[Issue 17713] Template 'this' parameters for static methods
https://issues.dlang.org/show_bug.cgi?id=17713 Timoses changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14191 --
[Issue 14191] Failure to locate overload with template this parameter
https://issues.dlang.org/show_bug.cgi?id=14191 Timoses changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=17713 --
[Issue 17714] Function template - this T for static methods
https://issues.dlang.org/show_bug.cgi?id=17714 --- Comment #2 from Timoses --- (In reply to Steven Schveighoffer from comment #1) > Huh, I think separately Timon Gehr added an almost identical issue right > before you :) > > *** This issue has been marked as a duplicate of issue 17713 *** That's quite a coincidence : D. Forum post discussion: https://forum.dlang.org/post/tkrtxyvjknolkynzd...@forum.dlang.org --
[Issue 17719] New: compiler generates code for CTFE-only templates
https://issues.dlang.org/show_bug.cgi?id=17719 Issue ID: 17719 Summary: compiler generates code for CTFE-only templates Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: c...@dawg.eu Quite a few template functions that are only used as CTFE helpers end up in final binaries, unnecessarily slowing down compilation and blowing up object sizes. Would be great if we could dismiss any instantions that are not used during runtime. --
[Issue 14793] net.curl.download https broken - windows
https://issues.dlang.org/show_bug.cgi?id=14793 --- Comment #7 from Vladimir Panteleev --- If there is a reproducible problem with the installer not installing libcurl properly, please file that separately. --
[Issue 14793] net.curl.download https broken - windows
https://issues.dlang.org/show_bug.cgi?id=14793 Vladimir Panteleev changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|FIXED |INVALID --
[Issue 17703] __traits(compiles, AssignmentExpression) no longer compiles without surrounding parens
https://issues.dlang.org/show_bug.cgi?id=17703
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
Severity|regression |normal
--- Comment #1 from Martin Nowak ---
Looks like the assignment expression parsing isn't fully working, below example
works.
void works(int a, int b)
{
static assert(__traits(compiles, a = b));
}
Also the specs support the case
http://dlang.org/spec/grammar.html#TraitsArgument
I went back until 2.050 and it still wouldn't accept the code, downgrading to a
normal bug.
Simple workaround:
__traits(compiles, { exp; })
--
[Issue 17661] New isInputRange rejects valid input range
https://issues.dlang.org/show_bug.cgi?id=17661
Martin Nowak changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #5 from Martin Nowak ---
Well in, (R r) return => r.front, the return applies to the delegate context,
but you're escaping a reference to the argument.
What you want to check is `(return ref R r) => r.front`.
Also rewriting your front methods to a free functions helps understanding.
C front(return ref S _this) { return C(&_this); }
Obviously allowing
(R r) => front(r)
would return a dangling reference to the value parameter.
NB, if your front methods leaked a field of the range (e.g. a pointer), you'd
need a `return scope` front methods, but the `(R r) => r.front` check is fine,
since the parameter `r` isn't scoped, i.e. it might leak any pointer fields.
--
[Issue 17718] New: [scope] function literal arguments can be escaped
https://issues.dlang.org/show_bug.cgi?id=17718
Issue ID: 17718
Summary: [scope] function literal arguments can be escaped
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: safe
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
@safe:
struct S
{
int* p;
int* leak() return scope { return p; }
}
alias f = function int*(scope S s) { return s.leak; }; // broken
int* f(scope S s) { return s.leak; } // works
CODE
dmd -c -dip1000 bug
--
[Issue 14793] net.curl.download https broken - windows
https://issues.dlang.org/show_bug.cgi?id=14793 Yury Korchemkin changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Yury Korchemkin --- Figured that out — the problem was with libcurl.dll being not installed on the machine and not copied into the folder with executable. Copying the DLL solved the problem. Resolving the bug. --
[Issue 17601] [REG2.075.0-b1] segmentation fault for dmd -deps
https://issues.dlang.org/show_bug.cgi?id=17601 Martin Nowak changed: What|Removed |Added Priority|P3 |P1 --
[Issue 17717] New: C++ files not always recompiled when changed
https://issues.dlang.org/show_bug.cgi?id=17717 Issue ID: 17717 Summary: C++ files not always recompiled when changed Product: D Version: D2 Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: nicolas.jincher...@gmail.com C++ files included in my Visual D project don't always get recompiled after they've been changed. I have to clean the solution to get them to recompile. --
[Issue 17601] [REG2.075.0-b1] segmentation fault for dmd -deps
https://issues.dlang.org/show_bug.cgi?id=17601 --- Comment #7 from Martin Nowak --- I'd say that the change in https://github.com/dlang/dmd/pull/6748 and using -deps without -o- are suboptimal, as you'd end up with all the codegen from the semantic3 in imported methods in your object files, not particularly nice. This is unfortunately similar to how inlining is implemented in dmd :/. --
[Issue 17716] wrong result of IsExpression when not in static assert
https://issues.dlang.org/show_bug.cgi?id=17716
--- Comment #1 from ag0ae...@gmail.com ---
Inside functions everything works as expected:
struct S { shared int* foo; int* bar; }
pragma(msg, is(shared S : S)); /* "true" - wrong */
void f()
{
pragma(msg, is(shared S : S)); /* "false" - correct */
}
--
[Issue 17601] [REG2.075.0-b1] segmentation fault for dmd -deps
https://issues.dlang.org/show_bug.cgi?id=17601 --- Comment #6 from Martin Nowak --- Happens because a function ends up in the glue layer in PASSsemantic2 state (std.range.SortedRange!(string[], "a < b").SortedRange.__xopEquals). It's a side-effect of bluntly trying to run semantic3 on all imported modules (https://github.com/dlang/dmd/pull/6748). Seems like the deferred STCinference mechanism added in https://github.com/dlang/dmd/pull/5075 isn't run for the compiler generated __x* methods. --
[Issue 17601] [REG2.075.0-b1] segmentation fault for dmd -deps
https://issues.dlang.org/show_bug.cgi?id=17601 --- Comment #5 from Martin Nowak --- @Mario, try to avoid external dependencies in bug reports, but if you include them, please use a fixed commit/tag, so we can reproduce the issue. --
[Issue 17601] [REG2.075.0-b1] segmentation fault for dmd -deps
https://issues.dlang.org/show_bug.cgi?id=17601 --- Comment #4 from Martin Nowak --- The reduced case segfaults on invalid code, seems to be different from the reported issue. --
[Issue 17716] New: wrong result of IsExpression when not in static assert
https://issues.dlang.org/show_bug.cgi?id=17716
Issue ID: 17716
Summary: wrong result of IsExpression when not in static assert
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
struct S { shared int* foo; int* bar; }
static assert(!is(shared S : S)); /* passes */
pragma(msg, is(shared S : S)); /* "true" */
static if (is(shared S : S))
{
static assert(false); /* is triggered */
}
The `static assert` is correct.
The `pragma(msg, ...);` should print "false":
The body of the `static if` should not be entered.
Also happens with other qualifiers (const, immutable).
Depends on the order of the struct fields. When the unqualified fields comes
first, everything works as expected.
--
[Issue 17622] [REG2.075.0-b1] Wrong code with appender and -inline
https://issues.dlang.org/show_bug.cgi?id=17622 --- Comment #10 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/c73fe970c2014058b9544524d1809180db13cfbb fix Issue 17622 - [REG2.075.0-b1] Wrong code with appender and -inline https://github.com/dlang/dmd/commit/17473d2e6248da9fbb746ed8314b0ee488961156 Merge pull request #7056 from WalterBright/fix17622 fix Issue 17622 - [REG2.075.0-b1] Wrong code with appender and -inline merged-on-behalf-of: Martin Nowak --
[Issue 17622] [REG2.075.0-b1] Wrong code with appender and -inline
https://issues.dlang.org/show_bug.cgi?id=17622 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17713] Template 'this' parameters for static methods
https://issues.dlang.org/show_bug.cgi?id=17713 Steven Schveighoffer changed: What|Removed |Added CC||timos...@gmail.com --- Comment #2 from Steven Schveighoffer --- *** Issue 17714 has been marked as a duplicate of this issue. *** --
[Issue 17714] Function template - this T for static methods
https://issues.dlang.org/show_bug.cgi?id=17714 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution|--- |DUPLICATE --- Comment #1 from Steven Schveighoffer --- Huh, I think separately Timon Gehr added an almost identical issue right before you :) *** This issue has been marked as a duplicate of issue 17713 *** --
[Issue 17632] [REG 2.075-b1] opBinary and delegate code generation
https://issues.dlang.org/show_bug.cgi?id=17632 Martin Nowak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Martin Nowak --- *** This issue has been marked as a duplicate of issue 17622 *** --
[Issue 17622] [REG2.075.0-b1] Wrong code with appender and -inline
https://issues.dlang.org/show_bug.cgi?id=17622 Martin Nowak changed: What|Removed |Added CC||briancsch...@gmail.com --- Comment #9 from Martin Nowak --- *** Issue 17632 has been marked as a duplicate of this issue. *** --
[Issue 17713] Template 'this' parameters for static methods
https://issues.dlang.org/show_bug.cgi?id=17713 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --
[Issue 17715] New: Floating point numbers are printed as integers
https://issues.dlang.org/show_bug.cgi?id=17715 Issue ID: 17715 Summary: Floating point numbers are printed as integers Product: D Version: D2 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: pgkos.bugzi...@yahoo.com Currently, this example: writeln(1.01); prints just "1", probably because the call to snprintf inside phobos/format.d formatValue implementation for floats uses "%g" by default. It would be nice if the default formatter was e.g.: %.8g for float type %.16g for double type --
[Issue 17684] [REG 2.062] `static alias this` bug or incomplete implementation?
https://issues.dlang.org/show_bug.cgi?id=17684 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/9cdaed6e4b2259e883b6d716472516ac994e9d1e Fix Issue 17684 - [REG 2.062] static alias this Added newline at end of file https://github.com/dlang/dmd/commit/9df55228d2311e518c3fa4dfd7348facbcbcf775 Merge pull request #7055 from JinShil/stable Fix Issue 17684 - [REG 2.062] static alias this --
[Issue 17684] [REG 2.062] `static alias this` bug or incomplete implementation?
https://issues.dlang.org/show_bug.cgi?id=17684 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 --- Comment #7 from Johannes Pfau --- For reference: the missing symbol also causes a backend ICE for GCC <= 4.9: https://bugzilla.gdcproject.org/show_bug.cgi?id=157 This is fortunately of lower priority as an (unrelated) GCC change works around this problem in all new GCC versions. Fortunately we're already at GCC-7 released / GCC-8 in development :-) --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 --- Comment #6 from ki...@gmx.net --- (In reply to ZombineDev from comment #5) > > For LDC, I'm planning to allow the user to prevent template culling via a > > command-line switch, as the current implementation doesn't seem very mature. > > I think that's what dmd's -allinst switch does currently. [LDC uses the same logic and command-line switch.] I find it quite hard to tell the exact difference when using `-allinst` (and whether that includes speculative ones), as it's an early return of that function and the remaining needsCodegen() logic isn't trivial; the interaction with the tnext chain doesn't make it any simpler unfortunately. --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 --- Comment #5 from ZombineDev --- > For LDC, I'm planning to allow the user to prevent template culling via a > command-line switch, as the current implementation doesn't seem very mature. I think that's what dmd's -allinst switch does currently. --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #4 from ki...@gmx.net --- LDC ran into the same issue when moving to Phobos 2.074. I ended up switching from individual druntime/Phobos object file compilation to all-D-files-at-once compilation (like DMD), as that reduces the template instantiation culling [1]. See LDC PR [2]. This template culling, in combination with restructured Phobos, also leads to sometimes dramatic performance decreases due to less inlining potential with non-instantiated (culled) templates, rendering cross-module-inlining/LTO essential for best performance. See this (lenghty but interesting) LDC issue [3]. There's a link to a Weka.io-specific patch where they had to disable the culling due to linker errors. For LDC, I'm planning to allow the user to prevent template culling via a command-line switch, as the current implementation doesn't seem very mature. [1]: https://github.com/dlang/dmd/blob/v2.075.0/src/ddmd/dtemplate.d#L7197-L7205 [2]: https://github.com/ldc-developers/ldc/pull/2076#issuecomment-315175464 [3]: https://github.com/ldc-developers/ldc/issues/2168 --
[Issue 11252] "in" operator for std.range.iota
https://issues.dlang.org/show_bug.cgi?id=11252 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/80d1e84453e5a8c20ef53fd459ce641ca8df0d4e Issue 11252 - In operator requested for std.range.iota https://github.com/dlang/phobos/commit/017ca067e668546a5df0d5b45442e44ee225f266 Merge pull request #5629 from dukc/11252 Issue 11252 - In operator requested for std.range.iota merged-on-behalf-of: Jack Stouffer --
[Issue 17714] Function template - this T for static methods
https://issues.dlang.org/show_bug.cgi?id=17714 Timoses changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=14191 --
[Issue 14191] Failure to locate overload with template this parameter
https://issues.dlang.org/show_bug.cgi?id=14191 Timoses changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=17714 --
[Issue 17714] New: Function template - this T for static methods
https://issues.dlang.org/show_bug.cgi?id=17714
Issue ID: 17714
Summary: Function template - this T for static methods
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: timos...@gmail.com
For static method templates the this T will not work to deduce the calling
derived class/interface.
Although this information is present at compile-time, there seems to be no way
to easily access the calling derived class:
interface I
{
static void test(this T)()
{
writeln(T.type.stringof);
}
}
abstract class A
{
static void test(this T)()
{
writeln(T.type.stringof);
}
}
class B : A
{
alias type = uint;
}
class C : I {
alias type = int;
}
void main() {
B.test();
C.test();
}
Throws:
Error: template app.A.test cannot deduce function from argument types !()(),
candidates are:
app.A.test(this T)()
Error: template app.I.test cannot deduce function from argument types !()(),
candidates are:
app.I.test(this T)()
Shouldn't it be possible to access the class which is calling the static method
as easily as "this T" as template parameter? Would "this T" be too confusing,
as it is a static method and this does not really exist?
To simplify, the following should be possible in some way (if not via "this
T"):
class A
{
// T will be whatever class is calling this method
static void func (this T)() { };
}
A.func();
Possibly related issue:
https://issues.dlang.org/show_bug.cgi?id=14191
--
[Issue 17713] Template 'this' parameters for static methods
https://issues.dlang.org/show_bug.cgi?id=17713
er.kr...@gmail.com changed:
What|Removed |Added
CC||er.kr...@gmail.com
--- Comment #1 from er.kr...@gmail.com ---
I would add that they should really work pretty much everywhere in a class...
i.e. all kind of templates:
---
template isClass(T) {
static if (is(T == class)) {
enum isClass = true;
} else {
enum isClass = false;
}
}
template Super(C) if (isClass!C) {
import std.traits;
import std.meta;
static if (is(C == Object)) {
alias Super = AliasSeq!();
} else {
alias Parents = Filter!(isClass, BaseTypeTuple!C);
static assert (Parents.length == 1);
alias Super = Parents[0];
}
}
class A {
public:
enum desc = "class A";
template getDesc(this C) if (is(C == A)) {
enum getDesc = A.desc;
}
template getDesc(this C) if (!is(C == A)) {
enum getDesc = (Super!C).getDesc ~ " - " ~ C.desc;
}
}
class B : A {
enum desc = "class B";
}
class C : B {
enum desc = "class C";
}
void main() {
static assert(C.getDesc == "class A - class B - class C");
}
--
[Issue 17713] New: Template 'this' parameters for static methods
https://issues.dlang.org/show_bug.cgi?id=17713
Issue ID: 17713
Summary: Template 'this' parameters for static methods
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: timon.g...@gmx.ch
Template 'this' parameters should work even when the method is static.
For example:
mixin template Constructors(){
this(){ }
this()immutable{ }
this()shared{ }
}
class A {
public:
static C getInstance(this C)() {
return new C();
}
private:
mixin Constructors;
}
class B : A {
private:
mixin Constructors;
}
void main(){
auto a = A.getInstance();
auto b = B.getInstance();
static assert(is(typeof(a)==A));
static assert(is(typeof(b)==B));
auto ai = (immutable(A)).getInstance();
auto bs = (shared(B)).getInstance();
static assert(is(typeof(ai)==immutable(A)));
static assert(is(typeof(bs)==shared(B)));
}
Also see: http://forum.dlang.org/post/olv6se$1ohc$1...@digitalmars.com
--
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 --- Comment #3 from Iain Buclaw --- (In reply to ZombineDev from comment #2) > Definitely looks like a front-end bug to me. The link error does not happen when compiling the test with -unittest. So the specific location to look would be file dtemplate.d, function appendToModuleMember. The change in phobos was enough to make the instantiation speculative, so its arguable who's at fault. The compiler may be working as intended, though admittedly the whole design around speculative templates is not really backed by any spec. --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 Johannes Pfau changed: What|Removed |Added CC||johannesp...@gmail.com --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 ZombineDev changed: What|Removed |Added CC||petar.p.ki...@gmail.com --- Comment #2 from ZombineDev --- Definitely looks like a front-end bug to me. --
[Issue 17712] [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw --- This seems to be the breaking change: https://github.com/dlang/phobos/pull/5017 --
[Issue 17712] New: [REG 2.074] [LINK] Undefined reference to std.conv.toChars!(10, char, 1, uint).toChars(uint)
https://issues.dlang.org/show_bug.cgi?id=17712
Issue ID: 17712
Summary: [REG 2.074] [LINK] Undefined reference to
std.conv.toChars!(10, char, 1, uint).toChars(uint)
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ibuc...@gdcproject.org
Reduced test (with two selective imports).
---
struct Bytecode
{
uint data;
}
@trusted ctSub(U)(string format, U args)
{
import std.conv : to;
foreach (i; format)
return format~ to!string(args);
return format;
}
struct CtContext
{
import std.uni : CodepointSet;
CodepointSet[] charsets;
string ctAtomCode(Bytecode[] ir)
{
string code;
switch (code)
{
OrChar:
code ~= ``;
for (uint i ; i ;)
code ~= ctSub(``, ir[i].data);
charsets[ir[0].data].toSourceCode;
break;
default:
assert(0);
}
return code;
}
}
---
Causes link error.
---
backtracking.o: In function
`_D3std4conv17__T6toImplTAyaTkZ6toImplFNaNbNekkE3std5ascii10LetterCaseZAya':
__main.d:(.text._D3std4conv17__T6toImplTAyaTkZ6toImplFNaNbNekkE3std5ascii10LetterCaseZAya+0x5e):
undefined reference to
`_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6Result'
backtracking.o: In function
`_D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZAa':
__main.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZAa+0xd):
undefined reference to
`_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6Result6lengthMFNaNbNdNiNfZm'
__main.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZAa+0x4f):
undefined reference to
`_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6Result5emptyMFNaNbNdNiNfZb'
__main.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZAa+0x5c):
undefined reference to
`_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6Result5frontMFNaNbNdNiNfZa'
__main.d:(.text._D3std5array96__T5arrayTS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZ5arrayFNaNbNfS3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6ResultZAa+0x9f):
undefined reference to
`_D3std4conv47__T7toCharsVii10TaVE3std5ascii10LetterCasei1TkZ7toCharsFNaNbNiNfkZ6Result8popFrontMFNaNbNiNfZv'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
---
Prettified.
---
backtracking.o: In function `std.conv.toImpl!(immutable(char)[],
uint).toImpl(uint, uint, std.ascii.LetterCase)':
__main.d:(0x5e): undefined reference to `std.conv.toChars!(10, char, 1,
uint).toChars(uint)'
backtracking.o: In function `std.array.array!(std.conv.toChars!(10, char, 1,
uint).toChars(uint).Result).array(std.conv.toChars!(10, char, 1,
uint).toChars(uint).Result)':
__main.d:(0xd): undefined reference to `std.conv.toChars!(10, char, 1,
uint).toChars(uint).Result.length()'
__main.d:(0x4f): undefined reference to `std.conv.toChars!(10, char, 1,
uint).toChars(uint).Result.empty()'
__main.d:(0x5c): undefined reference to `std.conv.toChars!(10, char, 1,
uint).toChars(uint).Result.front()'
__main.d:(0x9f): undefined reference to `std.conv.toChars!(10, char, 1,
uint).toChars(uint).Result.popFront()'
collect2: error: ld returned 1 exit status
Error: linker exited with status 1
---
Does not happen with 2.073.
---
$ dmd-2073 backtracking.d -v 2>&1 | grep toChars.Result.popFront
function std.conv.toChars!(10, char, cast(LetterCase)true,
uint).toChars.Result.popFront
function std.conv.toChars!(16, char, cast(LetterCase)false,
uint).toChars.Result.popFront
function std.conv.toChars!(16, char, cast(LetterCase)true,
uint).toChars.Result.popFront
function std.conv.toChars!(2, char, cast(LetterCase)true,
uint).toChars.Result.popFront
function std.conv.toChars!(8, char, cast(LetterCase)true,
uint).toChars.Result.popFront
$ dmd-2074 backtracking.d -v 2>&1 | grep toChars.Result.popFront
function std.conv.toChars!(16, char, cast(LetterCas
