[Issue 12114] buildNormalizedPath shouldn't normalize current path to empty string
https://issues.dlang.org/show_bug.cgi?id=12114
Thibaut CHARLES changed:
What|Removed |Added
CC||cro...@gmail.com
--- Comment #2 from Thibaut CHARLES ---
What should happen if you do buildNormalizedPath(".", "") ?
--
[Issue 5050] No way to declare delegates with ref return
https://issues.dlang.org/show_bug.cgi?id=5050 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright --- You can do it with an alias: alias ref int delegate(ref int) dg_t; dg_t r = ...; --
[Issue 13832] New: delegates that return ref do not output correctly to .di file
https://issues.dlang.org/show_bug.cgi?id=13832 Issue ID: 13832 Summary: delegates that return ref do not output correctly to .di file Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: bugzi...@digitalmars.com The source code: alias ref int delegate() dg_t; when compiled with: dmd -c -H test.d yields a .di file with: alias int delegate() dg_t; in it. The 'ref' got dropped, but it is still there as part of the type. --
[Issue 13830] Circular dependency between interface and implementation segfault the compiler
https://issues.dlang.org/show_bug.cgi?id=13830 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Kenji Hara --- The segfault is a dup of issue 13668, and fortunately it's already fixed in git-head. *** This issue has been marked as a duplicate of issue 13668 *** --
[Issue 13668] [ICE] unable to compile __traits(allMembers...)
https://issues.dlang.org/show_bug.cgi?id=13668 Kenji Hara changed: What|Removed |Added CC||pro.mathias.l...@gmail.com --- Comment #3 from Kenji Hara --- *** Issue 13830 has been marked as a duplicate of this issue. *** --
[Issue 13830] Circular dependency between interface and implementation segfault the compiler
https://issues.dlang.org/show_bug.cgi?id=13830 Dicebot changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #1 from Dicebot --- Does changing `Impl` to alias parameter instead of type parameter change anything? Anyway, compiler shouldn't crash. Please paste here exact ICE error line too. --
[Issue 13831] DMD crash
https://issues.dlang.org/show_bug.cgi?id=13831 --- Comment #1 from Mr. Smith --- Created attachment 1459 --> https://issues.dlang.org/attachment.cgi?id=1459&action=edit Crash dump --
[Issue 13831] DMD crash
https://issues.dlang.org/show_bug.cgi?id=13831 Mr. Smith changed: What|Removed |Added Keywords||ice --
[Issue 13831] New: DMD crash
https://issues.dlang.org/show_bug.cgi?id=13831
Issue ID: 13831
Summary: DMD crash
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: mrsmit...@yandex.ru
Crashes both on windows and linux, both m32 and m64.
Tested with 2.066, 2.066.1, master
---
struct Vector()
{
}
struct ChunkCoord
{
union
{
struct
{
short x;
}
Vector!() vector;
}
}
struct Chunk
{
this(ChunkCoord)
{
coord = coord;
}
ChunkCoord coord;
static Chunk* unknownChunk = new Chunk(ChunkCoord());
}
---
--
[Issue 6256] [patch] std.algorithm.map does not support static arrays and has 'length' for narrow strings.
https://issues.dlang.org/show_bug.cgi?id=6256 --- Comment #7 from bearophile_h...@eml.cc --- (In reply to Jonathan M Davis from comment #6) > So, I think that benchmarks which show a significant improvement with static > arrays being special-cased would be required for it to be worth considering. I agree. --
[Issue 1829] Inline assembler cannot get label addresses
https://issues.dlang.org/show_bug.cgi?id=1829 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #11 from bearophile_h...@eml.cc --- (In reply to Orvid King from comment #10) > It appears I failed to add the word fixes to the description of the commit, > so this wasn't auto-marked as resolved when the PR was merged. I'd like to see somewhere a working example of jump table in D. --
[Issue 12971] Missing REX prefix for 8 bit register access
https://issues.dlang.org/show_bug.cgi?id=12971 safety0ff.bugz changed: What|Removed |Added Summary|DMD inline asm outputs |Missing REX prefix for 8 |wrong AND instruction |bit register access --- Comment #3 from safety0ff.bugz --- Likely affects SPL, BPL, SIL and DIL since they all require REX. --
[Issue 13830] New: Circular dependency between interface and implementation segfault the compiler
https://issues.dlang.org/show_bug.cgi?id=13830
Issue ID: 13830
Summary: Circular dependency between interface and
implementation segfault the compiler
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pro.mathias.l...@gmail.com
I tried to use the CRTP in D to generate an interface at compile time based on
another interface and the implementation. Unfortunately, it segfaulted the
compiler.
import std.stdio, std.traits;
template RESTServer(I, Impl) {
private abstract class IRESTServer/* : I*/ {
//final override void test() { assert(0); }
void test(Context ctx);
}
int abuseTheCompiler() {
foreach (method; __traits(allMembers, Impl)) {
foreach (overload; MemberFunctionsTuple!(Impl, method))
{
pragma(msg, __traits(identifier, overload));
}
}
return 42;
}
static assert(abuseTheCompiler());
alias RESTServer = IRESTServer;
}
struct Context { string ip; }
interface MyAPI { void test(); }
class MyAPIImpl : RESTServer!(MyAPI, MyAPIImpl) {
override:
void test(Context ctx) {
writeln(ctx.ip);
}
}
void main() {
auto c = new MyAPIImpl();
c.test(Context("10.24.50.42"));
}
Question: should such code be valid ? It allows an interesting pattern for code
generators.
--
[Issue 1829] Inline assembler cannot get label addresses
https://issues.dlang.org/show_bug.cgi?id=1829 Orvid King changed: What|Removed |Added Status|NEW |RESOLVED CC||blah38...@gmail.com Resolution|--- |FIXED --- Comment #10 from Orvid King --- It appears I failed to add the word fixes to the description of the commit, so this wasn't auto-marked as resolved when the PR was merged. --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #5 from Rainer Schuetze --- AFAIK the heap on OSX starts 0x 0x1__, so your "b" members create false pointers into the memory chunks into the arrays allocated in the while(true) loop. That's why they are never collected. You might want to try one of the proposed precise GCs: https://github.com/D-Programming-Language/druntime/pull/1022 or https://github.com/D-Programming-Language/druntime/pull/1057 --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 Ben Grabham changed: What|Removed |Added CC||dl...@chillichef.com --- Comment #9 from Ben Grabham --- I just hit this bug too and I wasn't so fortunate as to realise that classes that implement an interface need override but classes that extend and abstract class which implements an interface must not have the "override" attribute. Please make it consistent! --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 --- Comment #4 from Ben Grabham --- The initial test was on: DMD64 D Compiler v2.066.1 I just tested it on (dmd master): DMD v2.067-devel-8ff302a DEBUG It takes up insane amounts of memory on both. (only tested on mac) --
[Issue 6196] with statement with single statement breaks linking
https://issues.dlang.org/show_bug.cgi?id=6196 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #9 from Andrej Mitrovic --- (In reply to hsteoh from comment #8) > Seems to have been fixed in git HEAD; could you re-test? Yeah I can confirm it works now.. although I'm worried it's just a side-effect of any import changes we might have made within std.stdio, and the actual problem not being properly fixed. We'll see if it resurfaces. --
[Issue 13420] double.nan unusable as AA key
https://issues.dlang.org/show_bug.cgi?id=13420 --- Comment #12 from Marc Schütz --- (In reply to Martin Nowak from comment #10) > > Maybe the AA implementation should assert that keys added to it should be > > equal to themselves. > > Sorry for breaking your code, but this check seems exaggerated. > An AA implementation has to rely on a working equality comparison and hash. > > As floats are builtin types we should special case the AA implementation to > perform some extra checks, e.g. disallow NaN as key value. > See bug 13581 for an enhancement request. > I don't think we should special-case floats. As you said, AA has to rely on a working equality comparison and hash, and the way to verify that is to use an assert. --
[Issue 13801] Garbage collector fails to work after lots of small allocations
https://issues.dlang.org/show_bug.cgi?id=13801 Marc Schütz changed: What|Removed |Added CC||schue...@gmx.net --- Comment #3 from Marc Schütz --- FWIW, I can't reproduce it on x86_64 Linux with DMD master. I've even raised the multiplier up to 128000, and RES stayed at a modest 19MB. --
[Issue 13829] std.uni.byCodePoint for strings has length
https://issues.dlang.org/show_bug.cgi?id=13829 --- Comment #1 from Marc Schütz --- In case it wasn't clear: For strings and wstrings, determining the actual number of code points is an O(n) operation and should therefore not be available via length at all. The current implementation returns the number of code units, not of code points. --
[Issue 13829] New: std.uni.byCodePoint for strings has length
https://issues.dlang.org/show_bug.cgi?id=13829
Issue ID: 13829
Summary: std.uni.byCodePoint for strings has length
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: schue...@gmx.net
import std.uni;
static assert(__traits(compiles, "é".byCodePoint.length));
pragma(msg, typeof("é".byCodePoint)); // => string
The problem is that `byCodePoint(w?string.init)` returns its argument
(string/wstring) which of course defines `length`, instead of a wrapper that
doesn't.
The reason is once again auto-decoding. In std/uni.d(6644):
Range byCodePoint(Range)(Range range)
if(isInputRange!Range && is(Unqual!(ElementType!Range) == dchar))
{
return range;
}
`Unqual!(ElementType!string)` is of course `dchar`.
Brought up in this discussion:
http://forum.dlang.org/thread/ovzcetxbrdblpmyiz...@forum.dlang.org#post-ovzcetxbrdblpmyizdjr:40forum.dlang.org
--
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827 --- Comment #4 from Temtaime --- Thanks. It worked in 2.066. :) P.S. +1 for 42 --
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827 --- Comment #3 from Ketmar Dark --- p.s. i'm not even sure that this is supposed to work in compile-time. --
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827
Ketmar Dark changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--- Comment #2 from Ketmar Dark ---
struct Matrix(T) {
private static defaultMatrix() {
T arr[3];
return arr;
}
union {
T[3] A = defaultMatrix;
T[3] flat;
}
this (T v) {
flat[0] = v;
}
}
enum S = Matrix!int(42);
--
[Issue 13828] New: std.random not @nogc aware
https://issues.dlang.org/show_bug.cgi?id=13828 Issue ID: 13828 Summary: std.random not @nogc aware Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: alil...@gmail.com std.random doesn't contain "@nogc". I stumbled upon it since I have @nogc audio callbacks that involves noise generator that calls std.random.uniform, and this function isn't @nogc. --
[Issue 13827] Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827
--- Comment #1 from Temtaime ---
Reduced more:
struct Matrix(T, uint N) {
private static defaultMatrix() {
T arr[N];
return arr;
}
union {
T[N] A = defaultMatrix;
T[N] flat;
}
this(A...)(auto ref in A args) {
uint k;
foreach(ref v; args)
flat[k++] = cast(T)v;
}
}
enum S = Matrix!(int, 3)(1, 2, 3);
--
[Issue 13827] New: Internal Compiler Error: null field
https://issues.dlang.org/show_bug.cgi?id=13827
Issue ID: 13827
Summary: Internal Compiler Error: null field
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: temta...@gmail.com
mixin template VectorImpl() {
this(A...)(auto ref in A args) {
uint k;
foreach(ref v; args)
flat[k++] = cast(T)v;
}
}
struct Matrix(T, uint _M, uint _N = _M) {
enum {
M = _M, //rows
N = _N, //columns
C = M * N, // count of elements
isVector = N == 1 || M == 1,
}
private static defaultMatrix() {
T arr[M][N] = void;
foreach(i, ref v; arr) {
v[] = 0;
static if(M == N) v[i] = 1;
}
return arr;
}
union {
T[N][M] A = defaultMatrix;
T[C] flat;
}
mixin VectorImpl;
}
alias Vector(T, uint M) = Matrix!(T, 1, M);
alias Vector3 = Vector!(float, 3);
enum isMatrix(T) = is(T == Matrix!A, A...);
template isVector(T) {
static if(isMatrix!T) enum isVector = T.isVector;
else enum isVector = false;
}
enum S = Vector3(1, 2, 3);
void main() {
}
main.d(6): Error: Internal Compiler Error: null field flat
main.d(6): Error: cannot determine length of this.flat at compile time
main.d(50):called from here: Matrix([[0.00F, 0.00F,
0.00F]], ).this(1, 2, 3)
Maybe one can reduce it more. This code compiles on 2.066.
--
[Issue 6256] [patch] std.algorithm.map does not support static arrays and has 'length' for narrow strings.
https://issues.dlang.org/show_bug.cgi?id=6256 Jonathan M Davis changed: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #6 from Jonathan M Davis --- If you want to argue for a special overload for static arrays, please open a new enhancement request. However, in general, I think that supporting static arrays with range-based functions is just asking for trouble, because they're not ranges (e.g. popFront does not and cannot work for them). So, I think that benchmarks which show a significant improvement with static arrays being special-cased would be required for it to be worth considering. --
