[Issue 22614] Wrong copy constructor is called depending on context
https://issues.dlang.org/show_bug.cgi?id=22614 Stanislav Blinov changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16500 --
[Issue 16500] inferred != annotated pure
https://issues.dlang.org/show_bug.cgi?id=16500 Stanislav Blinov changed: What|Removed |Added CC||stanislav.bli...@gmail.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=22614 --- Comment #1 from Stanislav Blinov --- I would strongly suggest constructors which are inferred pure, as opposed to explicitly annotated, MUST NOT be considered for uniqueness. Doing otherwise can lead to unexpected changes in program behavior, silent bugs. See the related issue for rationale. --
[Issue 22615] Wrong OS version and struct kevent_t in FreeBSD 13
https://issues.dlang.org/show_bug.cgi?id=22615 --- Comment #2 from Eugene --- LDC2 stdlib module (/usr/local/include/d/core/sys/freebsd/sys/event.d) does not contain struct kevent_t for versions 12+ at all, so, "no problem" :) --
[Issue 22615] Wrong OS version and struct kevent_t in FreeBSD 13
https://issues.dlang.org/show_bug.cgi?id=22615
--- Comment #1 from Eugene ---
@bsd:~/d> dmd --version
DMD64 D Compiler v2.098.0
LDC2 standart library does not have core.sys.freebsd.config module,
but kevent_t.sizeof is also wrong:
bsd:~/d> ldc2 -v
binary/usr/local/bin/ldc2
version 1.23.0 (DMD v2.093.1, LLVM 10.0.1)
@bsd:~/d> ldc2 freebsdver.d
@bsd:~/d> ./freebsdver
sizeof(kevent_t) = 32
Must be 64, see exerpt from /usr/include/sys/event.h:
new, 12+:
struct kevent {
__uintptr_t ident; // identifier for this event
short filter; // filter for event
unsigned short flags; // action flags for kqueue
unsigned intfflags; // filter flag value
__int64_t data; // filter data value
void*udata; // opaque user data identifier
__uint64_t ext[4]; // extensions
};
old, 11-:
#if defined(_WANT_FREEBSD11_KEVENT)
// Older structure used in FreeBSD 11.x and older.
struct kevent_freebsd11 {
__uintptr_t ident; // identifier for this event
short filter; // filter for event
unsigned short flags;
unsigned intfflags;
__intptr_t data;
void*udata; // opaque user data identifier
};
#endif
--
[Issue 22619] New: [REG2.098.1] Nullable regression introduced by new copy ctor
https://issues.dlang.org/show_bug.cgi?id=22619
Issue ID: 22619
Summary: [REG2.098.1] Nullable regression introduced by new
copy ctor
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: ki...@gmx.net
This newly fails to compile with DMD v2.098.1, but works with 2.098.0:
```
import std.typecons : Nullable, nullable;
struct Module {
Nullable!string name;
}
Nullable!(const(Module)) findModule(const ref Module mod) {
return nullable(mod);
}
```
Error:
```
std/typecons.d(3100): Error: variable
`std.typecons.nullable!(const(Module)).nullable.__copytmp15` `inout` variables
can only be declared inside `inout` functions
bug.d(8): Error: template instance `std.typecons.nullable!(const(Module))`
error instantiating
```
The copy ctor was added in https://github.com/dlang/phobos/pull/8318.
--
[Issue 22616] Infinity loop instead of InvalidMemoryOperationError during GC routine
https://issues.dlang.org/show_bug.cgi?id=22616 --- Comment #4 from moonlightsenti...@disroot.org --- The problem here is that this line [1] is executed before the exception is rethrown - which calls `_d_throwdwarf` and ends up trying to allocate the DefaultTraceHandler. [1] https://github.com/dlang/druntime/blob/fd9a45448244fb9dd4326520ad8526c540895eb0/src/core/internal/gc/impl/conservative/gc.d#L3141 --
[Issue 22616] Infinity loop instead of InvalidMemoryOperationError during GC routine
https://issues.dlang.org/show_bug.cgi?id=22616 Mathias LANG changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #3 from Mathias LANG --- The key is: ``` #7 0x5559d3db in gc_malloc () #8 0x55599875 in _d_newclass () #9 0x555a3029 in core.runtime.defaultTraceHandler(void*) () #10 0x5559db52 in _d_traceContext () #11 0x5559d942 in _d_createTrace () #12 0x55598cbe in _d_throwdwarf () ``` So it means we hit https://github.com/dlang/druntime/blob/fd9a45448244fb9dd4326520ad8526c540895eb0/src/core/runtime.d#L695 But that shouldn't be possible, since this function is guarded by a `GC.inFinalizer` check that would lead to it returning... --
[Issue 22483] DMD generates invalid string sections that work by coincidence
https://issues.dlang.org/show_bug.cgi?id=22483 ZombineDev changed: What|Removed |Added Keywords||backend, wrong-code CC||petar.p.ki...@gmail.com Severity|enhancement |minor --
[Issue 22616] Infinity loop instead of InvalidMemoryOperationError during GC routine
https://issues.dlang.org/show_bug.cgi?id=22616 moonlightsenti...@disroot.org changed: What|Removed |Added CC||moonlightsentinel@disroot.o ||rg --- Comment #2 from moonlightsenti...@disroot.org --- Bisection points to this PR: https://github.com/dlang/druntime/pull/3476 --
[Issue 22618] [REG2.078] Rejects valid depending on ordering of alias this and other alias
https://issues.dlang.org/show_bug.cgi?id=22618 johanenge...@weka.io changed: What|Removed |Added Keywords||industry, rejects-valid --
[Issue 22618] New: [REG2.078] Rejects valid depending on ordering of alias this and other alias
https://issues.dlang.org/show_bug.cgi?id=22618
Issue ID: 22618
Summary: [REG2.078] Rejects valid depending on ordering of
alias this and other alias
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: johanenge...@weka.io
Testcase:
```
struct BaseBlock
{
void baseFoo()
{
}
}
template someMixin(alias Func)
{
}
struct BlockHandle(T)
{
T* block;
void foo()
{
block.baseFoo;
}
mixin someMixin!((BlockHandle!T self) {
self.foo;
});
}
struct ChildBlock
{
version (BUG)
{
alias Handle = BlockHandle!(typeof(this));
BaseBlock base;
alias base this;
}
else
{
BaseBlock base;
alias base this;
alias Handle = BlockHandle!(typeof(this));
}
}
```
Compilation without any flags succeeds.
But compilation with -version=BUG resuls in the error:
aliasbug.d(18): Error: no property `baseFoo` for type `aliasbug.ChildBlock*
Apparently the `alias this` is ignored during the evaluation of `alias Handle =
BlockHandle!(typeof(this));`, if the `alias this` is defined after the `alias
Handle = ...`.
The testcase succeeds with/without -version=BUG for dlang 2.077. (The bug was
detected as a regression between 2.093 and 2.097, but after dustmiting to the
testcase above it fails also with 2.093.)
--
[Issue 22617] New: CTFE rejects modification of copied static array
https://issues.dlang.org/show_bug.cgi?id=22617
Issue ID: 22617
Summary: CTFE rejects modification of copied static array
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: moonlightsenti...@disroot.org
CTFE rejects the assignment to `copy[0]` if `arr` is const/immutable even
though the static array was copied!
int countWins(const uint[2] arr)
{
uint[2] copy = arr;
copy[0] = 0;
return 0;
}
enum force = countWins([4, 8]);
ctfe_copy.d(4): Error: cannot modify read-only constant `[4u, 8u]`
ctfe_copy.d(8):called from here: `countWins([4u, 8u])`
===
Introduced by https://github.com/dlang/dmd/pull/4503.
--
[Issue 22616] Infinity loop instead of InvalidMemoryOperationError during GC routine
https://issues.dlang.org/show_bug.cgi?id=22616 --- Comment #1 from feklushkin.de...@gmail.com --- Wrong stack trace attached, correct is: #0 __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fffdad0, rem=0x7fffdae0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:67 #1 0x77d053f3 in __GI___nanosleep (req=, rem=) at ../sysdeps/unix/sysv/linux/nanosleep.c:25 #2 0x555ba090 in core.thread.osthread.Thread.sleep(core.time.Duration) () #3 0x555bd6c9 in core.internal.spinlock.SpinLock.yield(ulong) shared () #4 0x555bd67a in core.internal.spinlock.SpinLock.lock() shared () #5 0x555c6dcb in 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)) () #6 0x555be702 in core.internal.gc.impl.conservative.gc.ConservativeGC.malloc(ulong, uint, const(TypeInfo)) () #7 0x5559d3db in gc_malloc () #8 0x55599875 in _d_newclass () #9 0x555a3029 in core.runtime.defaultTraceHandler(void*) () #10 0x5559db52 in _d_traceContext () #11 0x5559d942 in _d_createTrace () #12 0x55598cbe in _d_throwdwarf () #13 0x555c327c in core.internal.gc.impl.conservative.gc.Gcx.fullcollect(bool) () #14 0x555c78d4 in core.internal.gc.impl.conservative.gc.ConservativeGC.runLocked!(core.internal.gc.impl.conservative.gc.ConservativeGC.fullCollectNoStack().go(core.internal.gc.impl.conservative.gc.Gcx*), core.internal.gc.impl.conservative.gc.Gcx*).runLocked(ref core.internal.gc.impl.conservative.gc.Gcx*) () #15 0x555bfc54 in core.internal.gc.impl.conservative.gc.ConservativeGC.fullCollectNoStack() () #16 0x555bfbea in core.internal.gc.impl.conservative.gc.ConservativeGC.collectNoStack() () #17 0x555aac3f in gc_term () #18 0x5559da7b in rt_term () #19 0x55598acb in rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).runAll() () #20 0x555989ad in rt.dmain2._d_run_main2(char[][], ulong, extern(C) int(char[][]) function).tryExec(scope void() delegate) () #21 0x5559890e in _d_run_main2 () #22 0x5559866a in _d_run_main () #23 0x55597712 in main (argc=1, argv=0x7fffe228) at /usr/include/dmd/druntime/import/core/internal/entrypoint.d:29 #24 0x77c627ed in __libc_start_main (main=0x555976f0 , argc=1, argv=0x7fffe228, init=, fini=, rtld_fini=, stack_end=0x7fffe218) at ../csu/libc-start.c:332 #25 0x555975ea in _start () --
[Issue 22616] New: Infinity loop instead of InvalidMemoryOperationError during GC routine
https://issues.dlang.org/show_bug.cgi?id=22616
Issue ID: 22616
Summary: Infinity loop instead of InvalidMemoryOperationError
during GC routine
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: feklushkin.de...@gmail.com
Issue was introduced in v2.097.0
/+ dub.json:
{
"name": "test"
}
+/
class C
{
int i;
~this ()
{
// It is wrong to allocate during GC collection,
// but this failed assert allocates and must throw
// InvalidMemoryOperationError.
assert(i == 123);
}
}
void main()
{
auto c = new C;
}
```
DMD64 D Compiler v2.096.1 - OK
$ dub -f --compiler=dmd --single test.d
Performing "debug" build using dmd for x86_64.
test ~master: building configuration "application"...
Linking...
Running test
core.exception.InvalidMemoryOperationError@src/core/exception.d(647): Invalid
memory operation
Program exited with code 1
(as expected)
DMD64 D Compiler v2.097.0 - Infinity wait
$ dub -f --compiler=dmd --single test.d
Performing "debug" build using dmd for x86_64.
test ~master: building configuration "application"...
Linking...
Running test
(stalled)
Stack after ctrl+c:
#0 0x77d05176 in __GI___wait4 (pid=289204, stat_loc=0x7fffc68c,
options=0, usage=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1 0x557babb3 in std.process.Pid.performWait(bool) ()
#2 0x55700686 in
dub.generators.build.BuildGenerator.runTarget(dub.internal.vibecompat.inet.path.NativePath,
in dub.compilers.buildsettings.BuildSettings, immutable(char)[][],
dub.generators.generator.GeneratorSettings) ()
#3 0x5570031b in
dub.generators.build.BuildGenerator.performPostGenerateActions(dub.generators.generator.GeneratorSettings,
in dub.generators.generator.ProjectGenerator.TargetInfo[immutable(char)[]]) ()
#4 0x556e8806 in
dub.generators.generator.ProjectGenerator.generate(dub.generators.generator.GeneratorSettings)
()
#5 0x5577e429 in dub.commandline.GenerateCommand.execute(dub.dub.Dub,
immutable(char)[][], immutable(char)[][]) ()
#6 0x5577f4ee in dub.commandline.RunCommand.execute(dub.dub.Dub,
immutable(char)[][], immutable(char)[][]) ()
#7 0x5571964f in
dub.commandline.runDubCommandLine(immutable(char)[][]) ()
#8 0x557e7258 in rt.dmain2._d_run_main2(char[][], ulong, extern(C)
int(char[][]) function).runAll() ()
#9 0x557e7155 in _d_run_main2 ()
#10 0x557e6fae in _d_run_main ()
#11 0x77c627ed in __libc_start_main (main=0x55788050 ,
argc=5, argv=0x7fffe7d8, init=, fini=,
rtld_fini=, stack_end=0x7fffe7c8) at ../csu/libc-start.c:332
#12 0x5559b2da in _start ()
--
[Issue 22614] Wrong copy constructor is called depending on context
https://issues.dlang.org/show_bug.cgi?id=22614 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- It seems that for some reason annotating with @safe the unittest enables the compiler to infer attributes for the nested struct members. This has the result of inferring pure for the copy constructors and therefore the immutable constructor becomes a unique constructor (which means it can be implicitly convertible to mutable). Next, the compiler thinks that the unique copy constructor is better than const copy constructor. I think that the fundamental problem here is that @safe enables attribute inference. I haven't seen this anywhere explicitly stated in the spec. The unique conversion rules are another black box for me. --
[Issue 22615] Wrong OS version and struct kevent_t in FreeBSD 13
https://issues.dlang.org/show_bug.cgi?id=22615 Eugene changed: What|Removed |Added CC||dee0x...@gmail.com --
[Issue 22531] importC: D name mangling applied to forward declaration of function inside function
https://issues.dlang.org/show_bug.cgi?id=22531 --- Comment #3 from Dlang Bot --- dlang/dmd pull request #13446 "Move fix for issue 22531 from glue layer to frontend" was merged into stable: - f4ca2f2a26fb81ddbaf8e5626228eb74b54cf5c8 by Martin Kinkelin: Move fix for issue 22531 from glue layer to frontend https://github.com/dlang/dmd/pull/13446 --
[Issue 22136] [REG 2.097.1] hashOf failed to compile because of different inheritance order
https://issues.dlang.org/show_bug.cgi?id=22136 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #13404 "Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of d…" was merged into stable: - 289394fab4695d3f601767ea004f9c1737880395 by Eduard Staniloiu: Fix Issue 22136 - [REG 2.097.1] hashOf failed to compile because of different inheritance order https://github.com/dlang/dmd/pull/13404 --
[Issue 22615] New: Wrong OS version and struct kevent_t in FreeBSD 13
https://issues.dlang.org/show_bug.cgi?id=22615
Issue ID: 22615
Summary: Wrong OS version and struct kevent_t in FreeBSD 13
Product: D
Version: D2
Hardware: x86_64
OS: FreeBSD
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: dee0x...@gmail.com
test program:
import std.stdio;
import core.sys.freebsd.config;
import core.sys.freebsd.sys.event;
void main(string[] args) {
writefln("FreeBSD_version = %s", __FreeBSD_version);
writefln("sizeof(kevent_t) = %s", kevent_t.sizeof);
}
output:
@bsd:~/d> ./freebsdver
FreeBSD_version = 1104000
sizeof(kevent_t) = 32
actual version
@bsd:~/d> uname -K
1300139
NOTE:
/usr/include/d/dmd/core/sys/freebsd/sys/event.h do contain correct definition
of kevent_t for versions 12+ (with ulong[4] ext field), but because of wrong
kernel version size of kevent_t is also incorrect.
--
