[Issue 6400] opDispatch with WithStatement
https://issues.dlang.org/show_bug.cgi?id=6400
Philpax changed:
What|Removed |Added
CC||m...@philpax.me
--- Comment #3 from Philpax ---
Just ran into this issue. From a cursory look at DMD's source code, I noticed
that WithStatement::semantic was adding the symbol's scope before calling
body->semantic, which means WithStatement has the same scoping rules as a
method.
This means that the problem is that opDispatch doesn't work in symbol scope:
struct A
{
void opDispatch(string Value)()
{
pragma(msg, Value);
}
void test()
{
// works
this.hello;
// NG
hello;
}
}
I'm unsure as to whether this is intended behaviour or not, but resolving the
opDispatch scope issue would also resolve this issue.
--
[Issue 14802] Template argument deduction depends on order of arguments
https://issues.dlang.org/show_bug.cgi?id=14802 Kenji Hara changed: What|Removed |Added Keywords||pull, wrong-code --- Comment #7 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4818 --
[Issue 14807] unnecessary closure allocation for function literal in compile time test
https://issues.dlang.org/show_bug.cgi?id=14807
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #1 from ag0ae...@gmail.com ---
Silly workaround: Pass the literal to another literal that takes a scope
delegate.
void foo(int a) @nogc
{
static if (__traits(compiles,
(scope void delegate()){}(
{ a = 2; }
)
))
{}
}
--
[Issue 14807] New: unnecessary closure allocation for function literal in compile time test
https://issues.dlang.org/show_bug.cgi?id=14807
Issue ID: 14807
Summary: unnecessary closure allocation for function literal in
compile time test
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
void foo(int a) @nogc
{
static if (__traits(compiles, { a = 2; }))
{}
}
CODE
bug.d(1): Error: function bug.foo @nogc function allocates a closure with the
GC
Not sure if it's easy to detect the context of a function literal and see that
it can never be called.
--
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #36 from Vladimir Panteleev --- Question, is there any overhead in actually verifying the validity of UTF-8 streams, or is all overhead related to error handling (i.e. inability to be nothrow)? --
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #35 from Jonathan M Davis --- (In reply to Martin Nowak from comment #32) > Summary: > > We should adopt a new model of unicode validations. > The current one where every string processing function decodes unicode > characters and performs validation causes too much overhead. > A better alternative would be to perform unicode validation once when > reading raw data (ubyte[]) and then assume any char[]/wchar[]/dchar[] is a > valid unicode string. > Invalid encodings introduced by string processing algorithms are programming > bugs and thus do not warrant runtime checks in release builds. Exactly. --
[Issue 14571] [REG2.064] Large static arrays seem to lock up DMD
https://issues.dlang.org/show_bug.cgi?id=14571 --- Comment #22 from ag0ae...@gmail.com --- The newly opened issue 14805 is probably an overlooked variant of this. --
[Issue 14805] Unreasonably slow "new Struct[large]"
https://issues.dlang.org/show_bug.cgi?id=14805 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #2 from ag0ae...@gmail.com --- Probably related to the very similar issue 14571. --
[Issue 14806] New: alias this doesn't force elaborate equality, but is followed during it
https://issues.dlang.org/show_bug.cgi?id=14806
Issue ID: 14806
Summary: alias this doesn't force elaborate equality, but is
followed during it
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: wrong-code
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ag0ae...@gmail.com
Found by TC, who posted to D.learn:
http://forum.dlang.org/post/ohkyebycxuszarhtb...@forum.dlang.org
Either both asserts should pass, or they should both fail.
With dmd 2.062 and older both asserts pass.
struct Nullable
{
float get() {return float.nan;}
alias get this;
}
struct Foo(T)
{
T bar;
Nullable baz;
}
void main()
{
Foo!int a, b;
assert(a == b); /* passes, as Nullable.init == Nullable.init */
Foo!string c, d;
assert(c == d); /* fails, as float.init != float.init */
}
--
[Issue 14805] Unreasonably slow "new Struct[large]"
https://issues.dlang.org/show_bug.cgi?id=14805
Ivan Kazmenko changed:
What|Removed |Added
CC||ga...@mail.ru
--- Comment #1 from Ivan Kazmenko ---
Same here.
Maybe it generates an instance of the array at compile time?
Compile-time function execution is known to be slow.
Interestingly,
void main () {auto dummy = new Struct[513 * 513];}
and even
void main () {enum dummy = new Struct[513 * 513];}
compile just fine.
--
[Issue 14805] New: Unreasonably slow "new Struct[large]"
https://issues.dlang.org/show_bug.cgi?id=14805
Issue ID: 14805
Summary: Unreasonably slow "new Struct[large]"
Product: D
Version: D2
Hardware: x86_64
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: wyr...@gmx.net
struct Struct
{
ushort one;
}
auto dummy = new Struct[513*513];
The above program takes ~50s to compile on a modern computer.
No difference between:
v2.067.1
v2.068.0-b1
--
[Issue 14626] [REG2.066] byValue doesn't work with inout AA
https://issues.dlang.org/show_bug.cgi?id=14626 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14626] [REG2.066] byValue doesn't work with inout AA
https://issues.dlang.org/show_bug.cgi?id=14626 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to stable at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/6d57c68df1f72e9416548ad450e56a16bb1fdb90 fix Issue 14626 - byValue doesn't work with inout AA Until 2.065, compiler had substituted all `inout` qualifiers in the `Key` and `Value` types to `const`, then those had passed to the template struct `AssociativeArray`. https://github.com/D-Programming-Language/dmd/blob/v2.065.0/src/mtype.c#L4897 This change emulates that. https://github.com/D-Programming-Language/druntime/commit/ad900eb3cc38397c4fa3a0a805793f002d03abc7 Merge pull request #1326 from 9rnsr/fix14626 [REG2.066] Issue 14626 - byValue doesn't work with inout AA --
[Issue 14804] New: Comparing two Nullables does not check if either is null
https://issues.dlang.org/show_bug.cgi?id=14804
Issue ID: 14804
Summary: Comparing two Nullables does not check if either is
null
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
Currently, comparing two Nullables does not check if either is null. If either
of them are, Nullable.get will assert.
import std.typecons;
void main()
{
Nullable!int n1 = 0;
Nullable!int n2;
Nullable!int n3;
assert(n1 == n2); //Nullable.get asserts
assert(n2 == n3); //Nullable.get asserts
}
Instead a custom opEquals should be implemented that checks if either Nullable
is null before comparing their values. They should behave as shown below:
Nullable!int n4 = 0;
assert(n1 == n2); //n2 is null; returns false
assert(n2 == n3); //n2 and n3 are null; returns false
//Both n1 and n4 and non-null, so compare their values;
//Returns true
assert(n1 == n4);
--
[Issue 14803] New: successful static assert can change result of compilation
https://issues.dlang.org/show_bug.cgi?id=14803
Issue ID: 14803
Summary: successful static assert can change result of
compilation
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: r.sagita...@gmx.de
This compiles successfully:
enum hasElaborateAssign(T) = is(typeof(foo!T())) || true;
//static assert(hasElaborateAssign!int);
static assert(is(typeof(foo!int(;
void foo(T)()
{
static assert(hasElaborateAssign!T);
}
but when uncommenting the first assertion, the second assert fails with
error test.d(5): Error: static assert (is(typeof(__error))) is false
--
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #34 from Vladimir Panteleev --- (In reply to Martin Nowak from comment #31) > BTW, this is what I already wrote in comment 23. Not sure why you only > partially quoted my answer to suggest a contradiction. Err, well, to be fair, you did not state this clearly in comment 23, which is why I asked for a clarification. I was not trying to maliciously nitpick your words, just tried to understand your point. --
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #33 from Sobirari Muhomori --- Removing autodecoding is good, but this issue is about making autodecode @nothrow @nogc. --
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #32 from Martin Nowak --- Summary: We should adopt a new model of unicode validations. The current one where every string processing function decodes unicode characters and performs validation causes too much overhead. A better alternative would be to perform unicode validation once when reading raw data (ubyte[]) and then assume any char[]/wchar[]/dchar[] is a valid unicode string. Invalid encodings introduced by string processing algorithms are programming bugs and thus do not warrant runtime checks in release builds. Also see https://github.com/D-Programming-Language/druntime/pull/1279 --
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #31 from Martin Nowak --- (In reply to Martin Nowak from comment #30) > Well, b/c they contain delimited binary and ASCII data, you'll have to find > those delimiters, then validate and cast the ASCII part to a string, and can > then use std.string functions. BTW, this is what I already wrote in comment 23. Not sure why you only partially quoted my answer to suggest a contradiction. --
[Issue 14519] Get rid of unicode validation in string processing
https://issues.dlang.org/show_bug.cgi?id=14519 Martin Nowak changed: What|Removed |Added Summary|[Enh] foreach on strings|Get rid of unicode |should return |validation in string |replacementDchar rather |processing |than throwing | --
[Issue 14519] [Enh] foreach on strings should return replacementDchar rather than throwing
https://issues.dlang.org/show_bug.cgi?id=14519 --- Comment #30 from Martin Nowak --- (In reply to Vladimir Panteleev from comment #29) > (In reply to Martin Nowak from comment #28) > > Yes, and you would be better off to handle such protocols as ubyte. > > What do you mean? Aren't you contradicting yourself from when you wrote: > > > No one is suggesting you operate on ubyte[] as string. > > ? Well, b/c they contain delimited binary and ASCII data, you'll have to find those delimiters, then validate and cast the ASCII part to a string, and can then use std.string functions. --
