[Issue 12023] Regression 2.065-b2: template mixin fails within template class
https://issues.dlang.org/show_bug.cgi?id=12023 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/1df41dc6613e1e455e31136ac03b4102df5d54e1 Resolve forward reference in `VarDeclaration.toAlias()` After this change: 1. The check `!v.type` in `DsymbolExp.resolve` and `ScopeExp.semantic` will mean *unresolvable* forward reference. 2. The code for issue 12023 in `DsymbolExp.resolve` becomes cleaner. 3. Through the calls `AliasDeclaration.toAlias` and `VarDeclaration.toAlias`, selected import symbols will be resolved and `ice11300.d` case is made compilable. --
[Issue 15149] [2.068.2 regression] Linker error with separate compilation
https://issues.dlang.org/show_bug.cgi?id=15149 --- Comment #2 from yazan.dab...@gmail.com --- It does compile with -allinst as a workaround. This is a reduction of a project with multiple dependencies built using dub. My current workaround is using `dub --combined` to disable separate compilation. It is not blocking me but it is a regression. --
[Issue 15149] [2.068.2 regression] Linker error with separate compilation
https://issues.dlang.org/show_bug.cgi?id=15149 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- If you compile with -allinst dmd switch, does it work? --
[Issue 15150] New: [REG2.068.1] Public selective import causes conflict
https://issues.dlang.org/show_bug.cgi?id=15150
Issue ID: 15150
Summary: [REG2.068.1] Public selective import causes conflict
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
a.d
enum { x }
b.d
import a : x;
c.d
import a;
import b;
enum y = x;
/
c.d(4): Error: a.x at a.d(1) conflicts with a.x at b.d(1)
Introduced in https://github.com/D-Programming-Language/dmd/pull/4918
--
[Issue 15057] std.string.indexOf and friends do not accept custom types with alias this to string
https://issues.dlang.org/show_bug.cgi?id=15057 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- (In reply to Rainer Schuetze from comment #1) > related issue with rangified function in std.file: > https://issues.dlang.org/show_bug.cgi?id=15027 It's not just related, it's the same issue. --
[Issue 15110] pragma(inline) rarely works how I want it to
https://issues.dlang.org/show_bug.cgi?id=15110 --- Comment #6 from Manu --- There are cases where it should be valid to fail inlining, but shouldn't be an error. For instance, if I take the address of the function, that kinda implies it needs to emit an instance of the function... I shouldn't need to duplicate the function just because I take a function pointer in some situation. Another problem is that it's difficult to make all compilers inline with exactly the same behaviour, and what might work fine in one doesn't work in the other. I don't believe it's reasonable for this to emit a compile error when behaviour is different between compilers. You can't reliably build code anymore. It should just be a warning. The user needs to know when it doesn't inline, and they can then take appropriate action, but it shouldn't stop the program from compiling. That's highly annoying, it may create mutual-exclusions with other configurations where it works fine. It may very well be a niche configuration where it doesn't work (probably, since inhibitors would be addressed in the main configuration). There's no value in making it an error, it's only annoying, and results in code that's almost certainly brittle, since you have no idea whether your code will compile without errors unless you test every possible configuration. __forceinline/__attribute__((always_inline)). The behaviour is the same; it's a warning when inlining fails, and it would be extremely inconvenient (to the point of the feature being virtually useless) if it didn't behave this way. --
[Issue 15149] New: [2.068.2 regression] Linker error with separate compilation
https://issues.dlang.org/show_bug.cgi?id=15149
Issue ID: 15149
Summary: [2.068.2 regression] Linker error with separate
compilation
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: yazan.dab...@gmail.com
File structure:
a.d
b.d
a.d
import std.algorithm;
import b;
void main()
{
int[] foo;
setUnion(fun()[], foo);
}
b.d
module b;
auto fun()
{
import std.container;
return redBlackTree!int;
}
--
Compiling using `dmd -c a.d && dmd -c b.d && dmd *.o` succeeds except for
linker error:
a.o: In function
`_D3std9algorithm6setops119__T8SetUnionVAyaa5_61203c2062TS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5RangeTAiZ8SetUnion9__xtoHashFNbNeKxS3std9algorithm6setops119__T8SetUnionVAyaa5_61203c2062TS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5RangeTAiZ8SetUnionZm':
a.d:(.text._D3std9algorithm6setops119__T8SetUnionVAyaa5_61203c2062TS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5RangeTAiZ8SetUnion9__xtoHashFNbNeKxS3std9algorithm6setops119__T8SetUnionVAyaa5_61203c2062TS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5RangeTAiZ8SetUnionZm+0x18):
undefined reference to
`_D95TypeInfo_xS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5Range6__initZ'
a.d:(.text._D3std9algorithm6setops119__T8SetUnionVAyaa5_61203c2062TS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5RangeTAiZ8SetUnion9__xtoHashFNbNeKxS3std9algorithm6setops119__T8SetUnionVAyaa5_61203c2062TS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5RangeTAiZ8SetUnionZm+0x1f):
undefined reference to
`_D95TypeInfo_xS3std9container6rbtree41__T12RedBlackTreeTiVAyaa5_61203c2062Vbi0Z12RedBlackTree5Range6__initZ'
collect2: error: ld returned 1 exit status
--- errorlevel 1
Linker error happens with 2.068.2 but does not happen with 2.067.1.
--
[Issue 15148] Linker error with packages
https://issues.dlang.org/show_bug.cgi?id=15148 yazan.dab...@gmail.com changed: What|Removed |Added Severity|enhancement |normal --
[Issue 15148] New: Linker error with packages
https://issues.dlang.org/show_bug.cgi?id=15148
Issue ID: 15148
Summary: Linker error with packages
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: yazan.dab...@gmail.com
File structure:
app.d
p/package.d
- app.d -
import p;
void main()
{
a();
}
- p/package.d -
void a() {}
Compiling using `dmd app.d p/package.d` succeeds except for the linker failing
with:
app.o: In function `_Dmain':
p/package.d:(.text._Dmain+0x5): undefined reference to `_D1p1aFZv'
collect2: error: ld returned 1 exit status
--- errorlevel 1
Tested with 2.068.2 and 2.067.1.
--
[Issue 15137] core.time: Support Duration/Duration and Duration%Duration
https://issues.dlang.org/show_bug.cgi?id=15137 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/809b40a9b110b652ba4539679c292fbe068d5cab core.time: Implement Duration % Duration Fixes issue 15137 https://github.com/D-Programming-Language/druntime/commit/e02d47c8886bcf8bc969789c4dd1dbed4fdb90e8 core.time: Implement Duration / Duration Fixes issue 15137 https://github.com/D-Programming-Language/druntime/commit/8ddfb8dd711cc503fbe371ac7c4c26ed5caf1d0b Merge pull request #1401 from CyberShadow/pull-20151002-151147 fix Issue 15137 - core.time: Support Duration/Duration and Duration%Duration --
[Issue 15137] core.time: Support Duration/Duration and Duration%Duration
https://issues.dlang.org/show_bug.cgi?id=15137 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15144] Bad operand size in asm { movdqa ... } produces bogus ubyte16 initializer error elsewhere.
https://issues.dlang.org/show_bug.cgi?id=15144
--- Comment #1 from Marco Leise ---
Ok, using `movdqa XMM0, csXMM;` it works when the `SSEFromString` is changed to
declare the vector as __gshared instead of immutable. So DMD has trouble
sorting things out when they are read-only data.
void foo()
{
version (D_InlineAsm_X86_64)
{
alias csXMM = SSEFromString!`abc`;
asm @nogc nothrow
{
movdqa XMM0, csXMM;
}
}
else static assert(0, "Not implemented");
}
template SSEFromString(string str)
{
import std.algorithm, std.range;
version (DigitalMars)
__gshared ubyte16 SIMDFromString = chain(str,
'\0'.repeat(ubyte16.sizeof - str.length)).array;
else
immutable ubyte16 SIMDFromString = chain(str,
'\0'.repeat(ubyte16.sizeof - str.length)).array;
}
--
[Issue 8047] important opcodes missing from core/simd.d
https://issues.dlang.org/show_bug.cgi?id=8047 --- Comment #4 from Marco Leise --- //PMOVMSKB = 0x660FD7, has been commented out in core.simd. We may as well comment out all instructions returning non-XMM values until this is resolved. The ones I could find so far are: COMISD COMISS CVTSD2SI CVTSS2SI CVTTPD2PI CVTTPS2PI CVTTSD2SI CVTTSS2SI MASKMOVDQU MASKMOVQ MOVMSKPD MOVMSKPS PCMPESTRI PCMPISTRI PMOVMSKB PTEST UCOMISS UCOMISD CRC32, POPCNT and LZCNT don't belong in the XMM enum. They were introduced side-by-side with SSE4.2, but don't work on XMM registers and the latter two have their separate CPUID flags. --
[Issue 15147] New: std.random.uniform return value depends on integer size
https://issues.dlang.org/show_bug.cgi?id=15147
Issue ID: 15147
Summary: std.random.uniform return value depends on integer
size
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
With an RNG seeded with a constant value, uniform(0, 100) and uniform(0, 100L)
will return different values.
Demonstration:
// test.d //
import std.random;
import std.stdio;
void test(T)()
{
Mt19937 rng;
foreach (n; 0..10)
write(uniform(0, T(100), rng), " ");
writeln();
}
void main()
{
test!int();
test!uint();
test!long();
test!ulong();
}
This will print:
12 2 34 85 4 91 29 85 98 3
12 2 34 85 4 91 29 85 98 3
54 49 75 69 11 25 66 64 28 18
54 49 75 69 11 25 66 64 28 18
This can be a problem for applications that expect seeded RNGs to behave
predictably on all platforms (e.g. to generate something procedurally than must
be in sync), and pass a size_t to uniform. E.g.:
string sample = arr[uniform(0, $, rng)];
--
[Issue 15146] std.file.dirEntries("") only works on Windows
https://issues.dlang.org/show_bug.cgi?id=15146 Vladimir Panteleev changed: What|Removed |Added Keywords||pull --- Comment #1 from Vladimir Panteleev --- https://github.com/D-Programming-Language/phobos/pull/3690/files --
[Issue 15146] New: std.file.dirEntries("") only works on Windows
https://issues.dlang.org/show_bug.cgi?id=15146
Issue ID: 15146
Summary: std.file.dirEntries("") only works on Windows
Product: D
Version: D2
Hardware: All
OS: Other
Status: NEW
Severity: enhancement
Priority: P4
Component: phobos
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
/ test.d /
import std.algorithm.iteration;
import std.file;
import std.stdio;
void main()
{
dirEntries("", SpanMode.shallow).each!writeln;
}
//
This program runs fine on Windows, but throws on POSIX.
This is because POSIX opendir is defined to return ENOENT if the argument is an
empty string:
> [ENOENT] A component of dirname does not name an existing directory or
> dirname is an empty string.
Although the call to dirEntries can be changed to dirEntries("."), this has the
unpleasant effect of prepending "./" to all paths returned by dirEntries. It is
additionally a portability hazard (code that works on one OS but not another).
I thus propose to make dirEntries("") call opendir(".") under the hood.
--
[Issue 15144] Bad operand size in asm { movdqa ... } produces bogus ubyte16 initializer error elsewhere.
https://issues.dlang.org/show_bug.cgi?id=15144 Marco Leise changed: What|Removed |Added Keywords||iasm, SIMD --
[Issue 15145] New: Array initializers for SIMD not working inside functions.
https://issues.dlang.org/show_bug.cgi?id=15145
Issue ID: 15145
Summary: Array initializers for SIMD not working inside
functions.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: rejects-valid, SIMD
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: marco.le...@gmx.de
Practically this compiles:
import core.simd, std.range, std.array;
ubyte[16] a = ubyte(16).iota.array;
ubyte16 b = ubyte(16).iota.array;
But simply moving the definition inside a function does not work:
void main()
{
import core.simd, std.range, std.array;
ubyte16 b = ubyte(16).iota.array;
}
Error: cannot implicitly convert expression (array(iota(cast(ubyte)16u))) of
type ubyte[] to __vector(ubyte[16])
To be fair it works when you declare the vector as static, and that should
probably be done for performance, but it should not be an error and the message
is too general, as it works for static/global vectors.
--
[Issue 15144] New: Bad operand size in asm { movdqa ... } produces bogus ubyte16 initializer error elsewhere.
https://issues.dlang.org/show_bug.cgi?id=15144
Issue ID: 15144
Summary: Bad operand size in asm { movdqa ... } produces bogus
ubyte16 initializer error elsewhere.
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: marco.le...@gmx.de
--- CODE ---
void foo()
{
version (D_InlineAsm_X86_64)
{
alias csXMM = SSEFromString!`abc`;
asm @nogc nothrow
{
movdqa XMM0, [csXMM];
}
}
else static assert(0, "Not implemented");
}
template SSEFromString(string str)
{
import core.simd, std.algorithm, std.range;
enum ubyte16 SSEFromString = chain(str, '\0'.repeat(ubyte16.sizeof -
str.length)).array;
}
--- ---
Prints:
Error: integer constant expression expected instead of
cast(__vector(ubyte[16]))[cast(ubyte)97u, cast(ubyte)98u, cast(ubyte)99u,
cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u,
cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u,
cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u]
Error: bad type/size of operands 'movdqa'
The nature of the message (hinting at incorrect initializer syntax) makes you
think only integer constants are allowed in DMD as SIMD initializers, while in
fact, fixing the asm-block will make the primary error go away and the code
compile.
(Does this message still make any sense at all with SIMD? DMD accepts other
things than integer constants for a while now.)
--
[Issue 15138] ICE with basic use of stdx.data.json
https://issues.dlang.org/show_bug.cgi?id=15138 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #5 from Martin Nowak --- Can anyone try to reduce this using dustmite? --
[Issue 15006] Compiling trivial program produces 400,000+ byte object file
https://issues.dlang.org/show_bug.cgi?id=15006 --- Comment #4 from Martin Nowak --- Any update on that? Otherwise please close. --
[Issue 15143] New: core.demangle: Superfluous * when demangling function pointers
https://issues.dlang.org/show_bug.cgi?id=15143 Issue ID: 15143 Summary: core.demangle: Superfluous * when demangling function pointers Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com void function() fun; import std.demangle; pragma(msg, demangle(fun.mangleof)); This prints: void function()* test.fun The * is superfluous (as "function" already indicates a function pointer), and thus indicates a pointer to a function pointer. --
[Issue 15138] ICE with basic use of stdx.data.json
https://issues.dlang.org/show_bug.cgi?id=15138
Marc Schütz changed:
What|Removed |Added
OS|Windows |All
--- Comment #4 from Marc Schütz ---
Thanks, I can reproduce it now. Works in 2.068.1, broken in 2.068.2 and master.
dub.sdl:
name "aaa"
description "A minimal D application."
copyright "Copyright © 2015, marc"
authors "marc"
dependency "std_data_json" version="~>0.17.0"
source/app.d:
import stdx.data.json;
void main()
{
string str = `{"a": true, "b": "test"}`;
auto v = parseJSONValue(str);
// The following line causes the problem in 2.068.2
auto obj = v.get!(JSONValue[string]);
}
# dub test --force
core.exception.AssertError@dtemplate.d(6389): Assertion failure
Digger points to this PR:
https://github.com/D-Programming-Language/dmd/pull/5055
--
[Issue 12527] Cannot make @system function/delegate alias in a @safe section
https://issues.dlang.org/show_bug.cgi?id=12527 Vladimir Panteleev changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15142 --
[Issue 12529] Function/delegate type alias picks up @safe attribute from surrounding scope
https://issues.dlang.org/show_bug.cgi?id=12529 Vladimir Panteleev changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=15142 --
[Issue 15142] @trusted ignored on alias declarations when specified as prefix
https://issues.dlang.org/show_bug.cgi?id=15142 Vladimir Panteleev changed: What|Removed |Added Hardware|x86_64 |All See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=12527, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=12529 OS|Windows |All Severity|enhancement |normal --- Comment #1 from Vladimir Panteleev --- alias a = @trusted void function(); alias b = void function() @trusted; pragma(msg, a); pragma(msg, b); static assert(is(a == b)); --
[Issue 15142] New: @trusted ignored on alias declarations when specified as prefix
https://issues.dlang.org/show_bug.cgi?id=15142 Issue ID: 15142 Summary: @trusted ignored on alias declarations when specified as prefix Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: thecybersha...@gmail.com --
[Issue 15136] If we want toStringz to be fully correct, it needs to stop checking for '\0'
https://issues.dlang.org/show_bug.cgi?id=15136 John Colvin changed: What|Removed |Added CC||john.loughran.colvin@gmail. ||com --- Comment #2 from John Colvin --- It seem to me like this could happen with static arrays directly on the stack as well, depending on what variables the compiler happens to put directly after. --
[Issue 15141] New: Object.factory allows the creation of derived abstract classes
https://issues.dlang.org/show_bug.cgi?id=15141
Issue ID: 15141
Summary: Object.factory allows the creation of derived abstract
classes
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: atila.ne...@gmail.com
Object.factory returns null for abstract classes, unless they're a child class.
Trying to use this class and calling .method on it causes a crash.
The second assertion fails, it shouldn't:
module factory_test;
class Abstract {
abstract void method();
}
class Middle: Abstract { }
void main() {
auto abs = Object.factory("factory_test.Abtract");
assert(abs is null);
auto mid = Object.factory("factory_test.Middle");
assert(mid is null); //oops
//auto mid2 = new Middle; //doesn't compile
}
--
[Issue 14782] Internal error: backend/cod1.c
https://issues.dlang.org/show_bug.cgi?id=14782 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright --- https://github.com/D-Programming-Language/dmd/pull/5154 --
