[Issue 19950] access violation at compile time, possibly via static foreach and alias interaction
https://issues.dlang.org/show_bug.cgi?id=19950
--- Comment #1 from emmanuelle ---
Actually, it seems you can create an even tinier example:
---
alias Foo = NotHere;
alias Bar = baz!();
void baz()(Foo)
if (true)
{}
---
Which compiles fine (with a normal error) from dmd v2.060 until v2.066, but in
v2.067 and v2.068 it has this cryptic error:
---
onlineapp.d(1): Error: undefined identifier NotHere
dmd: template.c:930: MATCH TemplateDeclaration::matchWithInstance(Scope*,
TemplateInstance*, Objects*, Expressions*, int): Assertion `fd->type->ty ==
Tfunction' failed.
---
And from v2.069 onwards it has a segfault/access violation.
--
[Issue 19950] New: access violation at compile time, possibly via static foreach and alias interaction
https://issues.dlang.org/show_bug.cgi?id=19950
Issue ID: 19950
Summary: access violation at compile time, possibly via static
foreach and alias interaction
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: lakeavenger+dla...@gmail.com
The following snippet causes an access violation at compile time on dmd v2.086,
after a `test.d(2): Error: undefined identifier NotHere` error:
---
struct Bar {
alias Baz = NotHere;
static foreach (name; 0 .. 1) {
alias someAlias = set!();
}
void set()(Baz)
if (true)
{}
}
---
Changing any meaningful structure in the snippet, such as:
- removing the if guard in `set` (changing the condition seems fine)
- changing the arguments in `set`
- removing the static foreach (altering what it iterates over is fine, as long
as it's not empty)
- changing what `someAlias` aliases to
makes compilation act as normal (failing but no access violation), so I assume
this is a weird edge case with static foreach, if guards, and aliases.
Information DMD asked me to send:
---
DMD %.*s
predefs DigitalMars Windows CRuntime_DigitalMars CppRuntime_DigitalMars
LittleEndian D_Version2 all D_InlineAsm D_InlineAsm_X86 X86 Win32 assert
D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat
binaryC:\D\dmd2\windows\bin\dmd.exe
version v2.086.0
configC:\D\dmd2\windows\bin\sc.ini
DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos
-IC:\D\dmd2\windows\bin\..\..\src\druntime\import
---
run.dlang.io says the bug has been present ever since static foreach was
introduced, in dmd v2.076. Before that, the code obviously fails to parse.
--
[Issue 18016] using uninitialized value is considered @safe but has undefined behavior
https://issues.dlang.org/show_bug.cgi?id=18016 --- Comment #15 from Steven Schveighoffer --- (In reply to ag0aep6g from comment #13) > So LLVM would have to give you some value. It wouldn't be allowed to just > omit the whole access and everything that depends on it (as it apparently > does at the moment). How would it omit the return statement? The code above seems to compile with ldc and writeln(f()) seems to print something (0 in fact on my test). Where is the omission? Not saying your assertion is false, I just don't understand how it can omit everything that depends on an access of uninitialized data. --
[Issue 18016] using uninitialized value is considered @safe but has undefined behavior
https://issues.dlang.org/show_bug.cgi?id=18016 --- Comment #14 from Manu --- > As a whole, using an uninitialized variable wouldn't be implementation > defined. > That would be silly. I don't think it's silly at all. It's perfectly fine. Please don't butcher LDC to accommodate DMD's quirks. Reading from uninitialised memory is an invalid operation, and unnecessarily initialising memory has real cost. --
[Issue 18016] using uninitialized value is considered @safe but has undefined behavior
https://issues.dlang.org/show_bug.cgi?id=18016 --- Comment #13 from ag0aep6g --- (In reply to Steven Schveighoffer from comment #12) > I don't understand how the suggestion that the behavior is implementation > defined doesn't jive with LLVM's chosen behavior. As a whole, using an uninitialized variable wouldn't be implementation defined. That would be silly. Walter's PR doesn't do that. It only says that the value you get is up to the implementation. Everything else must work as usual. So LLVM would have to give you some value. It wouldn't be allowed to just omit the whole access and everything that depends on it (as it apparently does at the moment). --
[Issue 18016] using uninitialized value is considered @safe but has undefined behavior
https://issues.dlang.org/show_bug.cgi?id=18016 --- Comment #12 from Steven Schveighoffer --- (In reply to anonymous4 from comment #10) > AFAIK, Walter's suggestion is not supported by LLVM. Currently LLVM removes > code that uses uninitialized value. To work it around LDC will need to > initialize variables initialized with void and provide an different way to > declare uninitialized variables. Likely not a problem, but results in minor > fragmentation of language. I believe LDC way will have a priority, because > DMD is not really about performance anyway, so default initialized variables > for it are good enough. I don't understand how the suggestion that the behavior is implementation defined doesn't jive with LLVM's chosen behavior. --
[Issue 19874] imported CTFE static initializers are run for no reason
https://issues.dlang.org/show_bug.cgi?id=19874 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 19896] [internals] Represent string and arrays as sparse literals
https://issues.dlang.org/show_bug.cgi?id=19896 --- Comment #2 from Iain Buclaw --- (In reply to Nicholas Wilson from comment #1) > I think we should be fast and memory efficient for the common case, and most > string aren't sparse. What use case is that? I'm willing to admit that StringExp may be the wrong target to try to fix. ArrayLiteralExp's however I won't give up on. Casting a StringExp to any array type shouldn't create a new (potentially bigger) StringExp. --
[Issue 19907] passing slice to fixed array not working with variable offset
https://issues.dlang.org/show_bug.cgi?id=19907 anonymous4 changed: What|Removed |Added Severity|normal |minor --
[Issue 8109] typeof(function) within functions
https://issues.dlang.org/show_bug.cgi?id=8109 Basile-z changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #3 from Basile-z --- What's needed is not a special typeof(function), but more a new symbol that represents the function we're in and that would work with typeof(). In addition it would be nice to have a special symbol that would represent the tuple of parameters. using metaprog and __FUNCTION__ is known to work only when the current func has no overload. --
[Issue 12950] Lexer interprets UFCS on hex integer as hex float literal
https://issues.dlang.org/show_bug.cgi?id=12950 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @Basile-z created dlang/dmd pull request #10019 "fix issue 12950 - Lexer interprets UFCS on hex integer as hex float literal" fixing this issue: - fix issue 12950 - Lexer interprets UFCS on hex integer as hex float literal https://github.com/dlang/dmd/pull/10019 --
[Issue 18698] static foreach + __traits(allMembers, moduleName)
https://issues.dlang.org/show_bug.cgi?id=18698 Nicholas Wilson changed: What|Removed |Added Status|NEW |RESOLVED CC||iamthewilsona...@hotmail.co ||m Resolution|--- |WORKSFORME --- Comment #18 from Nicholas Wilson --- This works now, test case added in https://github.com/dlang/dmd/pull/10016 --
[Issue 8109] typeof(function) within functions
https://issues.dlang.org/show_bug.cgi?id=8109 --- Comment #2 from Manu --- I have needed this many times, and I think it's an obvious hole, especially in contrast to the presence of all the others. --
[Issue 8109] typeof(function) within functions
https://issues.dlang.org/show_bug.cgi?id=8109 Nicholas Wilson changed: What|Removed |Added CC||iamthewilsona...@hotmail.co ||m --- Comment #1 from Nicholas Wilson --- So, typeof(this) and typeof(super) are just regular expression typeofs, typeof(return) is special because it needs deferred analysis when the return type is auto. This would effectively be just as special, if not more so. Do you still need this? --
[Issue 18713] ICE in dmd/statementsem.d:1798 with -dip1000
https://issues.dlang.org/show_bug.cgi?id=18713 Basile-z changed: What|Removed |Added Status|NEW |RESOLVED CC||b2.t...@gmx.com Resolution|--- |WORKSFORME --- Comment #1 from Basile-z --- latest release or stable DMD don't crash anymore and instead they issue standard front-end errors --
[Issue 18630] std.math must CTFE
https://issues.dlang.org/show_bug.cgi?id=18630 Nicholas Wilson changed: What|Removed |Added CC||iamthewilsona...@hotmail.co ||m --- Comment #4 from Nicholas Wilson --- asin now works at compile time. The rest still fail for the following reasons. nextPow2 -- reinterpret truncPow2 -- reinterpret atan2 -- reinterpret expi -- asm lround-- no avail source lrint -- ditto rndtol-- ditto uantize -- ditto frexp -- reinterpret ilogb -- y.vu[3] is used before initialised scalbn-- asm --
[Issue 13429] icmp (and friends) should be @nogc
https://issues.dlang.org/show_bug.cgi?id=13429 Nicholas Wilson changed: What|Removed |Added Status|REOPENED|RESOLVED CC||iamthewilsona...@hotmail.co ||m Resolution|--- |FIXED --- Comment #7 from Nicholas Wilson --- This got fixed in https://github.com/dlang/phobos/pull/4933 --
[Issue 13428] Add template to perform appropriate substitution for inout when it appears in a type
https://issues.dlang.org/show_bug.cgi?id=13428 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @thewilsonator created dlang/phobos pull request #7062 "Fix issue 13428: add substituteInout" fixing this issue: - Fix issue 13428: add substituteInout https://github.com/dlang/phobos/pull/7062 --
