[Issue 24252] New: ci: Error: error writing file 'compilable\testcstuff3_0.obj'
https://issues.dlang.org/show_bug.cgi?id=24252 Issue ID: 24252 Summary: ci: Error: error writing file 'compilable\testcstuff3_0.obj' Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ibuc...@gdcproject.org It looks like CI has a race condition between two files of the same name. --- ... compilable\testcstuff3.i () ... compilable\testcstuff3.d () == Test 'compilable\testcstuff3.d' failed. The logged output: D:\a\1\s\generated\windows\RelWithAsserts\Win32\dmd.exe -conf= -m32mscoff -Icompilable -odD:\a\1\s\compiler\test\test_results\compilable -ofD:\a\1\s\compiler\test\test_results\compilable\testcstuff3_0.obj -c compilable\testcstuff3.d Error: error writing file 'D:\a\1\s\compiler\test\test_results\compilable\testcstuff3_0.obj' == Test 'compilable\testcstuff3.d' failed: Expected rc == 0, but exited with rc == 1 --
[Issue 24159] BetterC: appending to dynamic arrays no longer errors at compile time
https://issues.dlang.org/show_bug.cgi?id=24159 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #15829 "merge stable" was merged into master: - b9f8e7cf24273f2283a39f703b2367c9cb09a0dc by Teodor Dutu: Fix Issue 24159: Store lowering of `CatAssignExp` in a separate field (#15791) This preserves the `CatAssignExp` in the AST until the glue layer where an error is printed in case this expression is used with `-betterC`. This is required to happen in the glue layer as the semantic analysis doesn't correctly distinguish when code needs to be generated. Signed-off-by: Teodor Dutu https://github.com/dlang/dmd/pull/15829 --
[Issue 24184] [REG 2.103] Segmentation fault accessing variable with align(N) > platform stack alignment
https://issues.dlang.org/show_bug.cgi?id=24184 --- Comment #6 from Dlang Bot --- dlang/dmd pull request #15829 "merge stable" was merged into master: - 891cf59b1fd4118cb8c0c02258a9a54e6bb11529 by Walter Bright: fix Issue 24184 - [REG 2.103] Segmentation fault accessing variable with align(N) > platform stack alignment (#15820) https://github.com/dlang/dmd/pull/15829 --
[Issue 24209] static aa initialization of static function variable ICE
https://issues.dlang.org/show_bug.cgi?id=24209 --- Comment #4 from Dlang Bot --- dlang/dmd pull request #15829 "merge stable" was merged into master: - 7e052454e32312723324bcb18ebd6ad8181da2f5 by Dennis: Fix 24209 - static aa initialization of static function variable ICE (#15774) https://github.com/dlang/dmd/pull/15829 --
[Issue 24072] cast(__vector) array literal incorrectly triggers GC error
https://issues.dlang.org/show_bug.cgi?id=24072 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #15829 "merge stable" was merged into master: - 3d552df287d0b836861f760701b16569311e4dd7 by Dennis Korpel: Fix 24072 - cast(__vector) array literal incorrectly triggers GC error https://github.com/dlang/dmd/pull/15829 --
[Issue 24230] Infinite loop in core.cpuid.getCpuInfo0B in Solaris/x86 kernel zone
https://issues.dlang.org/show_bug.cgi?id=24230 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #15829 "merge stable" was merged into master: - 505e475b373a40d81635ee1df16cc1818448bb20 by Iain Buclaw: fix Issue 24230 - Infinite loop in core.cpuid.getCpuInfo0B in Solaris/x86 kernel zone https://github.com/dlang/dmd/pull/15829 --
[Issue 4733] Possible bugs caused by dynamic arrays in boolean evaluation context
https://issues.dlang.org/show_bug.cgi?id=4733 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #38 from Nick Treleaven --- For the record, this post described why the revert happened: https://forum.dlang.org/post/mr540j$1533$1...@digitalmars.com "The main reason why it caused issues is this nice idiom: if(auto arr = someFunction()) { // use arr } This would HAVE to be split out to two statements, and the arr variable would be scoped outside of the if statement." I attempted to make it obsolete: https://github.com/dlang/dmd/pull/15413 But that was rejected. I still think it would be good to do for editions. If that is still a no-go then it seems we need something like: if ((auto arr = expr).ptr) However, would `arr` then be declared in the `else` branch? If so that is still not a replacement for the feature. Another option would be to allow `if (auto arr = expr)` but allow no other uses of an array as a boolean. --
[Issue 14387] Disallow string literals as assert conditions
https://issues.dlang.org/show_bug.cgi?id=14387 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #4 from Dlang Bot --- @ntrel created dlang/dmd pull request #15837 "Deprecate boolean evaluation of array/string literals" fixing this issue: - Deprecate boolean evaluation of array/string literals Fix Issue 14387 - Disallow string literals as assert conditions. https://github.com/dlang/dmd/pull/15837 --
[Issue 11111] std.algorithm.canFind should support Needles...
https://issues.dlang.org/show_bug.cgi?id=1 Dlang Bot changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Dlang Bot --- dlang/phobos pull request #8845 "Fix Issue 1 - std.algorithm.canFind should support Needles..." was merged into master: - a2c2f79dfae38492e2269bcb4e34a6c916c22091 by Nick Treleaven: Fix Issue 1 - std.algorithm.canFind should support Needles... The requirement that each needle must be a range is arbitrary, so remove it. Note: This overload of `canFind` calls `find(haystack, needles)` which calls `startsWith`, which accepts mixed element and range needles. https://github.com/dlang/phobos/pull/8845 --
[Issue 24203] Params section in ddoc comments causes warnings with unnamed parameters
https://issues.dlang.org/show_bug.cgi?id=24203 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #2 from Nick Treleaven --- I think this warning is correct - why have a 'Params' section with no content? --
[Issue 24127] ImportC - no way to organize files
https://issues.dlang.org/show_bug.cgi?id=24127 --- Comment #2 from Steven Schveighoffer --- (In reply to Walter Bright from comment #1) > This boils down to the fact that C files do not have a means to name the > module. I think we're kinda stuck here. ImportC added import statements to C files, why not module statements? --
[Issue 24125] ImportC: vector type initializer not understood
https://issues.dlang.org/show_bug.cgi?id=24125 --- Comment #3 from Steven Schveighoffer --- (In reply to Walter Bright from comment #2) > Looks like there are two problems. The first is: > > typedef float __m128 __attribute__ ((__vector_size__ (16), > __may_alias__)); > > This doesn't recognize __m128 as a vector. But this works: > > typedef float __attribute__ ((__vector_size__ (16), __may_alias__)) > __m128; I may have copied the header code wrong... I'll double check. That does look more reasonable. --
[Issue 24125] ImportC: vector type initializer not understood
https://issues.dlang.org/show_bug.cgi?id=24125 --- Comment #4 from Steven Schveighoffer --- Hm.. nope, that's the exact code. So that does still need addressing. --
[Issue 24203] Params section in ddoc comments causes warnings with unnamed parameters
https://issues.dlang.org/show_bug.cgi?id=24203 --- Comment #3 from elpenguin...@gmail.com --- (In reply to Nick Treleaven from comment #2) > I think this warning is correct - why have a 'Params' section with no > content? There is no warning for an empty Params section. This warning is produced for ``` /// Params: /// a = b void foo(int a, int) {} ``` But it is not produced for ``` /// Params: void foo() {} ``` The example was just the simplest reproduction I could come up with. --
[Issue 24253] New: fn "is not accessible from module" with overload reflection regressed in v2.105
https://issues.dlang.org/show_bug.cgi?id=24253 Issue ID: 24253 Summary: fn "is not accessible from module" with overload reflection regressed in v2.105 Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P5 Component: dmd Assignee: nob...@puremagic.com Reporter: destructiona...@gmail.com Must have two modules so `private` applies: --- // bug.d import bug2; private void fooImpl() { } void main() { mvd!fooImpl(); } --- And: --- // bug2.d void mvd(alias fn)() { auto this_ = null; // we could call `fn` directly here since we got an alias ov: foreach(overload; __traits(getOverloads, __traits(parent, fn), __traits(identifier, fn))) { __traits(child, this_, overload)(); // but cannot use through traits } } --- You actually don't need the overload loop here, you could remove that to minimize further ``` void mvd(alias fn)() { auto this_ = null; fn(); // this allowed //__traits(child, this_, fn)(); // this is not } ``` But I wanted to show the loop to give you an idea of the real world use case this is affecting; it is a multiple virtual dispatch implementation. Interestingly, in dmd 2.098: ``` fn; // bug2.d(3): Deprecation: Function `bug.fooImpl` of type `void()` is not accessible from module `bug2` fn(); // perfectly OK; it let me call it through the alias, but not reference it ``` Which is a bit bizarre. I suspect the fix was intended to treat these two cases the same, but it awkward in any case. Anyway, the error when calling the function was introduced by this commit: https://github.com/dlang/dmd/commit/421ebfe8b507c7a415f64523bedf6ff2dd66 Before that, it worked without issue, after that, it deprecated, then a future commit (36043ded818506936790be55f9353d6132527541) turned the deprecation into an error. The first release to fail with this was https://dlang.org/changelog/2.105.0.html --
[Issue 24132] ImportC: Add support for wchar_t, char16_t, char32_t
https://issues.dlang.org/show_bug.cgi?id=24132 Adam Wilson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Adam Wilson --- I'm going to close this as WON'T FIX. I'll try to attack my problem with a post-processor script. --
[Issue 24125] ImportC: vector type initializer not understood
https://issues.dlang.org/show_bug.cgi?id=24125 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #5 from Dlang Bot --- @WalterBright created dlang/dmd pull request #15838 "Fix Issue 24125 - ImportC: vector type initializer not understood" fixing this issue: - fix Issue 24125 - ImportC: vector type initializer not understood - fix Issue 24125 - ImportC: vector type initializer not understood https://github.com/dlang/dmd/pull/15838 --