[Issue 23106] the simple main() leaks 72 bytes
https://issues.dlang.org/show_bug.cgi?id=23106 --- Comment #1 from Basile-z --- ==117347== Memcheck, a memory error detector ==117347== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==117347== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info ==117347== Command: /tmp/temp_7F336C18C4D0 ==117347== ==117347== realloc() with size 0 ==117347==at 0x4848A40: realloc (vg_replace_malloc.c:1649) ==117347==by 0x4389F1: rt.minfo.ModuleGroup.sortCtors(immutable(char)[]) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x439608: rt.minfo.ModuleGroup.sortCtors() (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4398DC: rt.minfo.rt_moduleCtor().__foreachbody1(ref rt.sections_elf_shared.DSO) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x439D31: rt.sections_elf_shared.DSO.opApply(scope int(ref rt.sections_elf_shared.DSO) delegate) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4398BC: rt_moduleCtor (in /tmp/temp_7F336C18C4D0) ==117347==by 0x436F39: rt_init (in /tmp/temp_7F336C18C4D0) ==117347==by 0x433BD7: rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).runAll() (in /tmp/temp_7F336C18C4D0) ==117347==by 0x433B75: rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).tryExec(scope void() delegate) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x433ADE: _d_run_main2 (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4338C7: _d_run_main (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4337E1: main (entrypoint.d:29) ==117347== Address 0x4b50c00 is 0 bytes inside a block of size 104 alloc'd ==117347==at 0x484382F: malloc (vg_replace_malloc.c:431) ==117347==by 0x438947: rt.minfo.ModuleGroup.sortCtors(immutable(char)[]) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x439608: rt.minfo.ModuleGroup.sortCtors() (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4398DC: rt.minfo.rt_moduleCtor().__foreachbody1(ref rt.sections_elf_shared.DSO) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x439D31: rt.sections_elf_shared.DSO.opApply(scope int(ref rt.sections_elf_shared.DSO) delegate) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4398BC: rt_moduleCtor (in /tmp/temp_7F336C18C4D0) ==117347==by 0x436F39: rt_init (in /tmp/temp_7F336C18C4D0) ==117347==by 0x433BD7: rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).runAll() (in /tmp/temp_7F336C18C4D0) ==117347==by 0x433B75: rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).tryExec(scope void() delegate) (in /tmp/temp_7F336C18C4D0) ==117347==by 0x433ADE: _d_run_main2 (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4338C7: _d_run_main (in /tmp/temp_7F336C18C4D0) ==117347==by 0x4337E1: main (entrypoint.d:29) ==117347== ==117347== ==117347== HEAP SUMMARY: ==117347== in use at exit: 72 bytes in 2 blocks ==117347== total heap usage: 101 allocs, 99 frees, 9,040 bytes allocated ==117347== ==117347== LEAK SUMMARY: ==117347==definitely lost: 0 bytes in 0 blocks ==117347==indirectly lost: 0 bytes in 0 blocks ==117347== possibly lost: 0 bytes in 0 blocks ==117347==still reachable: 72 bytes in 2 blocks ==117347== suppressed: 0 bytes in 0 blocks ==117347== Rerun with --leak-check=full to see details of leaked memory ==117347== ==117347== For lists of detected and suppressed errors, rerun with: -s ==117347== ERROR SUMMARY: 16 errors from 1 contexts (suppressed: 0 from 0) [basile@pc styx]$ --
[Issue 23106] the simple main() leaks 72 bytes
https://issues.dlang.org/show_bug.cgi?id=23106 Basile-z changed: What|Removed |Added Summary|the simple main() leaks 96 |the simple main() leaks 72 |bytes |bytes --
[Issue 16497] suboptimal moves between SSE registers
https://issues.dlang.org/show_bug.cgi?id=16497 Basile-z changed: What|Removed |Added Keywords||backend OS|All |Linux --
[Issue 21449] PrimaryExp `TypeCtor( Type )( ArgumentList)` is rejected when used alone in a ExpStatement
https://issues.dlang.org/show_bug.cgi?id=21449 Basile-z changed: What|Removed |Added Severity|enhancement |normal --
[Issue 23074] premature enum type inference leads to spurious error message
https://issues.dlang.org/show_bug.cgi?id=23074 Basile-z changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Basile-z --- maybe at least the circular reference could be detected. That'd give a better error message. --
[Issue 23579] static locals cannot be initialized with stack locals
https://issues.dlang.org/show_bug.cgi?id=23579 Basile-z changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --
[Issue 6032] wstring literals cannot be implicitly converted to const(wchar)*
https://issues.dlang.org/show_bug.cgi?id=6032 --- Comment #8 from Dlang Bot --- dlang/dlang.org pull request #3662 "[spec] Improve string literal docs" was merged into master: - 0ca0e63d81fc14b1610625693ee6aa9fd475f6c1 by Nick Treleaven: Document that StringPostfix disables implicit conversions Part of Issue 6032 - wstring literals cannot be implicitly converted to const(wchar)* https://github.com/dlang/dlang.org/pull/3662 --
[Issue 24047] New: compiler accepts unparseable code for unittests when -unittest is not provided
https://issues.dlang.org/show_bug.cgi?id=24047
Issue ID: 24047
Summary: compiler accepts unparseable code for unittests when
-unittest is not provided
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Keywords: accepts-invalid
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
without -unittest switch, this compiles:
```d
unittest anything goes here, even open parentheses without matching ones: (
{
stuff in here can be complete garbage as well???!!!
}
```
The grammar states that Unittest should be:
```
Unittest:
unittest BlockStatement
```
So really, nothing but whitespace should be allowed between the `unittest`
keyword and the opening brace, and the block statement should be valid D
grammar.
I get that the unittest itself can be skipped, and while I can understand a
small benefit from avoiding the parsing of the function itself, I don't believe
there's any other place where unparseable text is allowed. Even with templates
that aren't instantiated, or inside version(none) blocks.
I believe the code above should not compile, even when -unittest is not
specified.
--
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934 --- Comment #14 from Dlang Bot --- dlang/dlang.org pull request #3619 "[spec/function] Improve `return` struct method attribute docs" was merged into master: - 17763b0db20cc9978cc8729bd13f96f2987b by Nick Treleaven: [spec/function] Document `return` parameters without `scope` Part of Issue 17934 - [scope] scopeness entrypoint for unique/ref-counted missing. Add 'Struct Return Methods' subheading. https://github.com/dlang/dlang.org/pull/3619 --
[Issue 23957] Casting to derived extern(C++) class is unsafe
https://issues.dlang.org/show_bug.cgi?id=23957 --- Comment #4 from Dlang Bot --- @ntrel updated dlang/dmd pull request #15293 "Disallow dynamic cast to extern(C++) class" fixing this issue: - Fix Issue 23957 - Casting to derived extern(C++) class is unsafe https://github.com/dlang/dmd/pull/15293 --
[Issue 22427] betterC: casting an array causes linker error in string comparison.
https://issues.dlang.org/show_bug.cgi?id=22427 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dlang Bot --- dlang/dmd pull request #15404 "Fix Issue 22427 - betterC: casting an array causes linker error in string comparison" was merged into master: - bab58df92fa67c4702bf001c8258ff2eeb4643bc by RazvanN7: Fix Issue 22427 - betterC: casting an array causes linker error in string comparison - 9e1ba7b233a73941ec094d60b226af92618301d8 by RazvanN7: Fix Issue 22427 - betterC: casting an array causes linker error in string comparison https://github.com/dlang/dmd/pull/15404 --
[Issue 21034] concatenation with a string literal could also append the trailing null
https://issues.dlang.org/show_bug.cgi?id=21034 --- Comment #2 from Basile-z --- More simply: the result of `LHS ~ RHS` should be guaranteed to be zero terminated when RHS is a StringExp. --
[Issue 21034] concatenation with a string literal could also append the trailing null
https://issues.dlang.org/show_bug.cgi?id=21034 Salih Dincer changed: What|Removed |Added CC||sali...@hotmail.com --
[Issue 21034] concatenation with a string literal could also append the trailing null
https://issues.dlang.org/show_bug.cgi?id=21034 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- The assert would fail anyway, because "0123" is immutable data. When you assign "0" to s, that is different memory and cannot affect c. Presumably this request is for: s = "0"; s = s ~ "1"; assert(s.ptr[2] == '\0'); That would cause unnecessary writes when appending a (short) string in a loop and each null byte is not read. --
[Issue 11900] Implicit cast of string literal -> char* causing ambiguous call
https://issues.dlang.org/show_bug.cgi?id=11900 Nick Treleaven changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #9 from Nick Treleaven --- *** Issue 18875 has been marked as a duplicate of this issue. *** --
[Issue 18875] String literals can't disambiguate between const(char)[] and const(char)* overload.
https://issues.dlang.org/show_bug.cgi?id=18875 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |DUPLICATE --- Comment #1 from Nick Treleaven --- > At the very least there has to be something in the spec about this. See: https://issues.dlang.org/show_bug.cgi?id=11900#c8 *** This issue has been marked as a duplicate of issue 11900 *** --
[Issue 11900] Implicit cast of string literal -> char* causing ambiguous call
https://issues.dlang.org/show_bug.cgi?id=11900 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org Severity|normal |enhancement --- Comment #8 from Nick Treleaven --- The spec does say: > String literals can implicitly convert to any of the following types, *they > have equal weight* https://dlang.org/spec/expression.html#string_literals So changing this to an enhancement. --
[Issue 6032] wstring literals cannot be implicitly converted to const(wchar)*
https://issues.dlang.org/show_bug.cgi?id=6032 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #7 from Nick Treleaven --- Changed the pull not to close this issue. --
[Issue 6032] wstring literals cannot be implicitly converted to const(wchar)*
https://issues.dlang.org/show_bug.cgi?id=6032 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #6 from Dlang Bot --- @ntrel updated dlang/dlang.org pull request #3662 "[spec] Improve string literal docs" fixing this issue: - Fix Issue 6032 - wstring literals cannot be implicitly converted to const(wchar)* Until this works, it should not be documented. https://github.com/dlang/dlang.org/pull/3662 --
[Issue 13063] `enum` is allowed as storage class for functions
https://issues.dlang.org/show_bug.cgi?id=13063 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/dmd pull request #15405 "Fix Issue 13063 - `enum` is allowed as storage class for functions" was merged into master: - a0b455cf1a262ccff6c808c2d4c37236d8629dbc by Nick Treleaven: Fix Issue 13063 - `enum` is allowed as storage class for functions https://github.com/dlang/dmd/pull/15405 --
[Issue 23951] "alias this" not properly dereferenced when the object being looked up is a field of a type
https://issues.dlang.org/show_bug.cgi?id=23951 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #15406 "Fix Issues 23951 and 23279 - traits(hasMember) does not follow alias this + ICE when using traits(hasMember) on an erroneous member" was merged into stable: - b62b5066b4c797af42500be0ef6cca804c779e30 by RazvanN7: Fix Issue 23951 - traits(getMember) does not follow alias this https://github.com/dlang/dmd/pull/15406 --
[Issue 23279] Segmentation fault on mixin template + using unknown type
https://issues.dlang.org/show_bug.cgi?id=23279 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dlang Bot --- dlang/dmd pull request #15406 "Fix Issues 23951 and 23279 - traits(hasMember) does not follow alias this + ICE when using traits(hasMember) on an erroneous member" was merged into stable: - 1ad55f16b699d077c05034fe0678a5a05a73ed8a by RazvanN7: Fix Issue 23279 - ICE when using traits(hasMember) with an erroneous member https://github.com/dlang/dmd/pull/15406 --
[Issue 24046] static destructors should be allowed in function bodies
https://issues.dlang.org/show_bug.cgi?id=24046 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- Maybe an alternative would be for the compiler to automatically call the destructor of all static variables once the program ends. --
[Issue 7184] parse error on *(x)++
https://issues.dlang.org/show_bug.cgi?id=7184 Dlang Bot changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Dlang Bot --- dlang/dmd pull request #15410 "Fix Issue 7184 - parse error on *(x)++" was merged into master: - 50e5492929f4afe27177824371407094d93029dc by Nick Treleaven: Fix Issue 7184 - parse error on *(x)++ https://github.com/dlang/dmd/pull/15410 --
