[Issue 11169] __traits(isAbstractClass) prematurely sets a class to be abstract
https://issues.dlang.org/show_bug.cgi?id=11169 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/6fd1005dff51380e7bcb11dbc71e2c8bbb46cfb6 fix Issue 11169 - __traits(isAbstractClass) prematurely sets a class to be abstract __traits(isAbstractClass) should resolve forward references of all class member functions, in order to return stable result. https://github.com/dlang/dmd/commit/1bc9bad46c0539b243cca683d38cb1961870 Merge pull request #5695 from 9rnsr/fix11169 Issue 11169 - __traits(isAbstractClass) prematurely sets a class to be abstract --
[Issue 11169] __traits(isAbstractClass) prematurely sets a class to be abstract
https://issues.dlang.org/show_bug.cgi?id=11169 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 8008] Syntax for fixed size array literals like [1,2,3]s
https://issues.dlang.org/show_bug.cgi?id=8008 Nick Treleaven changed: What|Removed |Added URL||https://github.com/dlang/ph ||obos/pull/4090 --- Comment #15 from Nick Treleaven --- Added link to Phobos pull, but that has just been closed because there's no solution to Issue 12625 yet. --
[Issue 3849] Compiler should catch incomplete initialisation of an array
https://issues.dlang.org/show_bug.cgi?id=3849 Nick Treleaven changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=5290 --
[Issue 5290] Static array literals with too few elements
https://issues.dlang.org/show_bug.cgi?id=5290 Nick Treleaven changed: What|Removed |Added CC||ntrel-...@mybtinternet.com See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=3849 --
[Issue 15960] SetUnion should filter duplicates
https://issues.dlang.org/show_bug.cgi?id=15960 Nick Treleaven changed: What|Removed |Added URL||https://github.com/dlang/ph ||obos/pull/4249 CC||ntrel-...@mybtinternet.com --
[Issue 15961] New: [REG-master] ICE with instance field introduced by anonymous struct
https://issues.dlang.org/show_bug.cgi?id=15961
Issue ID: 15961
Summary: [REG-master] ICE with instance field introduced by
anonymous struct
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice, wrong-code
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Test case:
struct SliceOverIndexed(T)
{
enum assignableIndex = T.init;
}
struct Grapheme
{
SliceOverIndexed!Grapheme opSlice()
{
assert(0);
}
struct
{
ubyte* ptr_;
}
}
Command line and stack trace of debug build git-master dmd:
$ dmd -o- test
DMD v2.072.0 DEBUG
core.exception.AssertError@aggregate.d(593): Assertion failure
0x005ABC47 in _d_assert
0x004038E0 in AggregateDeclaration at
c:\d2home\dmd2\src\dmd\src\aggregate.d(594)
0x00403919 in AggregateDeclaration at
c:\d2home\dmd2\src\dmd\src\aggregate.d(617)
0x00407D40 in AnonDeclaration at c:\d2home\dmd2\src\dmd\src\attrib.d(744)
0x0044DD0C in StructDeclaration at c:\d2home\dmd2\src\dmd\src\dstruct.d(566)
0x0040320A in AggregateDeclaration at
c:\d2home\dmd2\src\dmd\src\aggregate.d(322)
0x0040328C in AggregateDeclaration at
c:\d2home\dmd2\src\dmd\src\aggregate.d(343)
0x004BFC1E in TypeStruct at c:\d2home\dmd2\src\dmd\src\mtype.d(8051)
0x004B5229 in Type at c:\d2home\dmd2\src\dmd\src\mtype.d(2421)
0x004B5659 in Type at c:\d2home\dmd2\src\dmd\src\mtype.d(2532)
0x004B598D in Type at c:\d2home\dmd2\src\dmd\src\mtype.d(2628)
0x004BF321 in TypeStruct at c:\d2home\dmd2\src\dmd\src\mtype.d(7875)
0x00475110 in DotIdExp at c:\d2home\dmd2\src\dmd\src\expression.d(8825)
0x00473F90 in DotIdExp at c:\d2home\dmd2\src\dmd\src\expression.d(8445)
0x0049FD50 in ExpInitializer at c:\d2home\dmd2\src\dmd\src\init.d(775)
0x0042A8C0 in VarDeclaration at c:\d2home\dmd2\src\dmd\src\declaration.d(1091)
0x0044D6AD in StructDeclaration at c:\d2home\dmd2\src\dmd\src\dstruct.d(374)
0x0045FF05 in TemplateInstance at c:\d2home\dmd2\src\dmd\src\dtemplate.d(8205)
0x0045FF5C in TemplateInstance at c:\d2home\dmd2\src\dmd\src\dtemplate.d(8223)
0x0045C774 in TemplateInstance at c:\d2home\dmd2\src\dmd\src\dtemplate.d(6309)
0x0045CD9F in TemplateInstance at c:\d2home\dmd2\src\dmd\src\dtemplate.d(6539)
0x004BE5A9 in TypeInstance at c:\d2home\dmd2\src\dmd\src\mtype.d(7406)
0x004BE656 in TypeInstance at c:\d2home\dmd2\src\dmd\src\mtype.d(7428)
0x004BB41C in TypeFunction at c:\d2home\dmd2\src\dmd\src\mtype.d(5876)
0x004873BA in FuncDeclaration at c:\d2home\dmd2\src\dmd\src\func.d(725)
0x0044D6AD in StructDeclaration at c:\d2home\dmd2\src\dmd\src\dstruct.d(374)
0x00445A5B in Module at c:\d2home\dmd2\src\dmd\src\dmodule.d(994)
0x004B07C3 in int ddmd.mars.tryMain(uint, const(char)**) at
c:\d2home\dmd2\src\dmd\src\mars.d(1431)
0x004B11D3 in _Dmain at c:\d2home\dmd2\src\dmd\src\mars.d(1655)
0x005AD9A2 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv
0x005AD977 in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x005AD88B in _d_run_main
0x004B170C in main
0x005C1F4D in mainCRTStartup
0x7605338A in BaseThreadInitThunk
0x77AC9A02 in RtlInitializeExceptionChain
0x77AC99D5 in RtlInitializeExceptionChain
This is a regression from 2.066. Since 2.066 to 2.068, the code had displayed
an assertion failure:
Assertion failure: 'alignment > 0 && !(alignment & (alignment - 1))' on line
455 in file 'struct.c'
abnormal program termination
But from 2.069, dmd codebase was switched to D, then the assertion failure no
longer happen with released dmd, and I guess it would have been wrong code bug
because of incorrect alignment.
--
[Issue 15961] [REG2.066] ICE with instance field introduced by anonymous struct
https://issues.dlang.org/show_bug.cgi?id=15961 Kenji Hara changed: What|Removed |Added Summary|[REG-master] ICE with |[REG2.066] ICE with |instance field introduced |instance field introduced |by anonymous struct |by anonymous struct --
[Issue 15961] [REG2.066] ICE with instance field introduced by anonymous struct
https://issues.dlang.org/show_bug.cgi?id=15961 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara --- https://github.com/dlang/dmd/pull/5715 --
[Issue 15962] New: [REG2.069] Don't strip off asserts to check internal compiler errors
https://issues.dlang.org/show_bug.cgi?id=15962 Issue ID: 15962 Summary: [REG2.069] Don't strip off asserts to check internal compiler errors Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: ice Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: k.hara...@gmail.com >From 2.069, dmd code base is switched to D. But today, a released dmd is compiled with -release switch. It means, the built dmd binary no longer contain any asserts. By that, all internal errors in front end no longer reported. Actually it would hide some serious regressions. See issue 15961 as a real example. --
[Issue 15962] [REG2.069] Don't strip off asserts to check internal compiler errors
https://issues.dlang.org/show_bug.cgi?id=15962 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara --- https://github.com/dlang/dmd/pull/5716 --
[Issue 11229] std.string.toLower is slow
https://issues.dlang.org/show_bug.cgi?id=11229 --- Comment #6 from Jack Stouffer --- This, (cast(string)"pg1342.txt".read).map!toLower.array is almost three times faster than (cast(string)"pg1342.txt".read).toLower because of the ASCII optimizations in dchar toLower(dchar c) --
[Issue 6343] std.math.ceilPow2
https://issues.dlang.org/show_bug.cgi?id=6343 Jack Stouffer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Jack Stouffer --- No need for a separate function now, you can just do nextPow2(w == 0 ? w : w - 1) for your desired effect. If you still want the name, then you can do alias ceilPow2 = (w) => nextPow2(w == 0 ? w : w - 1); in your code. I am going to mark this as won't fix because adding this function would only take one line and therefore is of questionable value to add to Phobos. --
[Issue 15961] [REG2.066] ICE with instance field introduced by anonymous struct
https://issues.dlang.org/show_bug.cgi?id=15961 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15961] [REG2.066] ICE with instance field introduced by anonymous struct
https://issues.dlang.org/show_bug.cgi?id=15961 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/4b667bb7603fe1a7b5bb153accf91ebc835c1ce1 fix Issue 15961 - ICE with instance field introduced by anonymous struct `AnonDeclaration.setFieldOffset` may be called before the `semantic` to determine aggregate instance size in early steps. https://github.com/dlang/dmd/commit/0d1d6ffae8be9fdaf63cc02147c91e8ba4e1ad56 Merge pull request #5715 from 9rnsr/fix15961 [REG2.066] Issue 15961 - ICE with instance field introduced by anonymous struct --
[Issue 15957] Disabled postblit + template mixin break opAssign with confusing error message
https://issues.dlang.org/show_bug.cgi?id=15957 --- Comment #4 from Dicebot --- Interesting. Why does it need to create opAssign when post-blit is disabled? Is it documented anywhere? It sounds very confusing that disabling any symbol result in hidden injection of another one in main scope. --
[Issue 14208] Use a single signal number for GC thread suspend and resume
https://issues.dlang.org/show_bug.cgi?id=14208 safety0ff.bugz changed: What|Removed |Added CC||safety0ff.b...@gmail.com Assignee|nob...@puremagic.com|safety0ff.b...@gmail.com --- Comment #1 from safety0ff.bugz --- I'm currently working on this. --
[Issue 15963] New: Hidden unresolved forward reference issue in std.uni
https://issues.dlang.org/show_bug.cgi?id=15963
Issue ID: 15963
Summary: Hidden unresolved forward reference issue in std.uni
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: k.hara...@gmail.com
Minimized test case from std.uni module code:
void main()//unittest
{
Grapheme()[];
}
struct SliceOverIndexed(T)
{
enum assignableSlice = is(typeof({ T.init[0..0] = Item.init; }));
alias Item = typeof(T.init[0]);
size_t from, to;
T* arr;
}
SliceOverIndexed!T sliceOverIndexed(T)(size_t a, size_t b, T* x)
{
return SliceOverIndexed!T(a, b, x);
}
struct Grapheme
{
dchar opIndex(size_t index) const pure nothrow @nogc
{
return 'a';
}
@system auto opSlice(size_t a, size_t b) pure nothrow @nogc
{
return sliceOverIndexed(a, b, &this);
}
@system auto opSlice() pure nothrow @nogc
{
return sliceOverIndexed(0, 0, &this);
}
}
Two opSlice auto functions in Grapheme depends on a return type of template
function sliceOverIndexed. But the instantiated type SliceOverIndexed!Grapheme
depends on is(typeof({ Grapheme.opSlice(0, 0) = dchar.init; })). In short,
there's an unresolved forward reference issue.
The hiding error is a bug of current dmd, but the Phobos code needs to be fixed
first.
--
[Issue 15939] GC.collect causes deadlock in multi-threaded environment
https://issues.dlang.org/show_bug.cgi?id=15939 safety0ff.bugz changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #9 from safety0ff.bugz --- Could you run strace to get a log of the signal usage? For example: strace -f -e signal -o signals.log command_to_run_program Then add the output signals.log to the bug report? I don't know if it'll be useful but it will be something more to look for hints. I'm wondering if there are any other signal handler invocations in the "...application stack" part of your stack traces. I've seem a deadlock caused by an assert firing within the thread_suspendHandler, which deadlocks on the GC lock. (In reply to Aleksei Preobrazhenskii from comment #6) > Like, if thread_suspendAll happens while some threads are still in the > thread_suspendHandler (already handled resume signal, but still didn't leave > the suspend handler). What should happen in this case is since the signal is masked upon signal handler invocation, the new suspend signal is marked as "pending" and run once thread_suspendHandler returns and the signal is unblocked. The suspended thread cannot receive another resume or suspend signal until after the sem_post in thread_suspendHandler. I've mocked up the suspend / resume code and it does not deadlock from the situation you've described. > Real-time POSIX signals (SIGRTMIN .. SIGRTMAX) have stronger delivery > guarantees Their queuing and ordering guarantees should be irrelevant due to synchronization and signal masks. I don't see any other benefits of RT signals. (In reply to Walter Bright from comment #8) > > Since you've written the code to fix it, please write a Pull Request for it. > That way you get the credit! He modified his code to use the thread_setGCSignals function: https://dlang.org/phobos/core_thread.html#.thread_setGCSignals P.S.: I don't mean to sound doubtful, I just want a sound explanation of the deadlock so it can be properly address at the cause. --
[Issue 15963] Hidden unresolved forward reference issue in std.uni
https://issues.dlang.org/show_bug.cgi?id=15963 Kenji Hara changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara --- https://github.com/dlang/phobos/pull/4253 --
[Issue 15961] [REG2.066] ICE with instance field introduced by anonymous struct
https://issues.dlang.org/show_bug.cgi?id=15961 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/4b667bb7603fe1a7b5bb153accf91ebc835c1ce1 fix Issue 15961 - ICE with instance field introduced by anonymous struct https://github.com/dlang/dmd/commit/0d1d6ffae8be9fdaf63cc02147c91e8ba4e1ad56 Merge pull request #5715 from 9rnsr/fix15961 --
[Issue 15857] incorrect checkimports mismatch for overload sets
https://issues.dlang.org/show_bug.cgi?id=15857 --- Comment #7 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/082e1199c258e99f7867ca33509db9ae9a31f3ae Issue 15857 - incorrect checkimports mismatch for overload sets https://github.com/dlang/dmd/commit/82c5682edbd876767d3853bd6fdd2cc70ebfa73b Merge pull request #5681 from 9rnsr/fix15857 --
[Issue 15939] GC.collect causes deadlock in multi-threaded environment
https://issues.dlang.org/show_bug.cgi?id=15939 --- Comment #10 from Aleksei Preobrazhenskii --- (In reply to safety0ff.bugz from comment #9) > Could you run strace to get a log of the signal usage? I did it before to catch the deadlock, but I wasn't able to do that while strace was running. And, unfortunately, I don't have original code running in production anymore. > I'm wondering if there are any other signal handler invocations in the > "...application stack" part of your stack traces. No, there was no signal related code in hidden parts of stack trace. > I've seem a deadlock caused by an assert firing within the > thread_suspendHandler, which deadlocks on the GC lock. In my case that was a release build, so I assume no asserts. > What should happen in this case is since the signal is masked upon signal > handler invocation, the new suspend signal is marked as "pending" and run > once thread_suspendHandler returns and the signal is unblocked. Yeah, my reasoning was wrong. I did a quick test and saw that signals weren't delivered, apparently, I forgot that pthread_kill is asynchronous, so signals should've coalesced in my test. > Their queuing and ordering guarantees should be irrelevant due to > synchronization and signal masks. Ideally, yeah, but as I said, I just changed SIGUSR1/SIGUSR2 to SIGRTMIN/SIGRTMIN+1 and didn't see any deadlocks for a long time, and I saw them pretty consistently before. So, either "irrelevant" part is wrong, or there is something else which is different and relevant (and probably not documented) for real-time signals. The other explanation is that bug is still there and real-time signals just somehow reduced probability of it happening. Also, I have no other explanation why stack traces look like that, the simplest one is that signal wasn't delivered. --
