[Issue 22845] DWARF .debug_line section is not standard compliant
https://issues.dlang.org/show_bug.cgi?id=22845 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13752 "Fix issue 22845: DWARF .debug_line section is not standard compliant" was merged into master: - a969b998e59ed730915f19b9d27d694304f096c1 by Luís Ferreira: Fix issue 22845: DWARF .debug_line section is not standard compliant According to DWARF standard, DW_LNS_set_isa standard opcode takes one operand, the generator is reporting 0, wrongly. Signed-off-by: Luís Ferreira https://github.com/dlang/dmd/pull/13752 --
[Issue 22845] DWARF .debug_line section is not standard compliant
https://issues.dlang.org/show_bug.cgi?id=22845 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ljmf00 created dlang/dmd pull request #13752 "Fix issue 22845: DWARF .debug_line section is not standard compliant" fixing this issue: - Fix issue 22845: DWARF .debug_line section is not standard compliant According to DWARF standard, DW_LNS_set_isa standard opcode takes one operand, the generator is reporting 0, wrongly. Signed-off-by: Luís Ferreira https://github.com/dlang/dmd/pull/13752 --
[Issue 22845] New: DWARF .debug_line section is not standard compliant
https://issues.dlang.org/show_bug.cgi?id=22845 Issue ID: 22845 Summary: DWARF .debug_line section is not standard compliant Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: cont...@lsferreira.net GNU dwarfdump can't print .debug_line section due to bad opcodes operand: -- dwarfdump ERROR: ERROR: dwarf_srcfiles problem : DW_DLE_LINE_NUM_OPERANDS_BAD (56). Attempting to continue. CU Name = CU Producer = Digital Mars D v2.099.0-rc.1-70-g9d1fb6f6c-dirty DIE OFF = 0x000b GOFF = 0x000b, Low PC = unknown , High PC = unknown .debug_line: line number info for a single cu dwarfdump ERROR: dwarf_srclines: DW_DLE_LINE_NUM_OPERANDS_BAD (56). Attempting to continue. CU Name = CU Producer = Digital Mars D v2.099.0-rc.1-70-g9d1fb6f6c-dirty DIE OFF = 0x000b GOFF = 0x000b, Low PC = unknown , High PC = unknown There were 2 DWARF errors reported: see ERROR above. --
[Issue 22793] importC: __import conflicts when importing multiple modules with same package
https://issues.dlang.org/show_bug.cgi?id=22793 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13747 "fix Issue 22793 - importC: __import conflicts when importing multiple…" was merged into master: - f9b9114af669996168af668544b1aa9e8163a704 by Walter Bright: fix Issue 22793 - importC: __import conflicts when importing multiple modules with same package https://github.com/dlang/dmd/pull/13747 --
[Issue 22802] [dip1000] First ref parameter seen as `return` destination even with `this`
https://issues.dlang.org/show_bug.cgi?id=22802 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13748 "Fix issue 22802 - First ref parameter seen as `return` destination ev…" was merged into master: - 8553e1e02da58e5f6d3c9818693b3af9d18e2b01 by Dennis Korpel: Fix issue 22802 - First ref parameter seen as `return` destination even with `this` https://github.com/dlang/dmd/pull/13748 --
[Issue 22844] New: [REG 2.089] SIGBUS, Bus error in _d_newitemU
https://issues.dlang.org/show_bug.cgi?id=22844 Issue ID: 22844 Summary: [REG 2.089] SIGBUS, Bus error in _d_newitemU Product: D Version: D2 Hardware: Other OS: Linux Status: NEW Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ibuc...@gdcproject.org Introduced by https://github.com/dlang/druntime/pull/2755 See: https://github.com/rainers/druntime/blob/441376bb34651c12a97bfa20c20ccc7078fa7990/src/rt/lifetime.d#L1131 --
[Issue 22841] importC: Error: variable 'var' is shadowing variable 'var'
https://issues.dlang.org/show_bug.cgi?id=22841 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13750 "fix Issue 22841 - importC: Error: variable 'var' is shadowing variable 'var'" was merged into master: - 2544758390e0f7598ac4bc1a1b1d382d790da49b by Iain Buclaw: fix Issue 22841 - importC: Error: variable 'var' is shadowing variable 'var' https://github.com/dlang/dmd/pull/13750 --
[Issue 22843] New: Program hangs on full gc collect with --DRT-gcopt=fork:1 if run under valgrind/callgrind
https://issues.dlang.org/show_bug.cgi?id=22843
Issue ID: 22843
Summary: Program hangs on full gc collect with
--DRT-gcopt=fork:1 if run under valgrind/callgrind
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: zor...@gmail.com
Manjaro/Arch x86_64, dmd 2.098.1, ldc 1.28.1.
When the new forking garbage collector is enabled, the program hangs on what I
imagine is the first collection, if run under the valgrind/callgrind profiler.
```d
import std.string : succ;
extern(C) __gshared string[] rt_options = [ "gcopt=profile:1 fork:1
initReserve:0 minPoolSize:0" ];
void main()
{
string[string] aa;
string key = "a";
foreach (immutable i; 0..1_000)
{
aa[key] = key;
key = key.succ;
}
}
```
```
$ dmd fork.d && valgrind --tool=callgrind ./fork
==799709== Callgrind, a call-graph generating cache profiler
==799709== Copyright (C) 2002-2017, and GNU GPL'd, by Josef Weidendorfer et al.
==799709== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==799709== Command: ./fork
==799709==
==799709== For interactive control, run 'callgrind_control -h'.
[hangs here, 100% cpu use until Ctrl+C]
```
```
$ callgrind_control -b | ddemangle
PID 799709: ./fork
sending command status internal to pid 799709
Frame: Backtrace for Thread 1
[ 0] clock_gettime@@GLIBC_2.17 (32260048 x)
[ 1] nothrow ulong
core.internal.gc.impl.conservative.gc.Gcx.fullcollect(bool, bool, bool) (1 x)
[ 2] nothrow void*
core.internal.gc.impl.conservative.gc.Gcx.smallAlloc(ulong, ref ulong, uint,
const(TypeInfo)) (2 x)
[ 3] nothrow void*
core.internal.gc.impl.conservative.gc.ConservativeGC.runLocked!(core.internal.gc.impl.conservative.gc.ConservativeGC.mallocNoSync(ulong,
uint, ref ulong, const(
TypeInfo)), core.internal.gc.impl.conservative.gc.mallocTime,
core.internal.gc.impl.conservative.gc.numMallocs, ulong, uint, ulong,
const(TypeInfo)).runLocked(ref ulong, ref uint, ref
ulong, ref const(TypeInfo)) (1 x)
[ 4] nothrow void*
core.internal.gc.impl.conservative.gc.ConservativeGC.calloc(ulong, uint,
const(TypeInfo)) (1 x)
[ 5] _THUNK16 (1 x)
[ 6] gc_calloc (1 x)
[ 7] ref rt.aaA.Impl rt.aaA.Impl.__ctor(scope
const(TypeInfo_AssociativeArray), ulong) (1 x)
[ 8] _aaGetX (1 x)
[ 9] _aaGetY (1 x)
[10] _Dmain (1 x)
[11] void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int
function(char[][])*).runAll().__lambda2() (1 x)
[12] void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int
function(char[][])*).tryExec(scope void delegate()) (1 x)
[13] void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int
function(char[][])*).runAll() (1 x)
[14] void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int
function(char[][])*).tryExec(scope void delegate()) (1 x)
[15] _d_run_main2 (1 x)
[16] __alloca (1 x)
[17] _d_run_main2 (1 x)
[18] _d_run_main (1 x)
[19] __alloca (1 x)
[20] _d_run_main (1 x)
[21] main (1 x)
[22] (below main) (1 x)
[23] __libc_start_main@@GLIBC_2.34 (1 x)
[24] (below main) (1 x)
[25] 0x0001d930
```
I could reproduce it with both dmd and ldc, though naturally the backtrace
differs slightly between them. It does not happen with `--DRT-gcopt="fork:0"`.
--
[Issue 22031] crt_constructor functions can't initialize immutable/const variables
https://issues.dlang.org/show_bug.cgi?id=22031 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @MoonlightSentinel created dlang/dmd pull request #13751 "Fix 22031 - Allow modification of non-mutable in `crt_[con|de]structor`'s" fixing this issue: - Fix 22031 - Allow modification of non-mutable in `crt_[con|de]structor`'s Allow functions marked as `pragma(crt_[con|de]structor)` to modify `const` / `immutable` variables, which is currently restricted to module ctors / dtors. This enables the use of lazily initialized global constants for applications without druntime. Such function may not be called at runtime because they might violate the guarantees of `const` / `immutable`. Hence it is now an error to call a function marked as `pragma(crt_[con|de]structor)`. https://github.com/dlang/dmd/pull/13751 --
[Issue 22825] #line parsing doesn't follow the spec
https://issues.dlang.org/show_bug.cgi?id=22825 Iain Buclaw changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Iain Buclaw --- Spec was merged, not the bug fix. --
[Issue 22841] importC: Error: variable 'var' is shadowing variable 'var'
https://issues.dlang.org/show_bug.cgi?id=22841 Iain Buclaw changed: What|Removed |Added Keywords||rejects-valid --
[Issue 22842] importC: Error: variable 'fun' cannot be declared to be a function
https://issues.dlang.org/show_bug.cgi?id=22842 Iain Buclaw changed: What|Removed |Added Keywords||ImportC, rejects-valid CC||ibuc...@gdcproject.org --
[Issue 22842] New: importC: Error: variable 'fun' cannot be declared to be a function
https://issues.dlang.org/show_bug.cgi?id=22842
Issue ID: 22842
Summary: importC: Error: variable 'fun' cannot be declared to
be a function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
Declaring functions has two equivalent syntaxes.
---
int fun();
---
typedef int (tfunc)();
tfunc fun;
---
The latter is however rejected by the compiler.
Related code results in "Error: function 'fun' conflicts with variable 'fun'"
---
typedef int (myfunc)();
static myfunc fun;
int main()
{
return fun();
}
int fun() // inherits "static" from declaration.
{
return 0;
}
--
[Issue 22841] importC: Error: variable 'var' is shadowing variable 'var'
https://issues.dlang.org/show_bug.cgi?id=22841 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @ibuclaw created dlang/dmd pull request #13750 "fix Issue 22841 - importC: Error: variable 'var' is shadowing variable 'var'" fixing this issue: - fix Issue 22841 - importC: Error: variable 'var' is shadowing variable 'var' https://github.com/dlang/dmd/pull/13750 --
[Issue 22841] importC: Error: variable 'var' is shadowing variable 'var'
https://issues.dlang.org/show_bug.cgi?id=22841 Iain Buclaw changed: What|Removed |Added Keywords||ImportC CC||ibuc...@gdcproject.org --
[Issue 22841] New: importC: Error: variable 'var' is shadowing variable 'var'
https://issues.dlang.org/show_bug.cgi?id=22841
Issue ID: 22841
Summary: importC: Error: variable 'var' is shadowing variable
'var'
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
Shadowing in C11 is not forbidden, but can be warned about.
---
void test()
{
int i;
{ unsigned i; }
}
--
[Issue 22770] C++ header generator generates trailing newlines
https://issues.dlang.org/show_bug.cgi?id=22770 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13649 "Fix issue 22770: C++ header generator generates trailing newlines" was merged into master: - 5e32ea6aec91c6829027803a8c408f8cc0939af3 by Luís Ferreira: Fix issue 22770: C++ header generator generates trailing newlines This patch adds logic to check for trailing newlines in dtoh generator and remove them. Signed-off-by: Luís Ferreira https://github.com/dlang/dmd/pull/13649 --
[Issue 22838] std.bitmanip.BitArray.count() reads beyond data when data size is integer size_t multiple
https://issues.dlang.org/show_bug.cgi?id=22838 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dlang Bot --- dlang/phobos pull request #8401 "Fix 22838 - BitArray.count reads beyond data" was merged into stable: - 292c38c43267829c7776e27d71da962eebeae405 by Johan Engelen: Fix 22838 - BitArray.count reads beyond data This fixes issue 22838 https://issues.dlang.org/show_bug.cgi?id=22838 All hail AddressSanitizer! ;-) https://github.com/dlang/phobos/pull/8401 --
[Issue 7083] variables with static/private storage create global symbols
https://issues.dlang.org/show_bug.cgi?id=7083
kinke changed:
What|Removed |Added
CC||ki...@gmx.net
--- Comment #4 from kinke ---
(In reply to Martin Nowak from comment #2)
> > as the code/data for one module can be distributed among several object
> > files
>
> Do you mean the multilib support?
```
private __gshared int something;
int getSomething(T)() { …; return something; }
```
If the (public) template is instantiated and emitted into another object file /
binary, it still needs to be able to access the private symbol.
--
[Issue 21008] dmd segfaults because of __traits(getMember, ...) and virtual function overriding
https://issues.dlang.org/show_bug.cgi?id=21008 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Dlang Bot --- dlang/dmd pull request #13724 "fix Issue 21008 - dmd segfaults because of __traits(getMember, ...) a…" was merged into master: - 088d11bb2497c7ca4a6d58652f940a643fc95a39 by Walter Bright: fix Issue 21008 - dmd segfaults because of __traits(getMember, ...) and virtual function overriding https://github.com/dlang/dmd/pull/13724 --
[Issue 22522] [dip1000] Creating interior pointers allowed in @safe
https://issues.dlang.org/show_bug.cgi?id=22522 Dennis changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #3 from Dennis --- Re-opening, because: - the error message makes no sense - this is not yet tested for in the test suite - hence, the accidental 'fix' will quietly be reverted when issue 22801 gets fixed --
[Issue 22831] No error for malformed extern(C) main function
https://issues.dlang.org/show_bug.cgi?id=22831
Dlang Bot changed:
What|Removed |Added
Keywords||pull
--- Comment #2 from Dlang Bot ---
@MoonlightSentinel created dlang/dmd pull request #13749 "Fix 22831 - Check
signature of extern(C) main functions" fixing this issue:
- Fix 22831 - Check signature of extern(C) main functions
Enforce that the `main` function uses (most likely) valid arguments /
return types. The spec / C standard denotes the following signatures:
```d
int main() { ... }
int main(int, char**) { ... }
```
The implemented checks are more lenient to accomodate for common
deviations from the standards. See the DDOC comment of `checkMain()`
for a list of accepted extensions.
Exotic platforms that expect a different signature can circumvent the
checks using `pragma(mangle, "main")`.
See e.g.
https://stackoverflow.com/questions/2108192/what-are-the-valid-signatures-for-cs-main-function
https://github.com/dlang/dmd/pull/13749
--
[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order
https://issues.dlang.org/show_bug.cgi?id=22136 --- Comment #5 from Dlang Bot --- dlang/dmd pull request #13745 "Revert "Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of d…"" was merged into stable: - 646fe4e97e1dae3e083ae461931f123f036bd4cf by Nathan Sashihara: Revert "Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of different inheritance order (#13404)" This reverts commit 646ec178ffa13cf596026dae4217fdad27ad777c. https://github.com/dlang/dmd/pull/13745 --
[Issue 22820] Error messages for slice pointers of structs with opIndex can be improved
https://issues.dlang.org/show_bug.cgi?id=22820 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/dmd pull request #13711 "Fix issue 22820: Improve error message for slice pointers" was merged into master: - 26876a29b60bacb889d03c6007a92c4dc35deed2 by Luís Ferreira: Fix issue 22820: Improve error message for slice pointers Signed-off-by: Luís Ferreira https://github.com/dlang/dmd/pull/13711 --
[Issue 22840] New: [dip1000] inout method with inferred @safe escapes local data
https://issues.dlang.org/show_bug.cgi?id=22840
Issue ID: 22840
Summary: [dip1000] inout method with inferred @safe escapes
local data
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
issue 20149 was closed with a partial fix. The fix doesn't work when `@safe` is
inferred, example:
```
struct S
{
int buf;
auto slice() inout
{
return &buf;
}
}
int* fun() @safe
{
S sb;
return sb.slice(); // should error
}
```
Remove `inout` or add explicit `@safe` to `slice` and it correctly raises an
error.
--
[Issue 404] Regression: missing source location in "Error: array initializers as expressions are not allowed"
https://issues.dlang.org/show_bug.cgi?id=404 --- Comment #2 from Dlang Bot --- dlang/dlang.org pull request #3169 "[prman.dd] [intro.dd] [spec.ddoc] Few small fix." was merged into master: - aec69051546e7e4fac11f57f4a9ef7168592dbb3 by devmynote: Translate TITLE Fix 404, sitemap https://github.com/dlang/dlang.org/pull/3169 --
[Issue 22802] [dip1000] First ref parameter seen as `return` destination even with `this`
https://issues.dlang.org/show_bug.cgi?id=22802 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @dkorpel created dlang/dmd pull request #13748 "Fix issue 22802 - First ref parameter seen as `return` destination ev…" fixing this issue: - Fix issue 22802 - First ref parameter seen as `return` destination even with `this` https://github.com/dlang/dmd/pull/13748 --
[Issue 22839] New: Add equivalent of C 'static' for symbols
https://issues.dlang.org/show_bug.cgi?id=22839
Issue ID: 22839
Summary: Add equivalent of C 'static' for symbols
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: dkor...@live.nl
When translating C code to D, I sometimes come across a static function with a
name that could easily clash if it weren't static:
```
static void terminate() {}
```
The closest equivalent D signature would be:
```
extern(C) private void terminate() {}
```
However, even with `private` the compiler intentionally emits a global
`terminate` symbol to the object file (see Issue 7083). I could mark it
extern(D) so it would get a mangled name that wouldn't clash, but that also
changes the ABI. Considering static symbol support was added to dmd for ImportC
(issue 22428), it might be worth exposing this to D code as well using
something like `@Cstatic` or `pragma(noLinkerSymbol)`.
--
[Issue 22793] importC: __import conflicts when importing multiple modules with same package
https://issues.dlang.org/show_bug.cgi?id=22793 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @WalterBright created dlang/dmd pull request #13747 "fix Issue 22793 - importC: __import conflicts when importing multiple…" fixing this issue: - fix Issue 22793 - importC: __import conflicts when importing multiple modules with same package https://github.com/dlang/dmd/pull/13747 --
