[Issue 22300] [REG 2.098-rc.2] `-checkaction=context` of a `shared` type with an `opCast` fails to compile
https://issues.dlang.org/show_bug.cgi?id=22300 --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13203 "Issue 22300 - Allow shared <-> unshared reinterpreting casts during CTFE" was merged into stable: - 80a4215978914d1860263da89884e6799679b36e by MoonlightSentinel: Issue 22300 - Allow shared <-> unshared reinterpreting casts during CTFE CTFE evaluation is single threaded only, hence it's safe to discard the `shared` qualifier in a reinterpreting cast. This change allows `-checkaction=context` to use a reinterpreting cast for compile and runtime - which removes the problematic workaround that caused the regression. https://github.com/dlang/dmd/pull/13203 --
[Issue 22430] OpenBSD: Add OpenBSD to the timezone unittest
https://issues.dlang.org/show_bug.cgi?id=22430 Brian Callahan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Brian Callahan --- Fixed in https://github.com/dlang/phobos/commit/089a3b8dc4a194f370e751bb871f82de0cd61069 --
[Issue 22430] New: OpenBSD: Add OpenBSD to the timezone unittest
https://issues.dlang.org/show_bug.cgi?id=22430 Issue ID: 22430 Summary: OpenBSD: Add OpenBSD to the timezone unittest Product: D Version: D2 Hardware: All OS: Other Status: NEW Severity: trivial Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: bcal...@openbsd.org The unittest in std/datetime/timezone.d needlessly failed because OpenBSD isn't in the OS list. --
[Issue 21022] std.range.only does not work with const
https://issues.dlang.org/show_bug.cgi?id=21022 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #8271 "Fix issue 21022 - only should work with qualifiers" was merged into master: - 769299f70b03a05a817843b331af9f42f919a486 by Ate Eskola: Fix issue 21022 - only should work with qualifiers https://github.com/dlang/phobos/pull/8271 --
[Issue 22411] importC: Error: cannot implicitly convert expression of type 'const(char*)' to 'char*'
https://issues.dlang.org/show_bug.cgi?id=22411 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #13186 "fix Issue 22411 - importC: Error: cannot implicitly convert expression of type 'const(char*)' to 'char*'" was merged into stable: - 0b71439a16714679fa7eb26751fd55cedb8017a3 by Iain Buclaw: fix Issue 22411 - importC: Error: cannot implicitly convert expression of type 'const(char*)' to 'char*' https://github.com/dlang/dmd/pull/13186 --
[Issue 21157] DWARF: DW_TAG_decl_file and DW_TAG_decl_line are not produced
https://issues.dlang.org/show_bug.cgi?id=21157 --- Comment #2 from Dlang Bot --- @ljmf00 created dlang/dmd pull request #13204 "backend: dwarf: add DW_AT_decl attributes to variables" mentioning this issue: - backend: dwarfdbginf: add DW_AT_decl attributes to DW_TAG_variable tags Fixe issue #21157 . Signed-off-by: Luís Ferreira https://github.com/dlang/dmd/pull/13204 --
[Issue 22350] std.process unit test sometimes fails on FreeBSD
https://issues.dlang.org/show_bug.cgi?id=22350 --- Comment #2 from Paul Backus --- Spotted again here: https://github.com/dlang/druntime/pull/3593 https://auto-tester.puremagic.com/show-run.ghtml?projectid=1=5016811=true --
[Issue 17037] std.concurrency has random segfaults
https://issues.dlang.org/show_bug.cgi?id=17037 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dlang Bot --- dlang/phobos pull request #5004 "Fix issue 17037 - std.concurrency has random segfaults" was merged into master: - 2c6051da1023f535544de5f575c013803286f62c by WalterW: Fix issue 17037 - std.concurrency has random segfaults https://github.com/dlang/phobos/pull/5004 --
[Issue 22429] New: importC: designator-list not supported yet
https://issues.dlang.org/show_bug.cgi?id=22429
Issue ID: 22429
Summary: importC: designator-list not supported yet
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
```
int a[2] = {
[0] = 1,
[1] = 2,
};
```
```
parser.c(2): Error: C designator-list not supported yet
```
Needed for compiling tree-sitter parsers, for example:
https://github.com/tree-sitter/tree-sitter-json/blob/master/src/parser.c
--
[Issue 18110] most of phobos should be @safe-ly useable
https://issues.dlang.org/show_bug.cgi?id=18110 Issue 18110 depends on issue 18187, which changed state. Issue 18187 Summary: std.uni.Grapheme should be usable in @safe https://issues.dlang.org/show_bug.cgi?id=18187 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 22428] New: importC: static variables/functions emit global symbols
https://issues.dlang.org/show_bug.cgi?id=22428
Issue ID: 22428
Summary: importC: static variables/functions emit global
symbols
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
dmd emits global symbols even for static variables / functions:
```
static int staticVar;
int globalVar;
static void staticFunc() {
static int staticVar;
}
```
```
dmd -c -betterC staticvar.c
nm staticvar.o
t
0008 B _D9staticvar10staticFuncUY14staticLocalVari
0004 B globalVar
W staticFunc
B staticVar
```
B = global, BSS section
W = global, weak symbol
For reference, Clang doesn't emit those symbols and GCC emits local symbols.
```
0004 C globalVar
t staticFunc
0004 b staticLocalVar.1959
b staticVar
```
This is a wontfix for D (issue 7083), but for C this is essential for when
there are multiple `static` functions with the same name but different
implementations. For example `my_flush_events` for different audio backends in
libsoundio:
https://github.com/andrewrk/libsoundio/search?q=my_flush_events
--
[Issue 18187] std.uni.Grapheme should be usable in @safe
https://issues.dlang.org/show_bug.cgi?id=18187 RazvanN changed: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |FIXED --
[Issue 22300] [REG 2.098-rc.2] `-checkaction=context` of a `shared` type with an `opCast` fails to compile
https://issues.dlang.org/show_bug.cgi?id=22300 --- Comment #1 from Dlang Bot --- @MoonlightSentinel created dlang/dmd pull request #13203 "Issue 22300 - Allow shared <-> unshared reinterpreting casts during CTFE" mentioning this issue: - Issue 22300 - Allow shared <-> unshared reinterpreting casts during CTFE CTFE evaluation is single threaded only, hence it's safe to discard the `shared` qualifier in a reinterpreting cast. This change allows `-checkaction=context` to use a reinterpreting cast for compile and runtime - which removes the problematic workaround that caused the regression. https://github.com/dlang/dmd/pull/13203 --
[Issue 22365] Compiler crash: tcs.body_ null in StatementSemanticVisitor.visit(TryCatchStatement) in semantic3 pass (dmd/statementsem.d:3956)
https://issues.dlang.org/show_bug.cgi?id=22365
--- Comment #2 from evilrat...@gmail.com ---
(In reply to RazvanN from comment #1)
> The chances of this bug getting fixed without a minimal reproducible test
> case are small. Maybe you can use DustMite [1] to reduce it?
>
> [1]
> https://dlang.org/blog/2020/04/13/dustmite-the-general-purpose-data-
> reduction-tool/
nope, unfortunately I wasn't able to reduce it yet, this is a complex library
with tons of dependencies and it is happily reduces it down to 'import ;'.
I'll try again later, meanwhile I traced down the issue and ready to submit
possible fix (I hope that's a real fix and not just symptoms mending) PR after
I double check everything.
Here is an overview
-
dmd issue 22365
calls:
[1] semantic3.d:1369 Semantic3Visitor.visit(CtorDeclaration) at 1446
TryCatchStatemt generation
[2] semantic3.d:208 Semantic3Visitor.visit(FuncDeclaration) at 595
statementSemantic(funcdecl.fbody, sc2) call
[3] statementsem.d:148 statementSemantic(Statement, Scope*) at 145
StatementSemanticVisitor.accept()
[4] statement.d:1580 TryCatchStatemt.accept (just in case)
[5] statementsem.d:3936 StatementSemanticVisitor.visit(TryCatchStatemt) at
3957 semanticScope() <--- here, returns wrong scope
[6] statementsem.d:4486 semanticScope(Statement, Scope*, Statement,
Statement, Statement) <--- push & pop the same scope?
[7] statementsem.d:4473 semanticNoScope(Statement, Scope*) at 4468
statementSemantic() returns null which triggers assert above
[8] statementsem.d:236 StatementSemanticVisitor.visit(CompoundStatent)
at 257-264 flatten() and then statementSemantic()
[9] statementsem.d:4631 flatten(Statement, Scope*) probably at 4720
if condition
specifically look:
[5]
https://github.com/dlang/dmd/blob/96b959e27c690f5e3abf411f8032c60f4728c1c1/src/dmd/statementsem.d#L3936
[6]
https://github.com/dlang/dmd/blob/96b959e27c690f5e3abf411f8032c60f4728c1c1/src/dmd/statementsem.d#L4497
so, at step 6 when using debbuger after semanticNoScope() restore s (null at
this moment) back to original s (from function argument), now it works as
expected
> s = s.semanticNoScope(scd); // <- null
> /* restore s */
> scd.pop();
> return s;
tracing it further...
[8]
https://github.com/dlang/dmd/blob/96b959e27c690f5e3abf411f8032c60f4728c1c1/src/dmd/statementsem.d#L255
calling flatten() produces Statements[] array with single null element which is
then returned as valid result here around line 420
> if (cs.statements.length == 1)
> {
> result = (*cs.statements)[0];
> return;
> }
[9]
https://github.com/dlang/dmd/blob/96b959e27c690f5e3abf411f8032c60f4728c1c1/src/dmd/statementsem.d#L4726
debug condition doesn't get picked up and returns that Statements[] array with
single null element afterwards
> if (cs.condition.include(sc))
can be fixed with adding else if check for null and else return 0 here
https://github.com/dlang/dmd/blob/96b959e27c690f5e3abf411f8032c60f4728c1c1/src/dmd/statementsem.d#L4737
this doesn't happens when adding debug else condition to original problem
source, or replacing debug with version (all/none) or anything else, so there
is a logic issue related to debug ConditionStatement somewhere
--
[Issue 22403] importC: Error: cannot pass argument '0' of type 'int' to parameter 'const(char)*'
https://issues.dlang.org/show_bug.cgi?id=22403 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #13185 "fix Issue 22403 - importC: Error: cannot pass argument '0' of type 'int' to parameter 'const(char)*'" was merged into stable: - 07648ef4aa84a8a2b30e16cb38c276d1c2053b50 by Iain Buclaw: fix Issue 22403 - importC: Error: cannot pass argument '0' of type 'int' to parameter 'const(char)*' https://github.com/dlang/dmd/pull/13185 --
[Issue 22404] importC: Error: cannot pass argument 'ENUMMEM' of type 'int' to parameter '__tag2'
https://issues.dlang.org/show_bug.cgi?id=22404 Dlang Bot changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13185 "fix Issue 22403 - importC: Error: cannot pass argument '0' of type 'int' to parameter 'const(char)*'" was merged into stable: - c3bfd18fbbcae6527879a3c1d051f34260b68136 by Iain Buclaw: fix Issue 22404 - importC: Error: cannot pass argument 'ENUMMEM' of type 'int' to parameter '__tag2' https://github.com/dlang/dmd/pull/13185 --
[Issue 22425] Documentation on implicit conversion of arrays is incomplete
https://issues.dlang.org/show_bug.cgi?id=22425 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3114 "Fix issue 22425 - Documentation on implicit conversion of arrays is i…" was merged into master: - d6bbdf6a1c828ea6376ceed250aec7699fdd203d by Paul Backus: Fix issue 22425 - Documentation on implicit conversion of arrays is incomplete https://github.com/dlang/dlang.org/pull/3114 --
[Issue 22419] Allow return type inference for main
https://issues.dlang.org/show_bug.cgi?id=22419 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dlang Bot --- dlang/dmd pull request #13195 "Fix 22419 - Allow inferred return type for main" was merged into master: - 8db36eadfcd72a30e4968f1d068f423cc96c190d by MoonlightSentinel: Fix 22419 - Allow inferred return type for main `auto main()` is fine iff return type inference resolves `auto` to one of the allowed return types (`void`, `int`, `noreturn`). Deferring the check after the return type inference removes this arbitrary limitation and allows for more flexible code. E.g. to use the upcoming `noreturn` inference and the associated codegen improvements. https://github.com/dlang/dmd/pull/13195 --
[Issue 22420] [REG2.098] Apparent CTFE regression wrt. alias this
https://issues.dlang.org/show_bug.cgi?id=22420 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13198 "Fix Issue 22420 - [REG2.098] Apparent CTFE regression wrt. alias this" was merged into stable: - 8f9a30f4f74359d80010ad6a671f5ddd8ead77e0 by Boris Carvajal: Fix Issue 22420 - [REG2.098] Apparent CTFE regression wrt. alias this https://github.com/dlang/dmd/pull/13198 --
[Issue 22397] Out of memory during compilation
https://issues.dlang.org/show_bug.cgi?id=22397 Imperatorn changed: What|Removed |Added CC||johan_forsberg_86@hotmail.c ||om Severity|normal |minor --
[Issue 22414] clamp(a, b, c) should always return typeof(a)
https://issues.dlang.org/show_bug.cgi?id=22414 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #8293 "Fix Issue 22414 - clamp(a, b, c) should always return typeof(a)" was merged into master: - 3041b3768b7df8e370e59794fbc95e2ed69bc182 by Andrei Alexandrescu: Fix Issue 22414 - clamp(a, b, c) should always return typeof(a) https://github.com/dlang/phobos/pull/8293 --
[Issue 22396] Assignments from function value parameters should pass by move when possible
https://issues.dlang.org/show_bug.cgi?id=22396 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- This sort of analysis was proposed in the move constructor DIP: https://github.com/dlang/DIPs/blob/a9c553b0dbab1c2983a801b5e89b51c5c33d5180/DIPs/DIP1040.md (Last Use chapter). Until the DIP is accepted and implemented this will probably not be solved. --
