[Issue 20687] Allow member function address as const initializer
https://issues.dlang.org/show_bug.cgi?id=20687 Dlang Bot changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Dlang Bot --- dlang/dmd pull request #10958 "Fix Issue 20687 - Allow member function address as const initializer" was merged into master: - 7bcf238b606efcc9808c795447adca9ea47b4e3a by Boris Carvajal: Fix Issue 20687 - Allow member function address as const initializer of static data https://github.com/dlang/dmd/pull/10958 --
[Issue 23902] ImportC error message location for #defines are not precise enough.
https://issues.dlang.org/show_bug.cgi?id=23902 Walter Bright changed: What|Removed |Added Keywords||ImportC CC||bugzi...@digitalmars.com --
[Issue 18528] dmd should deduplicate identical errors
https://issues.dlang.org/show_bug.cgi?id=18528 mhh changed: What|Removed |Added Status|RESOLVED|REOPENED CC||maxha...@gmail.com Resolution|INVALID |--- --- Comment #2 from mhh --- Looks pretty actionable to me. --
[Issue 21341] [REG2.092] Wrong reference escape error when parameter is stored in this
https://issues.dlang.org/show_bug.cgi?id=21341 Dennis changed: What|Removed |Added Keywords||safe Status|NEW |RESOLVED CC||dkor...@live.nl Resolution|--- |INVALID --- Comment #2 from Dennis --- The code compiles now because the check is no longer performed in `@system` code, but the error comes back when you add `@safe:`. However, the behavior is as intended, and comes down to the infamous 'scope is not transitive' limitation. > The `return` on parameter `watcher` means that the reference escapes to the > `this` parameter. `scope` on `this` applies to the array (`watchers.ptr`), not any pointers in the array elements. Line 13 is equivalent to: ```D this.watchers ~= [A()]; ``` And the problem isn't the `this.watchers ~=` part, but the `[A()];` part putting it into a GC array literal (the 'allocated memory' that the error talks about) --
[Issue 23665] Add traits to retrieve template parameter information
https://issues.dlang.org/show_bug.cgi?id=23665 Bolpat changed: What|Removed |Added Summary|Add traits |Add traits to retrieve ||template parameter ||information --
[Issue 23883] `#line` is off by one and off by two if a line comment follows
https://issues.dlang.org/show_bug.cgi?id=23883 --- Comment #2 from Bolpat --- So, you’re suggesting that we make a bug a feature. Checking for comments before the directive ends isn’t that big of a deal. You don’t even have to handle it correctly, you can make it an error if that is easier. It’s surprising, and you shouldn’t surprise users. --
[Issue 23907] __traits(child) respects visibility
https://issues.dlang.org/show_bug.cgi?id=23907
--- Comment #2 from Bolpat ---
> I would argue that this is intended behavior and if the opposite occurs for
> other traits then that is the bug.
I strongly disagree.
If you were right, that would mean that you cannot e.g. create a serialization
library that can serialize private data members.
A module could reasonably pass a private symbol as an argument to an `alias`
parameter of a template imported from another module. That template should be
able to do its job, regardless whether the symbol is private.
> Which ones?
* `getProtection` for a trivial one.
* `getOverloads` allows accessing private overloads in a private aggregate
* `hasMember` and `allMembers` returns/lists private members
* `hasCopyConstructor` does not fail if the argument is an alias to a private
struct
I didn’t check all of them, just a sample.
> I tried `getMember` and that doesn't bypass private.
I have no idea what you tried, but in my tests, it does.
Here is what I tried (suitable for run.dlang.io):
```d
--- a.d
#line 3 "a.d"
private struct _S
{
private int x;
private void f() @safe {}
private static int f(int x) @safe pure => x;
}
// only way to access anything in this module:
alias S = _S;
--- playground.d
#line 16 "playground.d"
import a;
void main()
{
S s;
static foreach (ov; __traits(getOverloads, s, "f"))
{
static if (is(typeof(ov(0
{
ov(0);
}
}
static assert(__traits(hasMember, S, "f"));
static assert(__traits(hasMember, s, "f"));
static assert(!__traits(compiles, s.x = 2 )); // x is private
__traits(getMember, s, "x") = 2;
static assert(!__traits(compiles, assert(s.x == 2) )); // x is private
assert(__traits(getMember, s, "x") == 2);
static assert(__traits(getProtection, S) == "private");
static assert(__traits(getProtection, __traits(getMember, s, "x")) ==
"private");
}
```
--
[Issue 18528] dmd should deduplicate identical errors
https://issues.dlang.org/show_bug.cgi?id=18528 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #1 from RazvanN --- Any reduced code sample? Otherwise there is nothing actionable in this bug report. --
[Issue 18594] X is not an lvalue should have a better error message
https://issues.dlang.org/show_bug.cgi?id=18594 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --- Comment #7 from RazvanN --- This issue has been fixed by: https://github.com/dlang/dmd/pull/8009 --
[Issue 18598] cyclic constructor calls have undefined behavior but are accepted in @safe code
https://issues.dlang.org/show_bug.cgi?id=18598
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #5 from RazvanN ---
Well, infinite recursion also leads to a segfault due to stack overflow however
it is still accepted in @safe code [1]. @safe typically refers to undefined
behavior caused by memory corruption. I don't see any memory corruption
happening here, since the OS guards against that, rather a programming mistake
that is beyond of what the @safe checking mechanism can discover.
[1] void fun() @safe { fun();
--
[Issue 18605] Missing return not detected when labeled continue is used
https://issues.dlang.org/show_bug.cgi?id=18605 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #3 from RazvanN --- I cannot reproduce neither of the examples. I get: test.d(1): Error: function `test.test!(1, 2, 3).test` no `return exp;` or `assert(0);` at end of function test.d(11): Error: template instance `test.test!(1, 2, 3)` error instantiating So this seems to have been fixed. --
[Issue 18725] compiler does not check all levels of methods for privateness, if used in invariant
https://issues.dlang.org/show_bug.cgi?id=18725 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #1 from RazvanN --- What happens here is that the invariant calls a private method which in turns calls a public method. Since the compiler inserts an invariant call before and after the call to `fun1` you get infinite recursion. >From the spec: "Do not indirectly call exported or public member functions within a class invariant, as this can result in infinite recursion" [1]. So I would say that this bug report is invalid. If the expectation is that the compiler checks for such indirect calls, then that is not going to happen since the frontend does not do dataflow analysis. The idea is that invariants check public functions. Private functions are exempt so that you can put your validation checks in a private function and call that one, however, what the code example is doing is calling a public method to check the invariant correctness. This bug is invalid. [1] https://dlang.org/spec/class.html#invariants --
[Issue 18666] varargs foreach variable can't be assigned to local variable within foreach loop in @safe code
https://issues.dlang.org/show_bug.cgi?id=18666 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- This seems to have been fixed. I cannot reproduce. --
[Issue 18035] super does not work properly for template base classes
https://issues.dlang.org/show_bug.cgi?id=18035 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- Today `super` is no longer usable in static contexts, therefore you get errors that `super.fun` is undefined. Using `typeof(super).fun` makes the code compile. Arguably, the error could be improved. --
[Issue 18073] rdmd --eval 'int main() {return 0;}' fails to find 'std/stdiobase.d'
https://issues.dlang.org/show_bug.cgi?id=18073 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Component|dmd |tools Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- I cannot reproduce this. --
[Issue 18085] Segmentation fault: Error: variable __gate forward referenced
https://issues.dlang.org/show_bug.cgi?id=18085 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from RazvanN --- I cannot reproduce this with latest master. I get successful compilation. --
[Issue 23885] [CI] C++ interop tests with g++ fail
https://issues.dlang.org/show_bug.cgi?id=23885 --- Comment #4 from Dlang Bot --- dlang/dmd pull request #15210 "[Stable] Try to fix g++ failures phrasing command differently" was merged into stable: - 0836e7cd4612b8c99fe30be304e1bfa680ced73e by mhh: Fix Issue 23885 - Rearranging the commands makes the crypto operations not fail https://github.com/dlang/dmd/pull/15210 --
[Issue 18151] wrong auto ref lvalue inference for implicitly converted alias this parameters
https://issues.dlang.org/show_bug.cgi?id=18151 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15214 "Fix Issue 18151 - wrong auto ref lvalue inference for implicitly converted alias this parameters" fixing this issue: - Fix Issue 18151 - wrong auto ref lvalue inference for implicitly converted alias this parameters https://github.com/dlang/dmd/pull/15214 --
[Issue 23893] DMD linking errors with -betterC
https://issues.dlang.org/show_bug.cgi?id=23893 Richard Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #3 from Richard Cattermole --- There are two ways this could work, I haven't really figured out which strategy is in play as RTInfo has the same set of problems. Either it's just not emitting it since it was disabled (ok, nothing wrong with that). Or its triggering emittance at the usage site rather than declaration. --
[Issue 23908] confusing nonexistent import hint on cyclic import
https://issues.dlang.org/show_bug.cgi?id=23908 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #15209 "Fix 23908 - confusing nonexistent import hint on cyclic import" was merged into master: - c14c5b47a9c7d53e8952c79c04735f5701e75f40 by Dennis Korpel: Fix 23908 - confusing nonexistent import hint on cyclic import https://github.com/dlang/dmd/pull/15209 --
[Issue 23881] std.system has no function for system architecture
https://issues.dlang.org/show_bug.cgi?id=23881 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #8744 "fix issue 23881: add std.system.instructionSetArchitecture and std.system.ISA" was merged into master: - 57fa167e79ec7d3478c8ffcfc3e62157c7bf957c by Cameron Ross: fix issue 23881: add std.system.instructionSetArchitecture and std.system.ISA https://github.com/dlang/phobos/pull/8744 --
[Issue 23893] DMD linking errors with -betterC
https://issues.dlang.org/show_bug.cgi?id=23893 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- I would be tempted to make this a compiler error until classes are properly supported in betterC. I just don't see classes could ever compile when they inherit object and a bunch of typeinfo's are generated for them. How come this code compiles in ldc? --
[Issue 23907] __traits(child) respects visibility
https://issues.dlang.org/show_bug.cgi?id=23907 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- > This is consistent with other reflection traits Which ones? I tried getMember and that doesn't bypass private. I would argue that this is intended behavior and if the opposite occurs for other traits then that is the bug. --
[Issue 23904] Spurious "struct [...] already exists"
https://issues.dlang.org/show_bug.cgi?id=23904 --- Comment #3 from RazvanN --- This looks to me like a dupe of: https://issues.dlang.org/show_bug.cgi?id=19024 . Although the issues appears as being fixed, I think that the fix was just a hack that masks the true issue: using mangling names as type decorators does not work for template alias parameters. --
[Issue 23904] Spurious "struct [...] already exists"
https://issues.dlang.org/show_bug.cgi?id=23904
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #2 from RazvanN ---
Further reduced:
==
template f1(alias fun)
{
struct UnusedButConflicting
{
}
auto f1()
{
}
}
template f2(T)
{
alias fun = {};
auto f2(auto ref T)
{
f1!fun();
}
}
void main()
{
int a;
f2(5);
f2(a);
}
==
The problem here comes from the way dmd stores types. It essentially creates a
decoration by getting the mangled name of the type. In this case f2 creates
different template instances depending on whether f2 is called with an lvalue
or an rvalue (due to the presence of auto ref). Having 2 template instances,
this leads to having 2 f1 template instances due to `fun` being declared twice
in 2 different scopes, although the type is the same.
When semantic is performed on the unused struct the compiler tries to get a
unique identifier for the struct type by generating the mangled type. However,
the mangling is performing only by taking into account types. Since for both
template instances the type of the alias parameter is the same is the same
(although the value is different), the mangling ends up being the same,
however, the declarations are different, hence the error.
It seems that using the type for alias template parameters to generate the
mangling for such declarations is not a correct solution.
--
[Issue 23908] confusing nonexistent import hint on cyclic import
https://issues.dlang.org/show_bug.cgi?id=23908 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #15209 "Fix 23908 - confusing nonexistent import hint on cyclic import" fixing this issue: - Fix 23908 - confusing nonexistent import hint on cyclic import https://github.com/dlang/dmd/pull/15209 --
[Issue 23909] std.getopt stopOnFirstNonOption ignored with switches
https://issues.dlang.org/show_bug.cgi?id=23909 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Vladimir Panteleev --- Oh, configuration is positional. Invalid. --
[Issue 23909] New: std.getopt stopOnFirstNonOption ignored with switches
https://issues.dlang.org/show_bug.cgi?id=23909
Issue ID: 23909
Summary: std.getopt stopOnFirstNonOption ignored with switches
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: dlang-bugzi...@thecybershadow.net
It tries to parse the switch (and throws "Can't parse string"), even though
there is a non-option argument before it:
/// test.d ///
import std.getopt;
void main()
{
string[] args = ["program", "dmd", "-de"];
bool doDownload;
getopt(args,
"d", ,
config.stopOnFirstNonOption,
);
}
//
Introduced in https://github.com/dlang/phobos/pull/1050
--
[Issue 23908] New: confusing nonexistent import hint on cyclic import
https://issues.dlang.org/show_bug.cgi?id=23908 Issue ID: 23908 Summary: confusing nonexistent import hint on cyclic import Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: diagnostic Severity: minor Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: dkor...@live.nl If you have module a, and import something non existent from module b: ``` module a; import b : nonexistent; ``` ``` module b; import a; ``` The error message is: ``` a.d(3): Error: module `b` import `nonexistent` not found, did you mean alias `a.nonexistent`? ``` It's suggesting the very alias that the error is about, which obviously won't work. --
[Issue 23369] Confusing error message for duplicate import
https://issues.dlang.org/show_bug.cgi?id=23369 Dennis changed: What|Removed |Added Status|NEW |RESOLVED CC||dkor...@live.nl Resolution|--- |FIXED --- Comment #3 from Dennis --- PR was merged, but the bot didn't close it --
[Issue 23905] Initialization of SumType with opaque enum causes ICE
https://issues.dlang.org/show_bug.cgi?id=23905 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @RazvanN7 created dlang/dmd pull request #15207 "Fix Issue 23905 - Initialization of SumType with opaque enum causes ICE" fixing this issue: - Fix Issue 23905 - Initialization of SumType with opaque enum causes ICE https://github.com/dlang/dmd/pull/15207 --
[Issue 23905] Initialization of SumType with opaque enum causes ICE
https://issues.dlang.org/show_bug.cgi?id=23905 RazvanN changed: What|Removed |Added Severity|critical|regression --- Comment #2 from RazvanN --- This seems to be a regression: https://run.dlang.io/gist/2a4e6b629a053d8a45a1a164a593246c?compiler=dreg --
[Issue 23846] std.math can't compile under macos rosetta
https://issues.dlang.org/show_bug.cgi?id=23846 Scot changed: What|Removed |Added Keywords|pull| CC||thinku...@zoho.com --- Comment #14 from Scot --- I wanted to comment that I saw this same issue when trying to compile dmd-2.102.2 on an older Linux x86_64 system. I originally posted on the dlang forum here: https://forum.dlang.org/post/mailman.9077.1678347256.31357.digitalmars-d-le...@puremagic.com My post received no responses. I guess people don't compile dmd themselves. dmd-2.102.2 through anything before dmd-2.104.0-beta.1 would not compile phobos, ending with these errors: std/math/exponential.d(3782): Error: number `0x0.8p-126f` is not representable as a `float` std/math/exponential.d(3784): Error: number `0x0.56p-126f` is not representable as a `float` std/math/exponential.d(3795): Error: number `0x0.8p-1022` is not representable as a `double` std/math/exponential.d(3797): Error: number `0x0.5p-1022` is not representable as a `double` I just tested dmd-2.104.0-beta.1 and it now builds successfully on my older system, using and installed dmd-2.102.1 to do the build. Thanks for the fix! --
