[Issue 21537] Pointer to function pointer cannot be converted to pointer to const function pointer with lower attributes
https://issues.dlang.org/show_bug.cgi?id=21537 Bolpat changed: What|Removed |Added Summary|Function pointer* pointer' |Pointer to function pointer |attributes not covariant|cannot be converted to |when referencing|pointer to const function |(delegates' are)|pointer with lower ||attributes --
[Issue 21537] Function pointer* pointer' attributes not covariant when referencing (delegates' are)
https://issues.dlang.org/show_bug.cgi?id=21537 Bolpat changed: What|Removed |Added Severity|enhancement |normal --
[Issue 21537] Function pointer* pointer' attributes not covariant when referencing (delegates' are)
https://issues.dlang.org/show_bug.cgi?id=21537 --- Comment #5 from Bolpat --- (In reply to moonlightsentinel from comment #4) > (In reply to Bolpat from comment #3) > > How is a pointer to a function pointer morally different from a pointer to a > > delegate or a pointer to a class object reference? > > It isn't. > > > If types T and S have a subtyping relationship like T ⊆ S, then const(T)* ⊆ > > const(S)*; at least, this is the case when T and S are class types or when T > > and S are delegate types, but fails when T and S are function pointer types. > > No, such implicit conversion for pointer are already rejected: > > [code] Of course, if you don't use const, the conversion is not safe. But I did. I checked it again if I missed it at some point by accident, but at a quick glance I couldn't find a spot. (Even if there is one, the overall use of const makes clear what I'm talking about.) Your example demonstrates conversation to a pointer a mutable supertype object, but the bug report is about pointers to a const supertype object. Neither of us is wrong, but we're talking about slightly, but meaningfully different things. The code you posted is rejected and for good reasons, but it does not invalidate the bug report. --
[Issue 22539] [dip1000] slicing of returned ref scope static array should not be allowed
https://issues.dlang.org/show_bug.cgi?id=22539 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #13362 "Fix issue 22539 - slicing of returned ref scope static array should not be allowed" fixing this issue: - Fix issue 22539 - slicing of returned ref scope static array should not be allowed https://github.com/dlang/dmd/pull/13362 --
[Issue 22548] Windows installer for dmd 2.098.0 isn't signed by the DLF
https://issues.dlang.org/show_bug.cgi?id=22548 Vivien Moreau (jmiven) changed: What|Removed |Added Severity|minor |major --
[Issue 22548] Windows installer for dmd 2.098.0 isn't signed by the DLF
https://issues.dlang.org/show_bug.cgi?id=22548 ryuukk_ changed: What|Removed |Added CC||ryuukk@gmail.com --- Comment #1 from ryuukk_ --- It should be marked as major, that's a security issue --
[Issue 22548] New: Windows installer for dmd 2.098.0 isn't signed by the DLF
https://issues.dlang.org/show_bug.cgi?id=22548 Issue ID: 22548 Summary: Windows installer for dmd 2.098.0 isn't signed by the DLF Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: minor Priority: P1 Component: installer Assignee: nob...@puremagic.com Reporter: jmiven-dlangiss...@algeb.re The dmd 2.098.0 Windows installer[1] hasn't been signed by the D Language Foundation, as it was the case for the previous releases. While probably just an oversight, it would be good to solve this for the next release, since the SmartScreen window is not the best publicity for D. :-) [1] https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2021/dmd-2.098.0.exe --
[Issue 20809] return statement might access memory from destructed temporary
https://issues.dlang.org/show_bug.cgi?id=20809 RazvanN changed: What|Removed |Added Keywords||backend CC||razvan.nitu1...@gmail.com --- Comment #12 from RazvanN --- Most likely this is a backend issue since I cannot reproduce this with ldc. --
[Issue 20753] "Error: unknown" with structs of arrays, speculative instantiation and recursive types
https://issues.dlang.org/show_bug.cgi?id=20753 --- Comment #5 from Vladimir Panteleev --- (In reply to RazvanN from comment #3) > Running the code on run.dlang.io [1], it seems that at some point this code > compiled, but then it issued an error which was transformed into an ICE. So > by "Works in DMD 2.085 but not newer.", I guess you mean that a proper error > is outputted? I can't imagine how this used to work we have a mutual > dependency at semantic between HashCollection and IniFragment. By "works" here I meant "does not crash with -o-", but it does result in various errors with -c. With -c, it succeeds in the version range 2.066.0 to 2.071.2. --
[Issue 20753] "Error: unknown" with structs of arrays, speculative instantiation and recursive types
https://issues.dlang.org/show_bug.cgi?id=20753 --- Comment #4 from RazvanN --- (In reply to RazvanN from comment #3) > Running the code on run.dlang.io [1], it seems that at some point this code > compiled, but then it issued an error which was transformed into an ICE. So > by "Works in DMD 2.085 but not newer.", I guess you mean that a proper error > is outputted? I can't imagine how this used to work we have a mutual > dependency at semantic between HashCollection and IniFragment. > > [1] https://github.com/dlang/dmd/pull/13348#issuecomment-979940003 I'm sorry, but I messed up the link. The proper link is: https://run.dlang.io/is/2qlZvz --
[Issue 20753] "Error: unknown" with structs of arrays, speculative instantiation and recursive types
https://issues.dlang.org/show_bug.cgi?id=20753 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #3 from RazvanN --- Running the code on run.dlang.io [1], it seems that at some point this code compiled, but then it issued an error which was transformed into an ICE. So by "Works in DMD 2.085 but not newer.", I guess you mean that a proper error is outputted? I can't imagine how this used to work we have a mutual dependency at semantic between HashCollection and IniFragment. [1] https://github.com/dlang/dmd/pull/13348#issuecomment-979940003 --
[Issue 20368] dmd 2.089.0 Error: expression `main` is `void` and has no value
https://issues.dlang.org/show_bug.cgi?id=20368 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com Component|dmd |druntime --
[Issue 19000] Building botan library causes segfault in dsymbolsem.d
https://issues.dlang.org/show_bug.cgi?id=19000 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |WORKSFORME --- Comment #5 from RazvanN --- I am not able to reproduce this. Closing as WORKFSFORME. Please reopen if you have a reproducible test case. --
[Issue 22547] New: .dup on array of nested structs can cause null dereference if copy throws
https://issues.dlang.org/show_bug.cgi?id=22547
Issue ID: 22547
Summary: .dup on array of nested structs can cause null
dereference if copy throws
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: stanislav.bli...@gmail.com
As pointed out by @kinke here:
https://forum.dlang.org/post/yfiytdysalmauqadt...@forum.dlang.org
void main() {
int i;
struct S {
// A copy ctor won't currently compile (dmd 2.098)
// due to "cannot access stack frame pointer..."
this(this) { throw new Exception("!!!"); }
~this() { ++i; }
}
auto a1 = [ S() ];
auto a2 = a1.dup; // throws
} // segmentation fault when destructing a2 because a2[0].tupleof[$-1] is null
--
[Issue 22528] [dip1000] scope inference turns return-ref into return-scope
https://issues.dlang.org/show_bug.cgi?id=22528
--- Comment #4 from Dennis ---
(In reply to thomas.bockman from comment #3)
> Why does an inferred restriction in once place effectively remove my
> explicit restriction from another?
Because the implementation is bad, it currently has flags STC.scope_ and
STC.return_ and infers the meaning of STC.return from context. Walter is
working on using STC.returnScope instead, see issue 22541 and
https://github.com/dlang/dmd/pull/13357
> At any
> time the compiler could be upgraded to be smart enough to recognize that
> this line is, in context, a no-op and can be ignored for analysis purposes.
Yes, it relies on issue 20674. I do think this issue will be solved before
that, but you could also add a unittest with `assert(!__traits(compiles, ()
@safe {...}));` to test that escaping a reference isn't allowed, so you'll be
aware when the workaround breaks.
--
