[Issue 24558] New: C asserts segfault on Glibc
https://issues.dlang.org/show_bug.cgi?id=24558
Issue ID: 24558
Summary: C asserts segfault on Glibc
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: connor...@outlook.com
When running the minimal test case of ``extern(C) int main() {assert(0);}``,
dmd would segfault (this also applies to ldc2).
Expected behavior: ``file: /home/user/file.d:2: file.main: Assertion `0'
failed.``
Observed behavior: ``Segmentation Fault``
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Dlang Bot --- dlang/dmd pull request #16510 "fix issue24534 : goto can skip declarations in labeled statements without error" was merged into master: - 7f30b66d3dae37544c7629af1178f908984c2a93 by Ben Jones: Fix Bugzilla Issue 24534 : goto can skip declarations in labeled statements without error https://github.com/dlang/dmd/pull/16510 --
[Issue 24557] File.readln does not properly handle case where last character in terminator is repeated
https://issues.dlang.org/show_bug.cgi?id=24557
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@gmail.com
Hardware|x86_64 |All
OS|Linux |All
--- Comment #1 from Steven Schveighoffer ---
readln does use the last character, but it is also validating the "line" ends
in the full termination sequence.
However, the bug is that if the last character is repeated in the termination
sequence, it checks just the new data that it has read for the termination
sequence.
So for example, if you look for `ging` as the termination sequence, the
following algorithm results (assume input is `bringing home the bacon`):
1. result = "", readln('g') => "bring". Does "bring" end in "ging"? no
2. result = "bring", readln('g') => "ing". Does "ing" end in "ging"? no
3. result = "bringing", readln('g') => " home the bacon". readln returned no
delim found, so result is "bringing home the bacon"
Instead, readln should check the *concatenated* result (but obviously, only the
result that has been appended since the readln call was started.
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 --- Comment #10 from Ben --- "Since this is used in C code quite often, and therefore ported code (such as dmd's backend)." >From what I can tell, there's only one place in the whole compiler that's affected by this bug, so I don't think this is something that was commonly relied on. --
[Issue 24557] New: File.readln does not properly handle case where last character in terminator is repeated
https://issues.dlang.org/show_bug.cgi?id=24557
Issue ID: 24557
Summary: File.readln does not properly handle case where last
character in terminator is repeated
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: zopsi...@use.startmail.com
Consider the following program:
-
import std.stdio : readln, writefln;
void main()
{
char[] buf;
readln(buf, "ABA");
writefln!"%(%s%)"([buf]);
}
-
Compiled and run as follows:
-
$ dmd example.d
$ printf 'XABAY' | ./example
-
Expected output: "XABA"
Actual output: "XABAY"
readln does not properly handle the case where the last character of the
terminator (in this case A) appears multiple times in the terminator (in this
case, A also appears at the front of the terminator).
--
[Issue 24556] New: Allow IFTI for dotted template parameters used as function type parameter
https://issues.dlang.org/show_bug.cgi?id=24556
Issue ID: 24556
Summary: Allow IFTI for dotted template parameters used as
function type parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: b2.t...@gmx.com
Minor enhancement, not very useful but maybe that this should work:
```d
version(all)
void v(T,U)(T.U tu){}
else
void v(U, T = __traits(parent, U))(U tu){}; // that works fine RN
void main()
{
struct S1 { S2 s2; struct S2 {} }
S1 s1;
v(s1.s2);
struct G1 { struct G2 {} }
G1.G2 g1g2;
v(g1g2);
}
```
That is currently rejected but the compiler could guess that `U` is either `S2`
or `G2` and then infer `T` as being the parent type (if any). That would be
similar to the case where D deduces T, let's say in `void v(T)(T[] t)`.
--
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #16507 "Fix https://issues.dlang.org/show_bug.cgi?id=24546 for musl libc" was merged into stable: - af9f2e3234dc29f91f4029517260005a1cd87bb3 by Johan Engelen: Fix bugzilla 24546 for musl libc https://github.com/dlang/dmd/pull/16507 --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 --- Comment #9 from Jonathan M Davis --- (In reply to Richard (Rikki) Andrew Cattermole from comment #7) > But, it is also desirable to skip variable declarations, as long as you > don't touch them you do not violate the spec clause. The spec clause specifically disallows that: "It is illegal for a GotoStatement to be used to skip initializations." There's certainly an argument to be made that the rule could be more fine-grained and require that no variable be accessed whose declaration was skipped (which would also mean that the variable couldn't have a destructor), but as the rule currently stands, you can't legally skip variable declarations whether the variable is then used or not. --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534
--- Comment #8 from Richard (Rikki) Andrew Cattermole
---
I've done some playing around to see if backward goto's have an equivalent
issue.
It seems dmd is actually smart there, and I couldn't get that to not work.
Generates a try/finally:
```
Label:
SomethingWithSideEffects var = 0;
try
{
if (uniform01() > 0.5)
return 0;
goto Label;
}
finally
var.~this();
```
This means only forward goto's have broken analysis.
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 --- Comment #7 from Richard (Rikki) Andrew Cattermole --- It is a bug in the compiler, I agree on that too. But, it is also desirable to skip variable declarations, as long as you don't touch them you do not violate the spec clause. Since this is used in C code quite often, and therefore ported code (such as dmd's backend). A shortcut was taken with the current reverse search to analyze it, and it doesn't work as a result. Solving this properly requires type state analysis as that is what this particular clause involves. Therefore any attempts to fix this that does not do type state analysis is unfortunately another shortcut. --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Jonathan M Davis changed: What|Removed |Added Severity|enhancement |normal --- Comment #6 from Jonathan M Davis --- Since this is in violation of the spec, I'm changing this back to a bug. If it's decided that the current behavior is desirable for whatever reason, then the spec will need to be updated instead. And even if the spec is updated instead of making this code illegal like the spec says it should be, the fact that @safe works with this code in spite of the fact that the variable is not properly initialized means that there's a compiler bug either way. So, it's not an enhancement. --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @benjones updated dlang/dmd pull request #16510 "fix issue24534 : goto can skip declarations in labeled statements without error" fixing this issue: - Fix Bugzilla Issue 24534 : goto can skip declarations in labeled statements without error https://github.com/dlang/dmd/pull/16510 --
[Issue 24555] New: macOS: Add shared druntime/Phobos (libphobos2.dylib)
https://issues.dlang.org/show_bug.cgi?id=24555
Issue ID: 24555
Summary: macOS: Add shared druntime/Phobos (libphobos2.dylib)
Product: D
Version: D2
Hardware: All
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: ki...@gmx.net
While DMD and its druntime support a shared libphobos2.so for most ELF
platforms, there's no Mach-O support for macOS yet. LDC does support shared
druntime/Phobos on macOS/iOS, and upstreaming shouldn't be very hard.
The main adaptations are required in druntime's `rt.sections_elf_shared`
module, extending it to work with Mach-O binaries too. LDC's version is here:
https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/rt/sections_elf_shared.d.
In LDC, we've already extended it to Windows too, so the file/diff is
unfortunately pretty messy, and the whole module could very much use a
refactoring (and a better name!!!). LDC uses `rt.sections_elf_shared` for all
major platforms, for static *and* shared druntime; all the other upstream
rt.sections* implementations are unused and could probably be dropped upstream
too in time.
Then each binary needs to register itself with druntime, calling
`_d_dso_registry`. DMD does this by emitting a `d_dso_init` function into every
compiled object file, like LDC used to. We then switched to doing this in
druntime directly (no magic compiler-generated code anymore, which for Mach-O
would need an extra helper variable + function), via some special little
module:
https://github.com/ldc-developers/ldc/blob/master/runtime/druntime/src/rt/dso.d.
If adopting that approach, make sure to read the comments to understand what
needs to be done, like bundling that precompiled object file with the compiler
installation packages, and linking it automatically into every binary linked
against *shared* druntime. And note that DMD would then need to adopt some
`@hidden` UDA too; `dso.d` absolutely needs that functionality (of making
symbols binary-internal only).
I'd propose adopting LDC's `-link-defaultlib-shared` too, instead of DMD's
platform-specific `-defaultlib={libphobos2.so,libphobos2.dylib,phobos2.dll}`.
Linking in the bundled `dso.o` would become easier then too.
After that, adapting variable `SHARED` in druntime's Makefile (setting it to 1
on macOS) might be enough.
--
[Issue 24554] New: Clarrification for bad codegen on postfix operators
https://issues.dlang.org/show_bug.cgi?id=24554
Issue ID: 24554
Summary: Clarrification for bad codegen on postfix operators
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: alphaglosi...@gmail.com
Johan Engelen asked me on the ldc bug ticket to create a ticket to find out
what the specification means.
All three compilers have differing behavior.
DMD: https://github.com/ldc-developers/ldc/issues/4651
GDC: https://forum.dlang.org/post/zybltjuxkbvtvirzw...@forum.dlang.org
ldc fe 2.107 as per run.dlang.org
```d
void main()
{
int d = 42;
bool o = d > d++;
}
```
```
define i32 @_Dmain({ i64, ptr } %unnamed) #0 {
%d = alloca i32, align 4; [#uses = 4, size/byte = 4]
%o = alloca i8, align 1 ; [#uses = 1, size/byte = 1]
store i32 42, ptr %d, align 4
%1 = load i32, ptr %d, align 4 ; [#uses = 2]
%2 = add i32 %1, 1 ; [#uses = 1]
store i32 %2, ptr %d, align 4
%3 = load i32, ptr %d, align 4 ; [#uses = 1]
%4 = icmp sgt i32 %3, %1; [#uses = 1]
%5 = zext i1 %4 to i8 ; [#uses = 1]
store i8 %5, ptr %o, align 1
ret i32 0
}
```
Note; the icmp is after the add, which it shouldn't be.
Source: https://twitter.com/marcos_don/status/1787629240550150361
--
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @JohanEngelen updated dlang/dmd pull request #16507 "Fix https://issues.dlang.org/show_bug.cgi?id=24546 for musl libc" fixing this issue: - Fix bugzilla 24546 for musl libc https://github.com/dlang/dmd/pull/16507 --
[Issue 24553] New: all 0 struct initializer with float is still stored in data section
https://issues.dlang.org/show_bug.cgi?id=24553
Issue ID: 24553
Summary: all 0 struct initializer with float is still stored in
data section
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: backend
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
Consider these structs:
```d
struct A {
int[1] x;
}
struct B {
float[1] x;
}
struct C {
float[1] x = 0;
}
struct D {
char[1] x = 0;
}
```
A and D do not store any static data in the binary, because they are
zero-initialized types (char.init is non-zero, but the assignment sets it to
0).
B obviously must store static data because float.init is NaN.
But C still stores static data (1 32-bit 0s). This should not happen.
--
[Issue 24549] std.process.environment.get(null) segfaults
https://issues.dlang.org/show_bug.cgi?id=24549 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #9002 "Fix issue 24549 - std.process.environment.get(null) segfaults" was merged into stable: - 6ea12cf3a4b2fb6e3e962a87e1954b949f349a79 by Steven Schveighoffer: Fix bugzilla issue 24549 -- environment.get(null) segfaults on Linux https://github.com/dlang/phobos/pull/9002 --
[Issue 6297] cast() does not remove const or immutable on arrays and pointers
https://issues.dlang.org/show_bug.cgi?id=6297 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Steven Schveighoffer --- I have no idea what I was thinking those 13 years ago. OK to close ;) --
[Issue 6297] cast() does not remove const or immutable on arrays and pointers
https://issues.dlang.org/show_bug.cgi?id=6297 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- The spec (now) says: > Casting with no type or qualifiers removes any top level const, immutable, > shared or inout type modifiers from the type of the UnaryExpression https://dlang.org/spec/expression.html#cast_qualifier Note 'top level'. So I think this is invalid. --
[Issue 24552] cast to immutable in @safe not rejected
https://issues.dlang.org/show_bug.cgi?id=24552 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- As is(immutable Foo!uint : Foo!uint) is false, `opCast` should not be matched. --
[Issue 21626] foreach create reference to rvalue tuple returned by front
https://issues.dlang.org/show_bug.cgi?id=21626 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- Confirmed with dmd v2.108.0-rc.1. --
[Issue 7361] No documentation for front tuple expansion in foreach over range
https://issues.dlang.org/show_bug.cgi?id=7361 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Treleaven --- Initial docs were added in https://github.com/dlang/dlang.org/pull/3001. Improvements: https://github.com/dlang/dlang.org/pull/3832 --
[Issue 24552] New: cast to immutable in @safe not rejected
https://issues.dlang.org/show_bug.cgi?id=24552
Issue ID: 24552
Summary: cast to immutable in @safe not rejected
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: critical
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: elpenguin...@gmail.com
```
void fun() @safe {
static struct Foo(E) {
private E[] data;
Foo!NewElement opCast(T : Foo!NewElement, NewElement)() {
return Foo!NewElement(cast(NewElement[])data);
}
}
int[] data = [1,2,3,4,5];
Foo!int tmp = Foo!int(data);
immutable tmp2 = (cast(immutable Foo!uint)tmp).data;
assert(tmp2[2] == 3);
data[2] = 77;
assert(tmp2[2] == 77); // immutable data mutated?!
}
```
This should not be allowed to compile.
--
[Issue 24551] Missing O_NOFOLLOW enum on macOS
https://issues.dlang.org/show_bug.cgi?id=24551 --- Comment #1 from Andrea Fontana --- Probably 0x0100? https://opensource.apple.com/source/xnu/xnu-6153.81.5/bsd/sys/fcntl.h --
[Issue 24551] New: Missing O_NOFOLLOW enum on macOS
https://issues.dlang.org/show_bug.cgi?id=24551 Issue ID: 24551 Summary: Missing O_NOFOLLOW enum on macOS Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: trik...@gmail.com Here it is missing the O_NOFOLLOW def for darwin: https://github.com/dlang/dmd/blob/001b66ed4033ae642e3501dd8ccb5e15bf1b7933/druntime/src/core/sys/posix/fcntl.d#L461 Not sure which is the right value. --
[Issue 23812] ImportC: allow adding function attributes to imported C functions
https://issues.dlang.org/show_bug.cgi?id=23812 ponce changed: What|Removed |Added CC||alil...@gmail.com --- Comment #2 from ponce --- I've translated a fair share of C and AFAIK they all could be `nothrow @nogc`. --
[Issue 24550] New: formattedWrite should support string interpolation
https://issues.dlang.org/show_bug.cgi?id=24550
Issue ID: 24550
Summary: formattedWrite should support string interpolation
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
auto sink = appender!(char[]);
const world = "World";
// This works
sink.formattedWrite("Hello %s", world);
// This does not.
sink.formattedWrite(i"Hello $(world)");
--
[Issue 24549] std.process.environment.get(null) segfaults
https://issues.dlang.org/show_bug.cgi?id=24549 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @schveiguy updated dlang/phobos pull request #9002 "Fix issue 24549" fixing this issue: - Fix bugzilla issue 24549 -- environment.get(null) segfaults on Linux https://github.com/dlang/phobos/pull/9002 --
[Issue 24549] std.process.environment.get(null) segfaults
https://issues.dlang.org/show_bug.cgi?id=24549 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@gmail.com --- Comment #1 from Steven Schveighoffer --- The underlying issue is that `std.internal.cstring.tempCString` returns a `null` pointer if the input string is an empty string with a null pointer. This is surprising, and seems to have been done as a hack to work around issue 14980 I would not expect to get a null pointer when passing in an empty string, I'd expect an empty string. This has a seemingly "unforseen" effect on code that is accepting of a string, and blindly passes to `tempCString` for calling a C lib -- if the library function doesn't handle null pointers, or handles them differently than non-null empty strings, then it may crash or do something unexpected. The Linux `getenv` function is crashing on the null pointer (BTW, this does not happen on MacOS). --
[Issue 24548] [spec] Boolean condition conversion is not documented
https://issues.dlang.org/show_bug.cgi?id=24548 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3830 "Fix Bugzilla 24548 - [spec] Boolean condition conversion is not docum…" was merged into master: - e094010a34f32ce56a3a4db7df8b8f43fbe29b4d by Nick Treleaven: Fix Bugzilla 24548 - [spec] Boolean condition conversion is not documented Add subheading for boolean conditions. Also use subheading instead of panel for `if` condition variables. https://github.com/dlang/dlang.org/pull/3830 --
[Issue 24548] [spec] Boolean condition conversion is not documented
https://issues.dlang.org/show_bug.cgi?id=24548 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3830 "Fix Bugzilla 24548 - [spec] Boolean condition conversion is not docum…" fixing this issue: - Fix Bugzilla 24548 - [spec] Boolean condition conversion is not documented Add subheading for boolean conditions. Also use subheading instead of panel for `if` condition variables. https://github.com/dlang/dlang.org/pull/3830 --
[Issue 24548] New: [spec] Boolean condition conversion is not documented
https://issues.dlang.org/show_bug.cgi?id=24548 Issue ID: 24548 Summary: [spec] Boolean condition conversion is not documented Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: minor Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: n...@geany.org E.g. for IfStatement, the spec just says: > Expression is evaluated. The result is converted to a boolean, using > opCast!bool() if the method is defined. That is insufficient information. It should specify which types can be converted to bool, and how. PR incoming. --
[Issue 23156] Thread should not rethrow Errors
https://issues.dlang.org/show_bug.cgi?id=23156 Steven Schveighoffer changed: What|Removed |Added Keywords||safe --
[Issue 24547] Stack overflow in CppMangleVisitor.writeQualified
https://issues.dlang.org/show_bug.cgi?id=24547 Tim changed: What|Removed |Added Keywords||C++ --
[Issue 24547] New: Stack overflow in CppMangleVisitor.writeQualified
https://issues.dlang.org/show_bug.cgi?id=24547
Issue ID: 24547
Summary: Stack overflow in CppMangleVisitor.writeQualified
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: tim.dl...@t-online.de
DMD crashes when compiling the following code:
```
extern(C++):
struct S(bool defined)
{
enum DefinedType { Defined }
}
void f(T)(S!(true).DefinedType = S!(true).DefinedType.Defined)
{
}
void main()
{
f!(int)();
}
```
A gdb backtrace repeats the following three lines:
```
#50 0x55952ab7 in CppMangleVisitor::visit(TemplateInstance*)
(this=0x7fffb848, t=0x7789a8a0) at src/dmd/cppmangle.d:2095
#51 0x559d6f8e in TemplateInstance::accept(Visitor*)
(this=0x7789a8a0, v=0x7fffb848) at src/dmd/dtemplate.d:5496
#52 0x55951b67 in
_D3dmd9cppmangle16CppMangleVisitor14writeQualifiedMFCQBz9dtemplate16TemplateInstanceMDFZvZv
(this=0x7fffb848, dg=..., t=0x7789a8a0) at src/dmd/cppmangle.d:1671
```
According to run.dlang.org it compiled until 2.083.1 and DMD crashes since
2.084.1, but I did not check if the mangling was correct, when it compiled.
--
[Issue 24531] foreach lowering fails to compile with dip1000 and std.array.array
https://issues.dlang.org/show_bug.cgi?id=24531 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #3 from Nick Treleaven --- It compiles with: import std.algorithm : filter, map; Adding -dip1000 gives: arrayctfe.d(14): Error: scope variable `srcs` assigned to non-scope parameter `range` calling `arrayCtfe` arrayctfe.d(28):which is not `scope` because of `__r115 = range` Replacing the foreach statement with the while code in comment #0 does compile with -dip1000. --
[Issue 24531] foreach lowering fails to compile with dip1000 and std.array.array
https://issues.dlang.org/show_bug.cgi?id=24531 --- Comment #2 from Walter Bright --- I need a file, say, test.d, that when compiled with specific switches reproduces the error. --
[Issue 24531] foreach lowering fails to compile with dip1000 and std.array.array
https://issues.dlang.org/show_bug.cgi?id=24531 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- Unfortunately, the example provided is incomplete and not compilable. --
[Issue 24543] The `@__future` attribute is (almost) undocumented
https://issues.dlang.org/show_bug.cgi?id=24543 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3827 "Fix Bugzilla 24543 - The `@__future` attribute is (almost) undocumented" was merged into master: - 27c4d0cd87bcd63fbb52e6252ef8fd193f52eb78 by Nick Treleaven: Fix Bugzilla 24543 - The `@future` attribute is (almost) undocumented https://github.com/dlang/dlang.org/pull/3827 --
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 kinke changed: What|Removed |Added Keywords||ImportC --
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 kinke changed: What|Removed |Added CC||ki...@gmx.net --- Comment #2 from kinke --- I hardly find anything wrt. `__ss` via Google. MSVC doesn't seem to treat it in a special way, it's a valid identifier. Could this be a DMC specificum? https://digitalmars.com/ctg/pointers16.html --
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 --- Comment #1 from johanenge...@weka.io --- Fails in testsuite here: https://github.com/dlang/dmd/blob/046679129774bf886e0650fa593c24fb2c7de499/compiler/test/compilable/stdcheaders.c#L30 --
[Issue 24546] importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 johanenge...@weka.io changed: What|Removed |Added Keywords||industry --
[Issue 24546] New: importC musl setjmp.h failure
https://issues.dlang.org/show_bug.cgi?id=24546 Issue ID: 24546 Summary: importC musl setjmp.h failure Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: major Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: johanenge...@weka.io importC fails on musl libc setjmp.h, this line: https://github.com/cloudius-systems/musl/blob/00733dd1cf791d13ff6155509cf139a5f7b2eecb/include/setjmp.h#L15 It uses identifier `__ss` which is #defined by D's importc.h: https://github.com/dlang/dmd/blame/046679129774bf886e0650fa593c24fb2c7de499/druntime/src/importc.h#L73 Is it really needed to define `__ss` ? --
[Issue 24410] Assertion for syntax error with interpolation string
https://issues.dlang.org/show_bug.cgi?id=24410 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |FIXED --- Comment #1 from Nick Treleaven --- Works with v2.108.1 --
[Issue 24503] run.dlang.org compiler needs updating from 2.105.3
https://issues.dlang.org/show_bug.cgi?id=24503 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Treleaven --- Seems to be 2.108.0 now --
[Issue 24545] Problems with m32 mode on Linux
https://issues.dlang.org/show_bug.cgi?id=24545 --- Comment #1 from erikas.aub...@gmail.com --- Created attachment 1914 --> https://issues.dlang.org/attachment.cgi?id=1914=edit Minimal hello world program. This causes linker warnings when compiled with dmd -m32 -run hello.d but successfully completes. --
[Issue 24545] New: Problems with m32 mode on Linux
https://issues.dlang.org/show_bug.cgi?id=24545 Issue ID: 24545 Summary: Problems with m32 mode on Linux Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: erikas.aub...@gmail.com Created attachment 1913 --> https://issues.dlang.org/attachment.cgi?id=1913=edit Minimal example to cause a segfault with bindbc. Execute with dub run --single sdlcrash.d --compiler=dmd --arch=x86 There seems to be some sort of weirdness with the output generated by DMD in m32 mode. I initially stumbled on the problem while trying to use bindbc-sdl in dynamic mode--attempting to load the DLL causes a segfault. I've attached a minimal testcase to illustrate this, and can be executed with dub run --single sdlcrash.d --compiler=dmd --arch=x86 This problem doesn't happen in x86_64 mode, or with LDC or GDC in x86 mode. Furthermore, it generates some linker warnings about relocations in read-only sections and creating DT_TEXTREL in a PIE. These warnings seem to be generated with code I feed the compiler, even a trivial hello world--which I'm attaching. The hello world example does not segfault, however. --
[Issue 24544] New: asm grammar dosn't covers bracket syntax
https://issues.dlang.org/show_bug.cgi?id=24544
Issue ID: 24544
Summary: asm grammar dosn't covers bracket syntax
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dlang.org
Assignee: nob...@puremagic.com
Reporter: i...@lapyst.by
The current grammar for asm statements does not cover the following code:
```d
asm {
mov ECX, [ESP + 1]
}
```
While there exists a rule in `AsmBrExp` that allows for some brackets, they
require an expression before the beginning bracket:
```d
void* pc;
asm {
mov pc[EBP],EBX
}
```
--
[Issue 24542] actually apply VRP to foreach indices when array is of known length
https://issues.dlang.org/show_bug.cgi?id=24542 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- I tried VRP, I don't think it works for array lengths. See issue 13700. --
[Issue 24543] The `@__future` attribute is (almost) undocumented
https://issues.dlang.org/show_bug.cgi?id=24543 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org Summary|The `@future` attribute is |The `@__future` attribute |(almost) undocumented |is (almost) undocumented --
[Issue 24543] The `@future` attribute is (almost) undocumented
https://issues.dlang.org/show_bug.cgi?id=24543 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel created dlang/dlang.org pull request #3827 "Fix Bugzilla 24543 - The `@__future` attribute is (almost) undocumented" fixing this issue: - Fix Bugzilla 24543 - The `@future` attribute is (almost) undocumented https://github.com/dlang/dlang.org/pull/3827 --
[Issue 24542] New: actually apply VRP to foreach indices when array is of known length
https://issues.dlang.org/show_bug.cgi?id=24542
Issue ID: 24542
Summary: actually apply VRP to foreach indices when array is of
known length
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: qs.il.paperi...@gmail.com
Follow-up to Issue 24450
```d
foreach (int i, int x; cond() ? [1,2,3] : [1,2])
{ }
```
should likewise not be an error. The length is not known, but is bounded the
same way `cond() ? 3 : 2` is bounded, and VRP detects that.
--
[Issue 24541] New: cartesianProduct should have length for finite ranges
https://issues.dlang.org/show_bug.cgi?id=24541 Issue ID: 24541 Summary: cartesianProduct should have length for finite ranges Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P4 Component: phobos Assignee: nob...@puremagic.com Reporter: dlang-bugzi...@thecybershadow.net Does not compile: import std.algorithm.setops; assert(cartesianProduct([1, 2], [3, 4]).length == 4); Currently the code does: return joiner(map!((ElementType!R1 a) => zip(repeat(a), range2.save)) (range1)); --
[Issue 24540] Add order/index to enum member to return its position
https://issues.dlang.org/show_bug.cgi?id=24540
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #2 from Nick Treleaven ---
(In reply to apham from comment #0)
> void set(Foo e)
> {
> v |= 1 << e.order;
> }
>
> bool isSet(Foo e)
> {
> return (v & (1 << e.order)) != 0;
> }
It's not possible to take a runtime enum value and produce its index in an enum
without some runtime overhead.
Another issue is that `e.order` is already valid code, meaning call `order(e)`.
--
[Issue 24540] Add order/index to enum member to return its position
https://issues.dlang.org/show_bug.cgi?id=24540 --- Comment #1 from apham --- The value is also needed to be known at compile time static assert(Foo.one.order == 0); static assert(Foo.two.order == 1); --
[Issue 24540] New: Add order/index to enum member to return its position
https://issues.dlang.org/show_bug.cgi?id=24540
Issue ID: 24540
Summary: Add order/index to enum member to return its position
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ap...@hotmail.com
Currently to get the order/index of an enum member to be done in loop which is
slow. Provide such member will speedup the lookup
enum Foo
{
one=100, // First order/index=0
two=399, // Next is 1
...
}
auto checkingMember = Foo.two;
size_t index;
foreach (e; EnumMembers!Foo)
{
if (e == checkingMember)
return index;
index++;
}
One of the use case is provide a set of Foo using ubyte/ushort/uint/ulong
struct Set(E)
{
void set(Foo e)
{
v |= 1 << e.order;
}
bool isSet(Foo e)
{
return (v & (1 << e.order)) != 0;
}
More...functions
uint v;
}
--
[Issue 24539] __traits(identifier, …) should work with sequences
https://issues.dlang.org/show_bug.cgi?id=24539 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- Why? --
[Issue 24539] New: __traits(identifier, …) should work with sequences
https://issues.dlang.org/show_bug.cgi?id=24539 Issue ID: 24539 Summary: __traits(identifier, …) should work with sequences Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: qs.il.paperi...@gmail.com If the argument of `__traits(identifier)` is a sequence or simply multiple arguments, it should return either a sequence or array of the individual identifiers. Alternatively, add a new trait, `__traits(identifiers)` (with a plural-s), that takes as arguments and returns sequences. --
[Issue 21929] delegates capture do not respect scoping
https://issues.dlang.org/show_bug.cgi?id=21929 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #17 from Nick Treleaven --- Issue 23136 shows that this behaviour can violate immutable. --
[Issue 23136] closure in a loop should hold distinct values for each iteration
https://issues.dlang.org/show_bug.cgi?id=23136 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #3 from Nick Treleaven --- Seems to be a duplicate of this bug: https://issues.dlang.org/show_bug.cgi?id=21929 --
[Issue 22193] is expression not understanding global scope operator
https://issues.dlang.org/show_bug.cgi?id=22193 basile-z changed: What|Removed |Added Keywords||rejects-valid --
[Issue 17364] Difference between slicing a slice and a reference to a slice
https://issues.dlang.org/show_bug.cgi?id=17364 --- Comment #4 from basile-z --- As of v 2.108 DMD is consistent and always verifies that the slice is equal to `[1]`. Maybe that now the issue could be closed with a PR introducing a test with `version()` for each compiler ? --
[Issue 24538] ImportC: packed bitfields not implemented
https://issues.dlang.org/show_bug.cgi?id=24538 Walter Bright changed: What|Removed |Added Keywords||ImportC --
[Issue 24538] New: ImportC: packed bitfields not implemented
https://issues.dlang.org/show_bug.cgi?id=24538
Issue ID: 24538
Summary: ImportC: packed bitfields not implemented
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bugzi...@digitalmars.com
>From Timon Gehr:
```
#include
struct __attribute__((packed)) S{
long long x:8;
};
int main(){
printf("%ld\n",sizeof(long long)); // 8
printf("%ld\n",sizeof(struct S)); // 1
}
```
gcc gives 8 and 1, dmd gives 8 and 8.
--
[Issue 13891] __gshared/static anonymous union members do not overlap
https://issues.dlang.org/show_bug.cgi?id=13891 basile-z changed: What|Removed |Added CC||b2.t...@gmx.com Summary|__gshared/static union |__gshared/static anonymous |members do not overlap |union members do not ||overlap --
[Issue 23546] bad error message for forward referenced member in enum
https://issues.dlang.org/show_bug.cgi?id=23546 basile-z changed: What|Removed |Added Status|NEW |RESOLVED CC||b2.t...@gmx.com Resolution|--- |WORKSFORME --
[Issue 19139] Need a convenient syntax for invoking nested eponymous templates
https://issues.dlang.org/show_bug.cgi?id=19139 basile-z changed: What|Removed |Added Summary|Need a convenient syntax|Need a convenient syntax |for invoking nested |for invoking nested |templates |eponymous templates --
[Issue 24537] New: homepage, no link to the github organization
https://issues.dlang.org/show_bug.cgi?id=24537 Issue ID: 24537 Summary: homepage, no link to the github organization Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: trivial Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: b2.t...@gmx.com The forum as one in the Community menu, but not the homepage. --
[Issue 22189] type qualifier not applied to type tuple
https://issues.dlang.org/show_bug.cgi?id=22189 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ntrel updated dlang/dmd pull request #16439 "[broken] Support `TypeQual(TypeSeq)`" fixing this issue: - Fix Bugzilla 22189 - type qualifier not applied to type tuple https://github.com/dlang/dmd/pull/16439 --
[Issue 24536] C runtime constructor/destructor pragma should not be on an exported symbol
https://issues.dlang.org/show_bug.cgi?id=24536 --- Comment #1 from Richard Cattermole --- Another confirmation that it is not required for Linux https://stackoverflow.com/a/32701238 --
[Issue 24536] New: C runtime constructor/destructor pragma should not be on an exported symbol
https://issues.dlang.org/show_bug.cgi?id=24536 Issue ID: 24536 Summary: C runtime constructor/destructor pragma should not be on an exported symbol Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: alphaglosi...@gmail.com So apparently the C runtime constructor/destructors should not be exported. This article covers Linux shared libraries and mentions them. https://www.akkadia.org/drepper/dsohowto.pdf It would be good to verify if this is indeed true and ensure the compiler prevents it. --
[Issue 23812] ImportC: allow adding function attributes to imported C functions
https://issues.dlang.org/show_bug.cgi?id=23812 johanenge...@weka.io changed: What|Removed |Added Keywords||industry CC||johanenge...@weka.io --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534
--- Comment #4 from Ben ---
Gotta be a bug:
void f2(){ //compiles fine
int x2;
goto Label2;
Dummy2:
int y2;
Label2:
int z2;
}
GotoStatement::semantic() for Label2
goto lastvar: x2
LabelStatement::semantic() for Dummy2
labelstatement lastvar: x2
LabelStatement::semantic() for Label2
labelstatement lastvar: x2 <--- WRONG, should be y2
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 --- Comment #3 from Jonathan M Davis --- Well, it's in clear violation of the spec: https://dlang.org/spec/statement.html#goto-statement So, either the spec is wrong, or dmd is. Also, if you slap @safe on main, it compiles even though the initialization is skipped, which should never happen in @safe code. So, there's a bug here of some kind regardless. --
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534
Richard Cattermole changed:
What|Removed |Added
Priority|P1 |P3
CC||alphaglosi...@gmail.com
Severity|normal |enhancement
--- Comment #2 from Richard Cattermole ---
After thinking about this, it's intentional.
This allows you to have multiple blocks at the end of your function that handle
things like success versus error.
It is very C style, and is used in dmd.
The solution of course would be to create a new scope so it doesn't bleed
between the labels.
```d
goto Lerror;
Lsuccess:
{
}
Lerror:
{
}
```
If this is fixed, it's going to need a very long deprecation.
Or we could kill off this logic entirely and have type state analysis proper
which works on a per-variable basis rather than a coarse reverse search which
it is currently.
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Ben changed: What|Removed |Added CC||ben.james.jo...@gmail.com --- Comment #1 from Ben --- *** Issue 24535 has been marked as a duplicate of this issue. *** --
[Issue 24535] Accepts Invalid: goto can skip declarations if they're labelled
https://issues.dlang.org/show_bug.cgi?id=24535 Ben changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ben --- *** This issue has been marked as a duplicate of issue 24534 *** --
[Issue 24535] New: Accepts Invalid: goto can skip declarations if they're labelled
https://issues.dlang.org/show_bug.cgi?id=24535
Issue ID: 24535
Summary: Accepts Invalid: goto can skip declarations if they're
labelled
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ben.james.jo...@gmail.com
void f1(){ //fails with error about skipping a declaration
int x;
goto Label;
int y;
Label:
int z;
}
void f2(){ //compiles fine
int x;
goto Label;
Dummy:
int y;
Label:
int z;
}
--
[Issue 24534] Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534 Jonathan M Davis changed: What|Removed |Added Keywords||accepts-invalid --
[Issue 24534] New: Having a label on a declaration makes it possible to skip it with goto
https://issues.dlang.org/show_bug.cgi?id=24534
Issue ID: 24534
Summary: Having a label on a declaration makes it possible to
skip it with goto
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: issues.dl...@jmdavisprog.com
This code compiles and runs:
---
void main()
{
int x;
goto Label;
Dummy:
int y;
Label:
int z;
import std.stdio;
writeln(y);
}
---
The value of y is then garbage (e.g. 539662115), because the declaration for y
was skipped, and it wasn't actually initialized. On the other hand, if the
Dummy label is removed, then we get an error such as
---
q.d(4): Error: `goto` skips declaration of variable `q.main.y`
q.d(5):declared here
---
So, it would appear that the label on the variable is confusing the compiler
and causing it to not understand that a declaration has been skipped.
--
[Issue 24481] retro no longer works with types that support assignment but not moving
https://issues.dlang.org/show_bug.cgi?id=24481 --- Comment #3 from Dlang Bot --- dlang/phobos pull request #8998 "merge stable" was merged into master: - ffe00ebdc38ee803aab25e8032ca5828e06fafcf by Jonathan M Davis: Fix bugzilla issue 24481: retro stopped working In an attempt make it so that non-copyable types worked with some of the functions in std/range/package.d, they were made to use moves instead of assignment, which broke the code for types which work with assignment but not moves (which affected the folks at Weka). The code checked for assignment but not whether move could be used, and that didn't change when the code was changed to use move, meaning that the checks didn't match what the code was actually doing. So, to support both the non-copyable types and the ones that can be assigned to but not moved to, this changes the code to use core.lifetime.forward which will move the argument if it can and assign otherwise. So ,the code that worked previously should work again, and the newer functionality of being able to use non-copyable types with this code should continue to work. Discussion here: https://github.com/dlang/phobos/pull/8721 https://github.com/dlang/phobos/pull/8998 --
[Issue 24533] New: clamp with smaller-than-int T1 fails to compile with literal parameters
https://issues.dlang.org/show_bug.cgi?id=24533 Issue ID: 24533 Summary: clamp with smaller-than-int T1 fails to compile with literal parameters Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: elpenguin...@gmail.com Since DMD 2.099, this code fails to compile: ``` assert(clamp(ubyte(4), 1, 5) == 4); ``` Likely cause is https://github.com/dlang/phobos/pull/8293 --
[Issue 23756] Add thread local constructor/destructor pragma
https://issues.dlang.org/show_bug.cgi?id=23756 Richard Cattermole changed: What|Removed |Added OS|Windows |All --- Comment #4 from Richard Cattermole --- Glibc offers support for C++ thread local destruction as part of its implementation of pthread. https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables Via ``__cxa_thread_atexit ``. I don't know how we could hook into this, but it seems like we could do it if we wanted to. --
[Issue 24532] New: Add pragma to set function as a TLS callback function for Windows
https://issues.dlang.org/show_bug.cgi?id=24532 Issue ID: 24532 Summary: Add pragma to set function as a TLS callback function for Windows Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: alphaglosi...@gmail.com The ``DllMain`` function on Windows is an optional /user/ function for being notified of when a binary load/unload or thread constructs and destructs. However, it is not really an entry point function akin to ``main``. It should be viewed as one of many call-back functions for TLS. https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#tls-callback-functions Having a pragma to set a function as one of these, would enable multiple library notifications without tying up and using the ``DllMain`` function. For druntime this is especially important if you want that to be a static library, preventing the need for ``SimpleDllMain`` to exist. Related: https://issues.dlang.org/show_bug.cgi?id=23756 which is about thread hooks similar to crt_constructor. --
[Issue 24516] qualifiers lost when tupleof is aliased
https://issues.dlang.org/show_bug.cgi?id=24516 basile-z changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #6 from basile-z --- (In reply to Nick Treleaven from comment #4) > > The reason must be that `S` in `S.tupleof` is not a TypeExp it's a DeclExp. > > No, the quoted code is for static array tupleof. I see, the compiler code you quoted is not for `S.tupleof` > I tried adding it for > classes and structs but dotExp seems to have a phantom expression e which is > a VarExp. I'm not sure if that helps but, as you might already know ?, the D front-end rewrites the DotExp lhs to what it resolves to e.g either a VarExp, a TypeExp, a DeclExp, etc. If it's not that then maybe that VarExp is used to extract a side-effects or to create a lvalue. but I dont see why this would be done on a type, that would be a bug. --
[Issue 24516] qualifiers lost when tupleof is aliased
https://issues.dlang.org/show_bug.cgi?id=24516 --- Comment #5 from Nick Treleaven --- > The spec uses tupleof on a type right there in the example Sorry, yes. We shouldn't break code then. --
[Issue 24516] qualifiers lost when tupleof is aliased
https://issues.dlang.org/show_bug.cgi?id=24516 --- Comment #4 from Nick Treleaven --- > The reason must be that `S` in `S.tupleof` is not a TypeExp it's a DeclExp. No, the quoted code is for static array tupleof. I tried adding it for classes and structs but dotExp seems to have a phantom expression e which is a VarExp. --
[Issue 24525] auto ref lambda exp not parsed if used as left-most expression in an expression statement
https://issues.dlang.org/show_bug.cgi?id=24525 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/dmd pull request #16431 "Fix Bugzilla 24525 - ref lambda not parsed at start of ExpressionStat…" was merged into master: - 3c3be0716da1b6d2cdbe2ca6517a8b1cec6d7ae2 by Nick Treleaven: Fix Bugzilla 24525 - ref lambda not parsed at start of ExpressionStatement https://github.com/dlang/dmd/pull/16431 --
[Issue 24516] qualifiers lost when tupleof is aliased
https://issues.dlang.org/show_bug.cgi?id=24516
--- Comment #3 from basile-z ---
(In reply to Nick Treleaven from comment #1)
> > S.tupleof
>
> I don't think it makes sense to allow `tupleof` to be a type property. It
> should be instance only. The spec does not mention its use on a type.
> https://dlang.org/spec/class.html#tupleof
>
> Also in dmd/typesem.d, dotExp:
> ```d
> else if (ident == Id._tupleof)
> {
> if (e.isTypeExp())
> {
> error(e.loc, "`.tupleof` cannot be used on type `%s`",
> mt.toChars);
> return ErrorExp.get();
> }
> ```
> For some reason that is not being triggered.
The reason must be that `S` in `S.tupleof` is not a TypeExp it's a DeclExp.
--
[Issue 24516] qualifiers lost when tupleof is aliased
https://issues.dlang.org/show_bug.cgi?id=24516
--- Comment #2 from Jonathan M Davis ---
(In reply to Nick Treleaven from comment #1)
> > S.tupleof
>
> I don't think it makes sense to allow `tupleof` to be a type property. It
> should be instance only. The spec does not mention its use on a type.
> https://dlang.org/spec/class.html#tupleof
The spec uses tupleof on a type right there in the example that you're linking
to even before it uses it on a variable:
---
class Foo { int x; long y; }
static assert(__traits(identifier, Foo.tupleof[0]) == "x");
static assert(is(typeof(Foo.tupleof)[1] == long));
---
And both druntime and Phobos having been using tupleof on types for years -
e.g. std.traits.Fields. It would break a lot of existing code if tupleof
stopped working on types.
Also, in most cases, it's less error-prone to do type introspection on types
rather than values or symbols. Some kinds of type introspection have to be done
on values or symbols, but pretty much any time that a trait takes an alias
rather than a type, it makes it far trickier to write it correctly, and corner
cases are frequently a problem. If anything, the fact that type qualifers are
being lost when aliasing the result of tupleof is an example of why aliasing
symbols when doing type introspection (as opposed to aliasing types) tends to
be error-prone. We unfortunately have variety of bugs where weird stuff happens
like type qualifiers disappearing when operating on symbols rather than on
types, and it's why some of the traits in std.traits are overloaded so that
they can explicitly take types or use an alias parameter.
Using tupleof on an instance has some uses, since then you can do stuff like
---
foo.tupleof[0] = 1;
---
but when doing type introspection, it makes far more sense to be operating on
the type, and tupleof has worked that way for many years.
The problem in this bug report is that for some reason, aliasing the result of
tupleof results in symbols that behave differently from the direct result of
tupleof, and the qualifiers are lost. I see no reason why it should be
reasonable for that to happen.
--
[Issue 11662] Template constraint evaluation should not look eponymous template function parameters if it's unnecessary
https://issues.dlang.org/show_bug.cgi?id=11662 Chloé changed: What|Removed |Added CC||chloe...@use.startmail.com --
[Issue 24531] foreach lowering fails to compile with dip1000 and std.array.array
https://issues.dlang.org/show_bug.cgi?id=24531 Atila Neves changed: What|Removed |Added Keywords||industry, rejects-valid, ||safe --
[Issue 24531] New: foreach lowering fails to compile with dip1000 and std.array.array
https://issues.dlang.org/show_bug.cgi?id=24531
Issue ID: 24531
Summary: foreach lowering fails to compile with dip1000 and
std.array.array
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: atila.ne...@gmail.com
The code below fails to compile. This is the minimum reduction I could find.
The `arrayCtfe` function is the static if branch in std.array.array for __ctfe.
This particular example can be fixed with an alternative implementation that
calls the range API directly like so:
--
while(!range.empty) {
result ~= range.front;
range.popFront;
}
return result;
--
Unfortunately trying to do this in std.array results in compilation failures
for other ranges, and checking that this implementation is valid for the range
in question with `is(typeof)` or `__traits(compiles)` crashes the compiler.
Offending code:
-
struct Target {
string[] strings() @safe pure return scope const {
return [];
}
}
auto maybeAddDependencies(in Target target, in string projectPath) @safe pure {
Target[] targets;
scope srcs = targets.filter!(a => true);
return srcs
.map!(t => t.strings[0])
.arrayCtfe
;
}
// this is the implementation in std.array.array guarded by `if(__ctfe)`
auto arrayCtfe(R)(auto ref R range) {
import std.traits: ForeachType;
ForeachType!R[] result; // string[]
foreach (ref e; range) {
result ~= e;
}
return result;
}
-
--
[Issue 24530] New: Rethrowing exception outside of catch clause segfaults with -dip1008
https://issues.dlang.org/show_bug.cgi?id=24530
Issue ID: 24530
Summary: Rethrowing exception outside of catch clause segfaults
with -dip1008
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: chloe...@use.startmail.com
Steps to reproduce:
-
$ cat example.d
import std.stdio : writeln;
void main()
{
Throwable a;
try
throw new Exception("A");
catch (Throwable b)
a = b;
writeln(a);
}
$ dmd example.d
$ ./example
object.Exception@example.d(6): A
??:? _Dmain [0x44f8e8]
$ dmd -dip1008 example.d
$ ./example
zsh: segmentation fault (core dumped) ./example
-
s/writeln(a)/throw a;/ likewise segfaults. I suspect that a is dangling.
--
[Issue 24516] qualifiers lost when tupleof is aliased
https://issues.dlang.org/show_bug.cgi?id=24516
Nick Treleaven changed:
What|Removed |Added
CC||n...@geany.org
--- Comment #1 from Nick Treleaven ---
> S.tupleof
I don't think it makes sense to allow `tupleof` to be a type property. It
should be instance only. The spec does not mention its use on a type.
https://dlang.org/spec/class.html#tupleof
Also in dmd/typesem.d, dotExp:
```d
else if (ident == Id._tupleof)
{
if (e.isTypeExp())
{
error(e.loc, "`.tupleof` cannot be used on type `%s`",
mt.toChars);
return ErrorExp.get();
}
```
For some reason that is not being triggered.
--
[Issue 24525] auto ref lambda exp not parsed if used as left-most expression in an expression statement
https://issues.dlang.org/show_bug.cgi?id=24525 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @ntrel created dlang/dmd pull request #16431 "Fix Bugzilla 24525 - ref lambda not parsed at start of ExpressionStat…" fixing this issue: - Fix Bugzilla 24525 - ref lambda not parsed at start of ExpressionStatement https://github.com/dlang/dmd/pull/16431 --
[Issue 24520] [REG] type(value) got a synonym (type)(value)
https://issues.dlang.org/show_bug.cgi?id=24520 --- Comment #11 from Dlang Bot --- dlang/dlang.org pull request #3819 "[spec] Add grammar for `(Type)(args)` expression" was merged into master: - d9eb8e8511b08fb54b246c82ee60873f92480959 by Nick Treleaven: [spec] Add grammar for `(Type)(args)` Change introduced in https://github.com/dlang/dmd/pull/15377. Fixes Bugzilla 24520 - type(value) got a synonym (type)(value) Also combine 2 other PrimaryExpression rules with `TypeCtor? (Type).Identifier`. https://github.com/dlang/dlang.org/pull/3819 --
[Issue 24525] auto ref lambda exp not parsed if used as left-most expression in an expression statement
https://issues.dlang.org/show_bug.cgi?id=24525 Nick Treleaven changed: What|Removed |Added Assignee|nob...@puremagic.com|n...@geany.org --
[Issue 24529] New: is expression ignores implicit conversion of enum when pattern matching
https://issues.dlang.org/show_bug.cgi?id=24529
Issue ID: 24529
Summary: is expression ignores implicit conversion of enum when
pattern matching
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: snarwin+bugzi...@gmail.com
As of DMD 2.108.0, the following program fails to compile:
---
struct S(T) {}
enum E : S!int { a = S!int() }
static assert(is(E : S!int)); // ok
static assert(is(E : S!T, T)); // error
---
The error message is:
---
bug.d(5): Error: static assert: `is(E : S!T, __isexp_id2, T)` is false
---
The expected behavior is for both static assert statements to pass.
See also issue 21975, in which the same error was caused by a struct with
`alias this`.
--
