[Issue 24796] New: Confusing irrelevant 'cannot pass rvalue argument' error message on a type error
https://issues.dlang.org/show_bug.cgi?id=24796
Issue ID: 24796
Summary: Confusing irrelevant 'cannot pass rvalue argument'
error message on a type error
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andy-han...@protonmail.com
```
void main() {
foo(Asdf());
}
void foo(in Asdg x) {}
struct Asdf {}
struct Asdg {
int a;
int b;
int c;
int d;
int e;
}
```
Compiling with `dmd a.d -preview=in` I get this error message:
```
a.d(2): Error: function `foo` is not callable using argument types `(Asdf)`
a.d(2):cannot pass rvalue argument `Asdf()` of type `Asdf` to parameter
`in Asdg x`
a.d(5):`a.foo(in Asdg x)` declared here
```
The error message appears to be complaining about an rvalue. The error is
actually just due to using the wrong type, and an rvalue of the correct type
would work.
The issue does not reproduce if the correct type has less than 5 fields.
--
[Issue 23841] isZeroInit does not take into account unions
https://issues.dlang.org/show_bug.cgi?id=23841 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16858 "Fix: isZeroInit does not take into account unions" was merged into master: - 261044eb866a952dab4063ea4aa945916bc444b1 by Nick Treleaven: Fix Bugzilla 23841 - isZeroInit does not take into account unions https://github.com/dlang/dmd/pull/16858 --
[Issue 24776] Struct with anonymous union has wrong isZeroInit
https://issues.dlang.org/show_bug.cgi?id=24776 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16858 "Fix: isZeroInit does not take into account unions" was merged into master: - cbb7cb6f3cd2eeed05aca8a2853c17e8829d0d2c by Nick Treleaven: Bugzilla 24776 - Struct with anonymous union has wrong isZeroInit - 179da5d3266fed3e9b3cbd65bf377d4149b31529 by Nick Treleaven: Fix Bugzilla 24776 - Struct with anonymous union has wrong isZeroInit https://github.com/dlang/dmd/pull/16858 --
[Issue 24793] Allow implicit conversion of const pointers to void*
https://issues.dlang.org/show_bug.cgi?id=24793
--- Comment #1 from anonymous4 ---
Any pimpl pattern is affected by this.
---
struct Console
{
GtkButton* btn;
void write(string s) const
{
g_signal_connect_data(cast(GtkButton*)btn, "clicked", &onClick);
}
}
---
--
[Issue 24795] New: emplace mutates immutable data in @safe code
https://issues.dlang.org/show_bug.cgi?id=24795
Issue ID: 24795
Summary: emplace mutates immutable data in @safe code
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: snarwin+bugzi...@gmail.com
As of DMD 2.109.1, the example program below compiles and runs to completion
without errors.
The program uses core.lifetime.emplace to mutate immutable data in @safe code.
Since mutating immutable data results in undefined behavior, it is a bug for
the program to compile.
The cause of the bug is the use of @trusted in core.lifetime.emplace to cast
away type qualifiers from the target object.
---
import core.lifetime;
void example1() @safe
{
const(int)* obj = new immutable(int)(123);
assert(*obj == 123);
emplace(obj, 456);
assert(*obj == 456); // immutable object mutated!
}
void example2() @safe
{
static class C
{
int n;
this(int n) pure @safe { this.n = n; }
}
const(C) obj = new immutable(C)(123);
assert(obj.n == 123);
emplace(obj, 456);
assert(obj.n == 456); // immutable object mutated!
}
void example3() @safe
{
static struct S
{
int n;
this(int n) pure @safe { this.n = n; }
}
const(S)* obj = new immutable(S)(123);
assert(obj.n == 123);
emplace(obj, 456);
assert(obj.n == 456); // immutable object mutated!
}
void main() @safe
{
example1();
example2();
example3();
}
---
--
[Issue 24374] ImportC: .di generator incorrect output for anonymous structs as members
https://issues.dlang.org/show_bug.cgi?id=24374 --- Comment #2 from Derek Fawcus --- I should modify that comment, I see that I can work with betterC despite the inability to mark the C imports as @nogc etc, as long as I haven't marked the betterC code in that fashion. So that was an error on my behalf, and I can continue investigating the viability of betterC additions to existing C code. I suspect this means not being able to optimise the repeated import of a common C header/module across multiple betterC file, in that each will have to parse the C source each time. --
[Issue 24374] ImportC: .di generator incorrect output for anonymous structs as members
https://issues.dlang.org/show_bug.cgi?id=24374 Derek Fawcus changed: What|Removed |Added CC||dfawcus+dl...@employees.org --- Comment #1 from Derek Fawcus --- I just ran in to exactly this issue while evaluating the potential for adding D (betterC mode) code to an existing C project, as an alternative to adding Rust code. For that I needed to be able to annotate existing functions with @nogc and nothrow, however the basic import of a C file does not allow for this. As such I decided to generate a .di file using this mechanism, and manipulate the file, prepending the annotations. Then I ran in to this issue. While I could work around this by altering my source files adding tags such that the struct / union is no longer anonymous, that is not viable. One reason being the quantity of changes required. More significantly the project headers in question transitively included system headers (inttypes.h) which themselves resulted in the same problem, as those system headers had similar anonymous structs and unions. Having to edit these is a non starter. There was another reason for wishing to pre-process the C headers to .di files, that being efficiency. By doing so, it would avoid the D compiler from having to repeatedly parse/transform the complete C sources, making builds faster. As it stands, the lack of ability to control the annotation (@nogc, nothrow, etc) applied to C sources so imported rather makes the use of ImportC and BetterC as I envisaged impractical. --
[Issue 24794] New: protected AND package?
https://issues.dlang.org/show_bug.cgi?id=24794 Issue ID: 24794 Summary: protected AND package? Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com I need to make some members `package`, but they are `protected` and need to stay that way. It seems a problem that protected and package are mutually exclusive... What are we supposed to do? In practise, most base class members are `protected`... but what's the point of package if not to make them accessible to some related functionality? We can't sacrifice the derived class access to those members :/ --
[Issue 20345] writing through `void[]` cannot be @safe
https://issues.dlang.org/show_bug.cgi?id=20345 Dennis changed: What|Removed |Added Status|NEW |RESOLVED CC||dkor...@live.nl Resolution|--- |DUPLICATE --- Comment #1 from Dennis --- Fixed by https://github.com/dlang/dmd/pull/16584 *** This issue has been marked as a duplicate of issue 24603 *** --
[Issue 24603] Can copy from non-void array into void[] in safe code
https://issues.dlang.org/show_bug.cgi?id=24603 Dennis changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #3 from Dennis --- *** Issue 20345 has been marked as a duplicate of this issue. *** --
[Issue 24793] New: Allow implicit conversion of const pointers to void*
https://issues.dlang.org/show_bug.cgi?id=24793
Issue ID: 24793
Summary: Allow implicit conversion of const pointers to void*
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
When interfacing with C APIs, I sometimes find myself casting away const on
void pointers.
```
void main()
{
const int* x = cast(int*) malloc(4);
free(cast(void*) x);
}
struct Console
{
HANDLE handle; // HANDLE = void* on Windows
void write(string s) const
{
WriteConsoleW(cast(void*) this.handle, ...);
}
}
```
This should be unnecessary. With void* you already completely give up on type
safety, so why be persnickety about `const`?
--
[Issue 24792] New: is expression doesn't seem to correctly handle function attributes
https://issues.dlang.org/show_bug.cgi?id=24792 Issue ID: 24792 Summary: is expression doesn't seem to correctly handle function attributes Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com This shouldn't emit `true`: alias Fun = void function(int); pragma(msg, is(Fun : RT function(Args) nothrow @nogc, RT, Args...)); The function pointer Fun should not say it's convertible to a nothrow @nogc function pointer; because it's not! --
[Issue 24791] New: Expression doesn't work
https://issues.dlang.org/show_bug.cgi?id=24791 Issue ID: 24791 Summary: Expression doesn't work Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com I feel like this should work: int x; pragma(msg, typeof(x)*); error : expression expected, not `)` It should print `int*` --
[Issue 24431] dmd -vcg-ast crashes printing failed template instantiation
https://issues.dlang.org/show_bug.cgi?id=24431 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #16916 "Fix bugzilla 24431 - dmd -vcg-ast crashes printing failed template in…" was merged into stable: - c7d7ad0fa8d99839103de49bfa59138940cc7746 by Dennis Korpel: Fix bugzilla 24431 - dmd -vcg-ast crashes printing failed template instantiation https://github.com/dlang/dmd/pull/16916 --
[Issue 14222] emplace implicit dynamic to static array fails
https://issues.dlang.org/show_bug.cgi?id=14222
Paul Backus changed:
What|Removed |Added
CC||snarwin+bugzi...@gmail.com
--- Comment #1 from Paul Backus ---
I'm pretty sure this is impossible. IFTI always infers parameter types from
argument types, not the other way around.
The best workaround is probably to use std.array.staticArray to convert the
array literal to the correct type:
---
struct S
{
this(int[3] a){}
}
unittest
{
auto s0 = S([1,2,3]); //OK
import std.conv : emplace;
import std.array : staticArray;
auto s1 = emplace!S(&s0, staticArray([1,2,3])); //OK
}
---
--
[Issue 24764] ICE when -vcg-ast prints imported invariant
https://issues.dlang.org/show_bug.cgi?id=24764 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16917 "Fix bugzilla 24764 - ICE when -vcg-ast prints imported invariant" was merged into stable: - c52c26276b6dc70054bbd6eac58c4d13445ab16b by Dennis Korpel: Fix bugzilla 24764 - ICE when -vcg-ast prints imported invariant https://github.com/dlang/dmd/pull/16917 --
[Issue 24790] -vcg-ast ICE on lowered assign exp
https://issues.dlang.org/show_bug.cgi?id=24790 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16914 "Fix bugzilla 24790 - -vcg-ast ICE on lowered assign exp" was merged into stable: - 1f0135d6459e38dc49393590bc83fa2a8ed300e0 by Dennis Korpel: Fix bugzilla 24790 - -vcg-ast ICE on lowered assign exp https://github.com/dlang/dmd/pull/16914 --
[Issue 24764] ICE when -vcg-ast prints imported invariant
https://issues.dlang.org/show_bug.cgi?id=24764 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16917 "Fix bugzilla 24764 - ICE when -vcg-ast prints imported invariant" fixing this issue: - Fix bugzilla 24764 - ICE when -vcg-ast prints imported invariant https://github.com/dlang/dmd/pull/16917 --
[Issue 24431] dmd -vcg-ast crashes printing failed template instantiation
https://issues.dlang.org/show_bug.cgi?id=24431 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16916 "Fix bugzilla 24431 - dmd -vcg-ast crashes printing failed template in…" fixing this issue: - Fix bugzilla 24431 - dmd -vcg-ast crashes printing failed template instantiation https://github.com/dlang/dmd/pull/16916 --
[Issue 24431] dmd -vcg-ast crashes printing failed template instantiation
https://issues.dlang.org/show_bug.cgi?id=24431 Dennis changed: What|Removed |Added CC||dkor...@live.nl Hardware|x86_64 |All Summary|dmd -vcg-ast crashes|dmd -vcg-ast crashes ||printing failed template ||instantiation OS|Linux |All --
[Issue 24790] -vcg-ast ICE on lowered assign exp
https://issues.dlang.org/show_bug.cgi?id=24790 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16914 "Fix bugzilla 24790 - -vcg-ast ICE on lowered assign exp" fixing this issue: - Fix bugzilla 24790 - -vcg-ast ICE on lowered assign exp https://github.com/dlang/dmd/pull/16914 --
[Issue 24790] New: -vcg-ast ICE on lowered assign exp
https://issues.dlang.org/show_bug.cgi?id=24790
Issue ID: 24790
Summary: -vcg-ast ICE on lowered assign exp
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: normal
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
```D
struct S { int[] payload; }
long f(S s) => s.payload.length += 3;
```
Compiling with -vcg-ast trips an assert with "precedence not defined for token
'='", because there's no PREC entry for EXP.loweredAssignExp.
--
[Issue 15843] D-type mangling used for extern(C) (extern) function declaration inside function body, on LDC, GDC, and DMD.
https://issues.dlang.org/show_bug.cgi?id=15843
basile-z changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from basile-z ---
Prgma mangle works locally since a year or so:
```
void main() {
pragma(mangle, "func")
extern(C) int func(int);
static assert(func.mangleof == "func");
}
```
--
[Issue 24789] Disallow body-less, non-extern, local functions
https://issues.dlang.org/show_bug.cgi?id=24789 --- Comment #1 from basile-z --- local body-less **non-extern** funcdecls have no use. --
[Issue 24789] New: Disallow body-less, non-extern, local functions
https://issues.dlang.org/show_bug.cgi?id=24789
Issue ID: 24789
Summary: Disallow body-less, non-extern, local functions
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
Given this small program, which compiles and run without error:
```d
module m;
void oops(){}
void main() {
void oops();
}
```
there could be an error for `main.oops` because
1. local body-less funcdecls have no use.
2. possibly the author was super-tired and meant to call `m.oops`.
--
[Issue 24715] std/process: Default to libc `closefrom` in spawnProcessPosix
https://issues.dlang.org/show_bug.cgi?id=24715 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #9048 "std/process: Default to libc closefrom in spawnProcessPosix" was merged into master: - 48d581a1f509a7a302ea893e28939edb5b130622 by Andrei Horodniceanu: Fix Bugzilla 24715 - std/process: Default to libc `closefrom` in spawnProcessPosix The current implementation of spawnProcessPosix is broken on systems with a large `ulimit -n` because it always OOMs making it impossible to spawn processes. Using the libc implementation, when available, for doing file descriptor operations en-mass partially solves this problem. Signed-off-by: Andrei Horodniceanu https://github.com/dlang/phobos/pull/9048 --
[Issue 24788] New: Template inferrence bug?
https://issues.dlang.org/show_bug.cgi?id=24788
Issue ID: 24788
Summary: Template inferrence bug?
Product: D
Version: D2
Hardware: All
URL: http://dlang.org/
OS: All
Status: NEW
Severity: normal
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: turkey...@gmail.com
void f(T)(const(T)[] x, const(T)* y) {}
void test()
{
// this works; T is inferred as int
int[] x;
const int y;
f(x, &y);
// fails: expected that T is inferred as int*
int*[] a;
const int* b;
f(a, &b);
}
Something about a/b being an arrangement of int* compared to x/y with int
causes this to fail.
I reckon the non-uniformity of this type deduction logic is a bug.
This non-uniformity has caused me several problems with meta code.
I think it's banging into an issue with const promotion; if you remove const
from y and b, both cases work properly.
--
[Issue 21995] Struct with size uint.max or greater causes ICE
https://issues.dlang.org/show_bug.cgi?id=21995 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16885 "fix bugzilla 21995 Struct with size uint.max or greater causes ICE" was merged into master: - 2595b71540a03bbeba55cf6f8d7a0a933deb1599 by Walter Bright: fix bugzilla 21995 Struct with size uint.max or greater causes ICE https://github.com/dlang/dmd/pull/16885 --
[Issue 6082] Constructors of templated types should be callable via IFTI
https://issues.dlang.org/show_bug.cgi?id=6082 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @dkorpel created dlang/dmd pull request #16910 "[WIP] Fix bugzilla 6082 - Constructors of templated types should be callabl…" fixing this issue: - Fix bugzilla 6082 - Constructors of templated types should be callable via IFTI https://github.com/dlang/dmd/pull/16910 --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 Dennis changed: What|Removed |Added CC||dkor...@live.nl --- Comment #9 from Dennis --- When I made a PR for this, it got closed for a reason which couldn't be specified. "There was a reason this was marked as unsafe, unfortunately I can't recall at the moment what it was." https://github.com/dlang/dmd/pull/10672 I personally don't believe it's unsafe however. --
[Issue 22174] destroy should be @nogc when class destructor is @nogc
https://issues.dlang.org/show_bug.cgi?id=22174 Manu changed: What|Removed |Added CC||turkey...@gmail.com Severity|enhancement |major --- Comment #2 from Manu --- This is a serious issue... it needs attention. --
[Issue 24787] Error signed integer overflow
https://issues.dlang.org/show_bug.cgi?id=24787 Dennis changed: What|Removed |Added CC||dkor...@live.nl Hardware|x86_64 |All OS|Linux |All --- Comment #1 from Dennis --- That expression gets parsed as -(9223372036854775808L), and 9223372036854775808 does not fit in a long, but you require it to be a long with the L suffix. You can remove the L suffix, or replace it with UL, and then the program works. Since this is filed as an enhancement request, what part of this behavior do you want to see changed exactly? --
[Issue 24787] New: Error signed integer overflow
https://issues.dlang.org/show_bug.cgi?id=24787 Issue ID: 24787 Summary: Error signed integer overflow Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@tagion.org Created attachment 1918 --> https://issues.dlang.org/attachment.cgi?id=1918&action=edit Test program The value long.min written as decimal results in an overflow error, both for ldc2 and dmd. long z=-9223372036854775808L; Error: signed integer overflow Compiler used dmd --version DMD64 D Compiler v2.109.0-rc.1 Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved written by Walter Bright ldc2 --version LDC - the LLVM D compiler (1.39.0): based on DMD v2.109.1 and LLVM 18.1.6 built with LDC - the LLVM D compiler (1.39.0) --
[Issue 22374] [REG 2.093] 'import std;' with -checkaction=context causes link error
https://issues.dlang.org/show_bug.cgi?id=22374 --- Comment #4 from kdevel --- Correction: WORKSFORME $ dmd -checkaction=context asszer.d $ ./asszer core.exception.AssertError@asszer.d(5): Assertion failure ??:? _d_assertp [0x4bbf14] ??:? _Dmain [0x4b30e0] --
[Issue 22374] [REG 2.093] 'import std;' with -checkaction=context causes link error
https://issues.dlang.org/show_bug.cgi?id=22374
kdevel changed:
What|Removed |Added
CC||kde...@vogtner.de
--- Comment #3 from kdevel ---
(In reply to Paul Backus from comment #0)
> As of DMD 2.097.2, compiling the following program with the flag
> `-checkaction=context` results in a linker error.
>
> ---
> import std;
>
> void main()
> {
> assert(0);
> }
> ---
>
WORKSFORME
$ dmd --version
DMD64 D Compiler v2.109.1
Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved
written by Walter Bright
$ cat asszer.d
import std;
void main()
{
assert(0);
}
$ dmd asszer.d
$ ./asszer
core.exception.AssertError@asszer.d(5): Assertion failure
??:? _d_assertp [0x4bbf14]
??:? _Dmain [0x4b30e0]
--
[Issue 24489] [REG 2.106] GC array allocations during CTFE in -betterC mode is unnecessarily restricted now
https://issues.dlang.org/show_bug.cgi?id=24489 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@gmail.com Hardware|x86_64 |All Summary|GC array allocations during |[REG 2.106] GC array |CTFE in -betterC mode is|allocations during CTFE in |unnecessarily restricted|-betterC mode is |now |unnecessarily restricted ||now OS|Windows |All --
[Issue 16643] CTFE internal error with null
https://issues.dlang.org/show_bug.cgi?id=16643 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #16887 "fix bugzilla Issue 16643 - CTFE internal error with null" was merged into master: - 824aa460e22abe532dccdafe10cd09ba216b63e2 by Walter Bright: fix bugzilla Issue 16643 - CTFE internal error with null https://github.com/dlang/dmd/pull/16887 --
[Issue 24784] Error on first lambda parameter with default with type inference
https://issues.dlang.org/show_bug.cgi?id=24784 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @Bolpat created dlang/dmd pull request #16889 "Fix Bugzilla Issue 24784" fixing this issue: - Fix Bugzilla Issue 24784 https://github.com/dlang/dmd/pull/16889 --
[Issue 24784] Error on first lambda parameter with default with type inference
https://issues.dlang.org/show_bug.cgi?id=24784 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com Assignee|nob...@puremagic.com|qs.il.paperi...@gmail.com --- Comment #2 from Bolpat --- I’ll try to fix this. --
[Issue 24786] dmd does not compile a c file (ImportC not used)
https://issues.dlang.org/show_bug.cgi?id=24786 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #1 from Richard (Rikki) Andrew Cattermole --- What does the command to cl produce? ``` cl.exe /P /Zc:preprocessor /PD /nologo /utf-8 example.c /FIc:\winoss\dmd2\windows\bin64\..\..\src\druntime\import\importc.h /FiC:\Users\VASILI~1\AppData\Local\Temp\scuo.0 ``` --
[Issue 24784] Error on first lambda parameter with default with type inference
https://issues.dlang.org/show_bug.cgi?id=24784
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #1 from Nick Treleaven ---
When there's a default initializer, I think the Identifier is parsed as a type:
struct X {}
alias fp = (X = X.init) {
pragma(msg, is(X)); return 0; }; // true
enum e = fp(X());
See Issue 12814.
--
[Issue 16643] CTFE internal error with null
https://issues.dlang.org/show_bug.cgi?id=16643 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #16887 "fix bugzilla Issue 16643 - CTFE internal error with null" fixing this issue: - fix bugzilla Issue 16643 - CTFE internal error with null https://github.com/dlang/dmd/pull/16887 --
[Issue 21995] Struct with size uint.max or greater causes ICE
https://issues.dlang.org/show_bug.cgi?id=21995 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86_64 |All OS|Linux |All --
[Issue 21995] Struct with size uint.max or greater causes ICE
https://issues.dlang.org/show_bug.cgi?id=21995 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #16885 "fix bugzilla 21995 Struct with size uint.max or greater causes ICE" fixing this issue: - fix bugzilla 21995 Struct with size uint.max or greater causes ICE https://github.com/dlang/dmd/pull/16885 --
[Issue 24786] New: dmd does not compile a c file (ImportC not used)
https://issues.dlang.org/show_bug.cgi?id=24786 Issue ID: 24786 Summary: dmd does not compile a c file (ImportC not used) Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: fithis2...@gmail.com Created attachment 1917 --> https://issues.dlang.org/attachment.cgi?id=1917&action=edit The c file I used to compile dmd cannot compile the attached hello.c file with ImportC System Windows 10 x64 19045.4894 Output of command ``` c:\work\swig_experiment>dmd -v example.c predefs DigitalMars LittleEndian D_Version2 all D_SIMD Windows Win64 CRuntime_Microsoft CppRuntime_Microsoft D_InlineAsm_X86_64 X86_64 D_LP64 assert D_PreConditions D_PostConditions D_Invariants D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat binarydmd version v2.109.1 configc:\winoss\dmd2\windows\bin64\sc.ini DFLAGS-Ic:\winoss\dmd2\windows\bin64\..\..\src\phobos -Ic:\winoss\dmd2\windows\bin64\..\..\src\druntime\import include c:\winoss\dmd2\windows\bin64\..\..\src\druntime\import\importc.h cl.exe /P /Zc:preprocessor /PD /nologo /utf-8 example.c /FIc:\winoss\dmd2\windows\bin64\..\..\src\druntime\import\importc.h /FiC:\Users\VASILI~1\AppData\Local\Temp\scuo.0 ``` PATH: ``` C:\Windows;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\winoss\VSCodium\bin;C:\Program Files\RedHat\Podman\;c:\winoss\git\cmd;C:\winoss\Python312\Scripts\;C:\winoss\Python312\;C:\Users\VasilisAnagnostopoul\AppData\Local\Programs\Python\Launcher\;C:\Users\VasilisAnagnostopoul\AppData\Local\Microsoft\WindowsApps;C:\Users\VasilisAnagnostopoul\AppData\Local\Coursier\data\bin;C:\Users\VasilisAnagnostopoul\AppData\Local\Programs\Rancher Desktop\resources\resources\linux\bin\;C:\Users\VasilisAnagnostopoul\AppData\Local\Programs\Rancher Desktop\resources\resources\win32\bin\;C:\winoss\jdk-23\bin;C:\winoss\apache-maven-3.9.8\bin;C:\Users\VasilisAnagnostopoul\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\VasilisAnagnostopoul\AppData\Local\Apps\Janet\bin\;;"c:\winoss\clang+llvm-18.1.8-x86_64-pc-windows-msvc\bin";c:\winoss\dmd2\windows\bin64 ``` Is there any possibility it has to do with Corporate Antivirus? I use Sophos --
[Issue 24635] Allow opApply with default parameters
https://issues.dlang.org/show_bug.cgi?id=24635 --- Comment #2 from Bolpat --- A use case is a recursive `opApply` that walks a tree-like structure; the recursive calls calls `opApply` on the child trees. --
[Issue 21995] Struct with size uint.max or greater causes ICE
https://issues.dlang.org/show_bug.cgi?id=21995 kdevel changed: What|Removed |Added CC||kde...@vogtner.de --
[Issue 24785] Add explicit template arguments for lambdas
https://issues.dlang.org/show_bug.cgi?id=24785 --- Comment #1 from Bolpat --- This would enable things like: ```d allSatisfy!(function template(T) => is(T : Object), ...) ``` Although requiring some modifications to `allSatisfy` to make it call a function pointer or delegate with zero arguments if given one via `alias`. --
[Issue 24785] Add explicit template arguments for lambdas
https://issues.dlang.org/show_bug.cgi?id=24785 Bolpat changed: What|Removed |Added CC||qs.il.paperi...@gmail.com --
[Issue 24785] New: Add explicit template arguments for lambdas
https://issues.dlang.org/show_bug.cgi?id=24785
Issue ID: 24785
Summary: Add explicit template arguments for lambdas
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
Add explicit template arguments for lambdas
After the `function` and `delegate` keyword, optionally allow for a template
argument list, introduced by the `template` keyword and a following template
parameter list. The parameters of such a lambda would be parsed exactly like a
regular function’s parameter list, i.e. `function template() (x) {}` (unless
`x` is a type in scope) will not work. The explicit write-out of
`function(x){}` is `function template(T)(T x) {}`.
The advantages:
- A lambda can be a template, even if it would otherwise not be: `function
template() int (int x) => x`
- A programmer can use the template type parameters in the lambda body
- Constraints are possible
- The ordering of type parameters is up to the programmer: `function
template(T1, T2) (T2 x, T1 y) { }`
- Variadic lambdas are possible: `function template(Ts...) (Ts args) { }`
- Template parameters can be any kind of template parameter, not just type.
- Template parameters can have a specialization.
- Template parameters can have a default.
Not really an argument: C++20 is ahead of D in this regard.
Required grammar changes:
```diff
FunctionLiteral:
function RefOrAutoRef? BasicTypeWithSuffixes? ParameterWithAttributes?
FunctionLiteralBody
delegate RefOrAutoRef? BasicTypeWithSuffixes?
ParameterWithMemberAttributes? FunctionLiteralBody
+ function template TemplateParameters RefOrAutoRef?
BasicTypeWithSuffixes? ParameterWithAttributes? Constraint? FunctionLiteralBody
+ delegate template TemplateParameters RefOrAutoRef?
BasicTypeWithSuffixes? ParameterWithMemberAttributes? Constraint?
FunctionLiteralBody
```
A fully formed function literal can look like this:
```d
delegate template(T : Object = Object, Ts...)
auto ref T (auto ref Ts args) const @safe
if (allSatisfy!(function template(T) => is(T : Object), Ts))
in (Ts.length == 0 || args[$-1] !is null)
{ ... }
```
---
I tried implementing this, and the parsing is doable, but it seems the
semantics doesn’t see the template parameters. A simple `function template(T)
=> is(T)` sets `is(T)` always `false`.
For a quick start for anyone who wants to tackle this, this is the diff of
parse.d I used: It works perfectly when using `alias fp = function template(T)
=> is(T);`, however, that’s due to `alias` lowering stuff to immediate
declarations.
diff --git a/compiler/src/dmd/parse.d b/compiler/src/dmd/parse.d
index bb2411825f..e4092f6040 100644
--- a/compiler/src/dmd/parse.d
+++ b/compiler/src/dmd/parse.d
@@ -5078,7 +5078,9 @@ class Parser(AST, Lexer = dmd.lexer.Lexer) : Lexer
private AST.Dsymbol parseFunctionLiteral()
{
const loc = token.loc;
+bool isExplicitTemplate = false;
AST.TemplateParameters* tpl = null;
+AST.Expression constraint = null;
AST.ParameterList parameterList;
AST.Type tret = null;
StorageClass stc = 0;
@@ -5090,6 +5092,14 @@ class Parser(AST, Lexer = dmd.lexer.Lexer) : Lexer
case TOK.delegate_:
save = token.value;
nextToken();
+
+if (token.value == TOK.template_)
+{
+nextToken();
+isExplicitTemplate = true;
+tpl = parseTemplateParameterList();
+}
+
if (token.value == TOK.auto_)
{
nextToken();
@@ -5158,7 +5168,7 @@ class Parser(AST, Lexer = dmd.lexer.Lexer) : Lexer
{
// (parameters) => expression
// (parameters) { statements... }
-parameterList = parseParameterList(&tpl);
+parameterList = parseParameterList(isExplicitTemplate ? null :
&tpl);
stc = parsePostfix(stc, null);
if (StorageClass modStc = stc & STC.TYPECTOR)
{
@@ -5196,6 +5206,11 @@ class Parser(AST, Lexer = dmd.lexer.Lexer) : Lexer
assert(0);
}
+if (isExplicitTemplate)
+{
+constraint = parseConstraint();
+}
+
auto tf = new AST.TypeFunction(parameterList, tret, linkage, stc);
tf = cast(AST.TypeFunction)tf.addSTC(stc);
auto fd = new AST.FuncLiteralDeclaration(loc, Loc.initial, tf, save,
null, null, stc & STC.auto_);
@@ -5215,7 +5230,7 @@ class Parser(AST, Lexer = dmd.lexer.Lexer) : Lexer
}
else
{
-parseContracts(fd);
+parseContracts(fd, isExplicitTemplate);
}
if (tpl)
--
[Issue 24784] New: Error on first lambda parameter with default with type inference
https://issues.dlang.org/show_bug.cgi?id=24784
Issue ID: 24784
Summary: Error on first lambda parameter with default with type
inference
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
Example:
```d
alias fp = (x = 0) { }; // Error: undefined identifier `x`
```
--
[Issue 24392] Installer not working: Can't check signature: No public key
https://issues.dlang.org/show_bug.cgi?id=24392 Martin Nowak changed: What|Removed |Added CC||mcookspok...@gmail.com --- Comment #4 from Martin Nowak --- *** Issue 24767 has been marked as a duplicate of this issue. *** --
[Issue 24767] Bad Signature
https://issues.dlang.org/show_bug.cgi?id=24767 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Martin Nowak --- *** This issue has been marked as a duplicate of issue 24392 *** --
[Issue 24767] Bad Signature
https://issues.dlang.org/show_bug.cgi?id=24767 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1 from Martin Nowak --- This is indeed a missing update of the keyring signature, see issue 24392. You can try to zap your ~/dlang folder, which should skip validating the d-keyring itself. --
[Issue 24392] Installer not working: Can't check signature: No public key
https://issues.dlang.org/show_bug.cgi?id=24392 Martin Nowak changed: What|Removed |Added CC||ibuc...@gdcproject.org --
[Issue 24392] Installer not working: Can't check signature: No public key
https://issues.dlang.org/show_bug.cgi?id=24392 --- Comment #3 from Martin Nowak --- More specifically, the keyring was updated by now, but it wasn't signed with any of the existing keys, hence `install.sh update` might fail verifying the new d-keyring. Maybe we should skip that verification step to not complicate bootstrapping that much. > A workaround is to import the updated key manually for now. > `gpg --recv-keys E22EC04C82780970381402F4A7D4D42F8EC6A355` Actually that should update the dlang keyring, not the default one. `gpg --keyring ~/dlang/d-keyring.gpg --no-default-keyring --recv-keys E22EC04C82780970381402F4A7D4D42F8EC6A355` --
[Issue 24781] alias this on inner structs have wrong behaviour
https://issues.dlang.org/show_bug.cgi?id=24781 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- I fixed this bug in the past, but I remember that a fair amount of projects were broken by this change because they were relying on the existing behavior, that's why the preview was introduced (which had the effect that people continued using the broken version and relying on it more). Also, in this case it's really hard to issue deprecations since it's essentially silent change of code behavior. So we would either have to make the preview the default and deal with the breakage or continue as is. Of course, there's the dreaded alternative of making the preview the default in a new edition which would be the worse alternative since we will be stuck maintaining both behaviors. --
[Issue 16476] Shared Library of Phobos for Windows
https://issues.dlang.org/show_bug.cgi?id=16476 --- Comment #2 from Richard (Rikki) Andrew Cattermole --- Oh and the shared druntime/phobos switches were not brought to dmd. That also indicates the configuration is missing from dmd. --
[Issue 16476] Shared Library of Phobos for Windows
https://issues.dlang.org/show_bug.cgi?id=16476 Richard (Rikki) Andrew Cattermole changed: What|Removed |Added Priority|P4 |P1 CC||alphaglosi...@gmail.com --- Comment #1 from Richard (Rikki) Andrew Cattermole --- After Rainer's introduction of the visibility and dllimport override switches, druntime and phobos were not shipped as shared libraries by dmd on Windows. Depending upon how much needs to be upstreamed from ldc, this may be limited to the installer. --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 --- Comment #10 from basile-z --- Sorry I was looking for a `search` overrides modified in dmodule.d but now I remember that you have removed it a few months ago. --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 --- Comment #9 from RazvanN --- (In reply to basile-z from comment #8) > RazvanN: I dont like how it's implemented. > > I remember I already suggested that in a forum discussion but, let's do it > again: > > If it's implemented in the compiler it would be better to implements this as > a "touched" system. You see when searching a symbol has worked and via an > import, you flag that import as "touched". > > Then when the user asks for unused import you visit the tree and when it's > an import node and that import has not been touched you emit the warning. I am fully aware how to implement it. In fact you can see that my implementation does the same thing, however, in dmdlib you do not have all the information that the compiler does (yet, I hope). --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 basile-z changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #8 from basile-z --- RazvanN: I dont like how it's implemented. I remember I already suggested that in a forum discussion but, let's do it again: If it's implemented in the compiler it would be better to implements this as a "touched" system. You see when searching a symbol has worked and via an import, you flag that import as "touched". Then when the user asks for unused import you visit the tree and when it's an import node and that import has not been touched you emit the warning. --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 --- Comment #7 from Dlang Bot --- @RazvanN7 updated dlang/dmd pull request #16878 "Implement warnings for unused imports" mentioning this issue: - Add changelog entry + fix importc error + Fix Bugzilla Issue 24778 https://github.com/dlang/dmd/pull/16878 --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 --- Comment #6 from RazvanN --- Here's the dmd implementation: https://github.com/dlang/dmd/pull/16878 --
[Issue 24783] New: ref and out declarations can be initialized with null references
https://issues.dlang.org/show_bug.cgi?id=24783
Issue ID: 24783
Summary: ref and out declarations can be initialized with null
references
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
@safe:
void test(ref int r, out int o);
void foo() {
int* p;
test(*p, *p);
}
compiles without complaint. They should get a null check.
--
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #5 from RazvanN --- (In reply to Lance Bachmeier from comment #4) > (In reply to ryuukk_ from comment #3) > > It should be builtin into the compiler > > > > People should learn to submit PRs to DMD > > > > In odin it is as simple as passing: > > > > -vet-unused-imports > > Checks for unused import declarations. > > > > > > > > Nobody wants to download external programs for such a basic, yet important, > > feature > > It's Razvan's script, so the problem is not lack of understanding of how to > submit PRs. His post notes cases that will be hard to handle. I was trying to implement it using dmd as a library to see if it's possible, and if not to understand what changes are required to make it possible. Implementing this inside the compiler would actually be easier, provided that Walter does not oppose it. --
[Issue 24782] New: mmsystem header has align(1): near top
https://issues.dlang.org/show_bug.cgi?id=24782 Issue ID: 24782 Summary: mmsystem header has align(1): near top Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: minor Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: destructiona...@gmail.com ttps://github.com/dlang/dmd/blob/master/druntime/src/core/sys/windows/mmsystem.d#L21 in upstream still too. another bug caught by safer by default? that looks just plain wrong, but also not super important since things are pointers and dwords contrast to this thing generated from the microsoft xml: https://github.com/rumbu13/windows-d/blob/master/out/windows/multimedia.d#L576 this has align(1): inside the struct, which is different than outside the struct! either one is wrong and the other is right, or they're both wrong this mingw based thing from wine also doesn't have an align setting. https://github.com/wine-mirror/wine/blob/master/include/mmsystem.h feels wrong to me, want second opinion. this potential bug caughed by OpenD Safer By Default btw: arsd\simpleaudio.d(2274): Deprecation: field `WAVEHDR.lpData` cannot modify misaligned pointers in non-`@system`/`@trusted` code --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 --- Comment #4 from Lance Bachmeier --- (In reply to ryuukk_ from comment #3) > It should be builtin into the compiler > > People should learn to submit PRs to DMD > > In odin it is as simple as passing: > > -vet-unused-imports > Checks for unused import declarations. > > > > Nobody wants to download external programs for such a basic, yet important, > feature It's Razvan's script, so the problem is not lack of understanding of how to submit PRs. His post notes cases that will be hard to handle. --
[Issue 7014] Better union initialization syntax
https://issues.dlang.org/show_bug.cgi?id=7014
Nick Treleaven changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||n...@geany.org
Resolution|--- |FIXED
--- Comment #4 from Nick Treleaven ---
(In reply to bearophile_hugs from comment #0)
> union Foo { int s; uint u; };
> void bar(Foo f) {}
> void main() {
> bar(Foo(u:5));
> }
That is implemented as of:
https://dlang.org/changelog/2.108.0.html#dmd.named-arguments
--
[Issue 24781] alias this on inner structs have wrong behaviour
https://issues.dlang.org/show_bug.cgi?id=24781 Luís Ferreira changed: What|Removed |Added CC||cont...@lsferreira.net --
[Issue 24781] New: alias this on inner structs have wrong behaviour
https://issues.dlang.org/show_bug.cgi?id=24781
Issue ID: 24781
Summary: alias this on inner structs have wrong behaviour
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: cont...@lsferreira.net
The following code:
struct Bar { @property bool isValid() { return true; } }
struct Club { @property bool isValid() { return false; } }
struct Foo
{
Bar bar;
alias bar this;
Foobar foobar;
struct Foobar
{
Club club;
alias club this;
bool humm() { return isValid(); }
}
static @property bool isValid() { assert(0); }
}
void main()
{
Foo foo;
imported!"std.stdio".writeln(foo.foobar.humm);
}
---
It is expected to print `false` but runs the `assert(0)`.
`--preview=fixAliasThis` fixes the behaviour, but this is very very error prone
and we found the bug at Weka that is not trivial to find.
I strongly suggest either making `--preview=fixAliasThis` the default and add
deprecation messages on the cases where its affected by the new behaviour, or
error these cases and ask to be explicit.
e.g.:
this should tell to use either `this.isValid` or `Foo.isValid`.
--
[Issue 14945] unions are missing from the ABI page
https://issues.dlang.org/show_bug.cgi?id=14945 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3915 "Fix Bugzilla 14945 - unions are missing from the ABI page" fixing this issue: - Fix Bugzilla 14945 - unions are missing from the ABI page https://github.com/dlang/dlang.org/pull/3915 --
[Issue 24770] spam
https://issues.dlang.org/show_bug.cgi?id=24770 anonymous4 changed: What|Removed |Added URL|https://twin68vip5.com/ | --
[Issue 24777] spam
https://issues.dlang.org/show_bug.cgi?id=24777 anonymous4 changed: What|Removed |Added URL|https://awin68top2.com/ | --
[Issue 24780] New: Errors in Using "alias this = arr" within a Class
https://issues.dlang.org/show_bug.cgi?id=24780
Issue ID: 24780
Summary: Errors in Using "alias this = arr" within a Class
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: mzfh...@foxmail.com
Errors in Using alias this = arr within a Class
```d
class A
{
int [] arr;
alias arr this;
}
void main()
{
A a = new A;
a ~= 1;
writeln(a); // output: [1]
writeln(a); // output err: []
}
```
When attempting to print the value of variable a for the second time, an error
occurs, and the result is an empty array [].
--
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 ryuukk_ changed: What|Removed |Added CC||ryuukk@gmail.com --- Comment #3 from ryuukk_ --- It should be builtin into the compiler People should learn to submit PRs to DMD In odin it is as simple as passing: -vet-unused-imports Checks for unused import declarations. Nobody wants to download external programs for such a basic, yet important, feature --
[Issue 24779] New: ImportC: undefined identifier `_Float16`
https://issues.dlang.org/show_bug.cgi?id=24779 Issue ID: 24779 Summary: ImportC: undefined identifier `_Float16` Product: D Version: D2 Hardware: All OS: Mac OS X Status: NEW Keywords: ImportC Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: dave287...@gmail.com MacOS’s math.h has been updated for the new OS version and new SDK and is now unconditionally using the _Float16 type (which I think was standardized with C23). math.h now has these declarations: extern _Float16 __fabsf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __hypotf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __sqrtf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __ceilf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __floorf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __rintf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __roundf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __truncf16(_Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __copysignf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __nextafterf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __fmaxf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __fminf16(_Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); extern _Float16 __fmaf16(_Float16, _Float16, _Float16) __API_AVAILABLE(macos(15.0), ios(18.0), watchos(11.0), tvos(18.0)); ImportC is unable to parse these. You can work around it by #defining _Float16 to any other type to get things to compile and just don’t call those functions. --
[Issue 24777] spam
https://issues.dlang.org/show_bug.cgi?id=24777 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |INVALID Summary|AWIN - Game bài đổi thưởng |spam |Awin68 Tặng 888K khi tải về | --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 Lance Bachmeier changed: What|Removed |Added CC||la...@lancebachmeier.com --- Comment #2 from Lance Bachmeier --- (In reply to Manu from comment #0) > This has come up before... but I seriously, desperately want this. > Detecting unused imports is most important to improve build times. > I periodically try and cull old imports to improve build times, but it's > difficult to do, and just a massive waste of time! > > I know people don't like warnings; but this is exactly what warnings should > be for. Atila started a related thread a couple months ago: https://forum.dlang.org/post/uosaqeqcwvdbzuafj...@forum.dlang.org There was a tool posted in that thread that identifies unused global imports: https://forum.dlang.org/post/xlggsjttounitndne...@forum.dlang.org --
[Issue 24778] Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 --- Comment #1 from Manu --- I don't know any other language that can't do this, and people expect it to be available. We've had this in C# for over 20 years, and Java for much longer... we need this. It's an embarrassing omission. --
[Issue 24778] New: Warning for unused imports
https://issues.dlang.org/show_bug.cgi?id=24778 Issue ID: 24778 Summary: Warning for unused imports Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com This has come up before... but I seriously, desperately want this. Detecting unused imports is most important to improve build times. I periodically try and cull old imports to improve build times, but it's difficult to do, and just a massive waste of time! I know people don't like warnings; but this is exactly what warnings should be for. --
[Issue 24777] AWIN - Game bài đổi thưởng Awin68 Tặng 888K khi tải về
https://issues.dlang.org/show_bug.cgi?id=24777 awin68top2 changed: What|Removed |Added URL||https://awin68top2.com/ --
[Issue 13891] __gshared/static anonymous union members do not overlap
https://issues.dlang.org/show_bug.cgi?id=13891 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- Still happens with 2.109. Also: pragma(msg, Foo.b.offsetof); // 0 pragma(msg, Bar.b.offsetof); // Error: no property `offsetof` for `b` of type `int` --
[Issue 24620] ImportC: Missing builtins floating point (GCC)
https://issues.dlang.org/show_bug.cgi?id=24620 Lance Bachmeier changed: What|Removed |Added CC||la...@lancebachmeier.com --- Comment #3 from Lance Bachmeier --- I hit the same issue with C code calling na. Error message: Error: undefined identifier `__builtin_isinf_sign` Adding this to the top of the file fixed it: typedef isinf __builtin_isinf_sign; --
[Issue 23841] isZeroInit does not take into account unions
https://issues.dlang.org/show_bug.cgi?id=23841 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel updated dlang/dmd pull request #16858 "Fix Bugzilla 24776 - Struct with anonymous union has wrong isZeroInit" fixing this issue: - Fix Bugzilla 23841 - isZeroInit does not take into account unions https://github.com/dlang/dmd/pull/16858 --
[Issue 24776] Struct with anonymous union has wrong isZeroInit
https://issues.dlang.org/show_bug.cgi?id=24776 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dmd pull request #16858 "Fix Bugzilla 24776 - Struct with anonymous union has wrong isZeroInit" fixing this issue: - Fix Bugzilla 24776 - Struct with anonymous union has wrong isZeroInit https://github.com/dlang/dmd/pull/16858 --
[Issue 24776] New: Struct with anonymous union has wrong isZeroInit
https://issues.dlang.org/show_bug.cgi?id=24776
Issue ID: 24776
Summary: Struct with anonymous union has wrong isZeroInit
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: n...@geany.org
struct S6 {
union {
int i1;
float f1;
}
}
static assert(__traits(isZeroInit, S6)); // fails
S6.init should be zero - `{ S6.i1.init }` according to:
https://dlang.org/spec/property.html#init
PR incoming.
--
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772
Jonathan M Davis changed:
What|Removed |Added
CC||issues.dl...@jmdavisprog.co
||m
--- Comment #8 from Jonathan M Davis ---
As a general rule, if we can guarantee that something is memory safe, it should
be @safe. The general issue is being absolutely certain that something cannot
result in memory corruption in @safe code. So, we do need to be careful in
verifying that.
However, if we are 100% sure that something will not result in violating memory
safety in purely @safe code, we arguably should enable it, and I'm not sure if
it really matters whether it clearly enables anything.
For this particular case, if the void* is immediately passed to something
@system, then the @safety doesn't really matter, because you'll need to slap
@trusted on it all anyway. However, if there is a use case where the class is
converted to void* in a separate piece of code, then it's arguably just
annoying to required @trusted in that part of the code.
But I've certainly run into the case where I have to slap @trusted on code or
use debug {} just because I'm trying to print out the pointer value of a class
reference.
--
[Issue 24774] Input range + filter + chain => First element vanishes
https://issues.dlang.org/show_bug.cgi?id=24774 anon changed: What|Removed |Added Severity|minor |normal --
[Issue 24775] New: Input range -> take -> filter -> chain: Take gets applied *after* filter
https://issues.dlang.org/show_bug.cgi?id=24775
Issue ID: 24775
Summary: Input range -> take -> filter -> chain: Take gets
applied *after* filter
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: qigezx+dc40d6nao9...@grr.la
InputRange.take(n).filter.chain logically transforms it into
InputRange.filter.take(n-1).chain and thus takes the wrong number of elements
Example:
import std.stdio;
import std.algorithm;
import std.range;
auto inputRangeFactory(){
int i = 0;
int gen(){
return i++;
}
return generate!gen();
}
void main(){
// [10, 11, 12, 13, 14, 15, 16, 17, 18, 100]
inputRangeFactory.take(10).filter!"a>8".chain(only(100)).writeln;
// Unless filter would discard all taken elements
// [100]
inputRangeFactory.take(10).filter!"a>9".chain(only(100)).writeln;
// Adding "array" somewhere in the middle fixes it
// [9,100]
inputRangeFactory.take(10).array.filter!"a>8".chain(only(100)).writeln;
inputRangeFactory.take(10).filter!"a>8".array.chain(only(100)).writeln;
}
--
$ dmd --version
DMD64 D Compiler v2.109.1
Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved
written by Walter Bright
--
[Issue 24774] New: Input range + filter + chain => First element vanishes
https://issues.dlang.org/show_bug.cgi?id=24774
Issue ID: 24774
Summary: Input range + filter + chain => First element vanishes
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: qigezx+dc40d6nao9...@grr.la
Chaining another range after a filtered input range omits the first element.
Minimal example:
import std.stdio;
import std.algorithm;
import std.range;
void main(){
int i = 0;
int gen(){
return i++;
}
auto r1 = generate!gen.until!(x=> x>10);
auto r2 = only(100);
// Will print [7.8,9,10,100]
// 6 is missing
r1.filter!"a>5".chain(r2).writeln;
// By adding "array" before chain, it will behave properly
// [6,7,8,9,10,100]
// r1.array.filter!"a>5".chain(r2).writeln;
// r1.filter!"a>5".array.chain(r2).writeln;
}
>dmd --version
DMD64 D Compiler v2.109.1
Copyright (C) 1999-2024 by The D Language Foundation, All Rights Reserved
written by Walter Bright
os: linux x64
--
[Issue 24773] Stable sort() invokes the destructor on uninitialized elements
https://issues.dlang.org/show_bug.cgi?id=24773 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #9049 "Fix Bugzilla 24773: don't invoke destructors on uninitialized elements in stable sort" was merged into master: - cfd577b28dead189f08bdf5d2b6c94b3352d0af5 by Sönke Ludwig: Fix Bugzilla 24773: Don't invoke destructors on uninitialized elements in stable sort Uses a regular initialized temporary array when sorting elements with an elaborate assignment to avoid undefined behavior when destructors, postblits or copy constructors are invoked during the array assignment. https://github.com/dlang/phobos/pull/9049 --
[Issue 24773] Stable sort() invokes the destructor on uninitialized elements
https://issues.dlang.org/show_bug.cgi?id=24773 --- Comment #1 from Dlang Bot --- @s-ludwig created dlang/phobos pull request #9049 "Bugzilla 24773 - don't invoke destructors on uninitialized elements in stable sort" mentioning this issue: - Bugzilla 24773 - don't invoke destructors on uninitialized elements in stable sort Uses a regular initialized temporary array when sorting elements with an elaborate assignment to avoid undefined behavior when destructors, postblits or copy constructors are invoked during the array assignment. https://github.com/dlang/phobos/pull/9049 --
[Issue 24773] New: Stable sort() invokes the destructor on uninitialized elements
https://issues.dlang.org/show_bug.cgi?id=24773
Issue ID: 24773
Summary: Stable sort() invokes the destructor on uninitialized
elements
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: slud...@outerproduct.org
The TimSort implementation creates a temporary uninitialized array for copying
ranges of elements to. While this works fine for POD values, element types with
an elaborate destructor/postblit/copy constructor will be invoked with
uninitialized data, possibly leading to crashes or data corruption.
Test case:
---
import std.algorithm;
struct S {
int i = 42;
~this() { assert(i == 42); }
}
void main()
{
auto array = new S[](400);
array.sort!((a, b) => false, SwapStrategy.stable);
}
---
--
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772
--- Comment #7 from Richard (Rikki) Andrew Cattermole
---
That does establish some casting should be valid.
I.e.
```d
import std.stdio;
void main() {
writeln(cast(size_t)cast(void*)new Object);
}
```
--
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 Tim changed: What|Removed |Added CC||tim.dl...@t-online.de --- Comment #6 from Tim --- (In reply to Richard (Rikki) Andrew Cattermole from comment #1) > The only thing you can do once you cast it is cause program corruption. > > Is there a benefit to being able to do this in ``@safe`` that I am not aware > of? One use case is printing the address of an object: ``` auto o = new Object(); writeln(cast(void*) o); ``` Addresses could also be compared for equality or used as keys in associative arrays. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 --- Comment #5 from Richard (Rikki) Andrew Cattermole --- It is relevant because I am asking for justification of what you can do with it after casting which would also be @safe. Right now, we have no examples of this being a positive change, only negative ones. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 --- Comment #4 from Georgy Markov --- (In reply to Richard (Rikki) Andrew Cattermole from comment #3) > > You have lost the type system guarantees, calling into unknown code. > > Which yes, if you passed the wrong arguments could have led to program > corruption. Irrelevant. The cause of possible memory corruption is function call, not pointer conversion. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772 --- Comment #3 from Richard (Rikki) Andrew Cattermole --- That code is unsafe. You have lost the type system guarantees, calling into unknown code. Which yes, if you passed the wrong arguments could have led to program corruption. --
[Issue 24772] Casting class references to void* should be @safe
https://issues.dlang.org/show_bug.cgi?id=24772
--- Comment #2 from Georgy Markov ---
(In reply to Richard (Rikki) Andrew Cattermole from comment #1)
> The only thing you can do once you cast it is cause program corruption.
interface MyCOMInterface : IUnknown
{
/*...*/
}
MyCOMInterface comObject;
CoCreateInstance(
&clsid,
null,
CLSCTX_INPROC_SERVER,
&iid,
&cast(void*)comObject,
);
--
