[Issue 5993] Strange thread exceptions with DMD 2.053 beta 13th May
https://issues.dlang.org/show_bug.cgi?id=5993 Infiltrator changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15288] The precedence of the exponentiation operator ^^ is too high.
https://issues.dlang.org/show_bug.cgi?id=15288 Shriramana Sharma changed: What|Removed |Added CC||samj...@gmail.com --
[Issue 15431] New: pragma mangle and mangleof are order dependent
https://issues.dlang.org/show_bug.cgi?id=15431
Issue ID: 15431
Summary: pragma mangle and mangleof are order dependent
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: alphaglosi...@gmail.com
Given some test code as:
pragma(msg, mySymbol.mangleof);
pragma(mangle, "_mySymbolIsThis")
void mySymbol() {
import std.stdio : writeln;
writeln("mySymbol");
}
pragma(msg, mySymbol.mangleof);
The output is:
_D4f2008mySymbolFZv
_mySymbolIsThis
The order of mangleof should not matter to the output.
It's silly because extern(C) is taking more into account then pragma(mangle is
here.
--
[Issue 15429] [std.stdio] Broken link in documentation
https://issues.dlang.org/show_bug.cgi?id=15429 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/e90edec9b6961fb0d78128abc876386b2de9e409 fix issue 15429 - [std.stdio] Broken link in documentation https://github.com/D-Programming-Language/phobos/commit/574734500e1800d9c43b73103f3005f34890a90c Merge pull request #3867 from aG0aep6G/15429 fix issue 15429 - [std.stdio] Broken link in documentation --
[Issue 15429] [std.stdio] Broken link in documentation
https://issues.dlang.org/show_bug.cgi?id=15429 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15430] New: amdMmx hangs up
https://issues.dlang.org/show_bug.cgi?id=15430
Issue ID: 15430
Summary: amdMmx hangs up
Product: D
Version: D2
Hardware: All
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kdm...@ya.ru
This code hangs up on amdMmx if it is compiled by dmd 2.069.2, but works well
if compiled by dmd 2.068.2.
void main()
{
import core.cpuid;
import std.stdio;
if (amdMmx)
writeln("amdMmx");
}
Configuration:
Microsoft Windows 7 Professional 6.1.7601 Service Pack 1 64-bit
CPU Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz, 2801 МГц
NVIDIA NVS 4200M
--
[Issue 4668] Troubles with 'auto ref'
https://issues.dlang.org/show_bug.cgi?id=4668
ag0ae...@gmail.com changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #2 from ag0ae...@gmail.com ---
(In reply to Infiltrator from comment #1)
> int foo(T)(auto ref T[] arr) { // The auto is invalid as we already have ref
> T[] to specify the type
The auto is fine. http://dlang.org/spec/template.html#auto-ref-parameters
That said, the compiler seems to behave differently now than when the bug was
filed. `&foo!int` is rejected in all cases, now. I'm not sure what exactly the
report is asking for, so this may or may not be good enough to close the issue.
--
[Issue 15429] [std.stdio] Broken link in documentation
https://issues.dlang.org/show_bug.cgi?id=15429 ag0ae...@gmail.com changed: What|Removed |Added Keywords||pull CC||ag0ae...@gmail.com Assignee|nob...@puremagic.com|ag0ae...@gmail.com Severity|enhancement |trivial --- Comment #1 from ag0ae...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/3867 --
[Issue 15422] [REG2.066] associative array of nested struct - crash on usage
https://issues.dlang.org/show_bug.cgi?id=15422 Kenji Hara changed: What|Removed |Added Keywords||pull Summary|associative array of nested |[REG2.066] associative |struct - crash on usage |array of nested struct - ||crash on usage --- Comment #3 from Kenji Hara --- (In reply to Ivan Kazmenko from comment #1) > With dmd 2.065.0, it does not compile, complaining that there is no opCmp > for `Foo`s. > > With dmd 2.066.0, and up to the current version dmd 2.069.2, it compiles > fine but crashes at runtime. > > So I'd say it's a regression somewhere between 2.064 and 2.066. The guilty commit had been introduced in 2.065, but the actual problem had been hidden until 2.066 was released, by the compiler's "no opCmp" complaint. PR to fix the issue: https://github.com/D-Programming-Language/dmd/pull/5304 --
[Issue 15422] associative array of nested struct - crash on usage
https://issues.dlang.org/show_bug.cgi?id=15422 Kenji Hara changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Kenji Hara --- Introduced in: https://github.com/d-programming-language/dmd/commit/a2f9ddf4eb7d5ffeb4bb157d5dcda9efe2f5b290 The main problem is that, built-in generated hashing operations don't handle hidden context field (foo.tupleof[$-1]) properly. I discovered that built-in generated equality operations also have equivalent issue. --
[Issue 15401] partialSort should accept two ranges
https://issues.dlang.org/show_bug.cgi?id=15401 --- Comment #4 from Andrei Alexandrescu --- (In reply to Infiltrator from comment #3) > (In reply to Andrei Alexandrescu from comment #2) > > (In reply to Infiltrator from comment #1) > > > Once issue 15421 is fixed, this is a simple matter of > > > topN(l, r); > > > sort(l); > > > > > > Which brings us to the question of: should partialSort(Range, index) be > > > changed to call partialSort(r[0..n], r[n..$]) to reduce duplication or is > > > there a large performance difference in the two topNs? > > > > Affirmative. > > Sorry, do you mean affirmative to how to implement partialSort(Range, Range); > or affirmative to changing partialSort(Range, index) to call the (Range, > Range) version; > or affirmative to there being too large of a performance difference between > the two versions of topN? My bad, I missed the "or". I don't think there's a loss of efficiency if partialSort with index calls partialSort with the two subranges. --
[Issue 5137] Compiler tips
https://issues.dlang.org/show_bug.cgi?id=5137 --- Comment #2 from bearophile_h...@eml.cc --- (In reply to Infiltrator from comment #1) > I don't know whether it's necessary to add another class of compiler > messages. It might be enough to just make these warnings. It would be > helpful especially useful for @nogc. Warnings are meant to warn you against something. Compiler tips are more like suggestions (but it's not an essential difference, I agree. What's important is to produce some message). The compilers of other good languages have such kind of messages, so they can be good for D too. --
[Issue 5376] writeln doesn't print immutable lazy sequences
https://issues.dlang.org/show_bug.cgi?id=5376 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from bearophile_h...@eml.cc --- (In reply to Infiltrator from comment #2) > 2.069 prints the types and contents of the sequences: > > [-1, -2, -3] > const(MapResult!(unaryFun, const(int)[]))([1, 2, 3]) > immutable(MapResult!(unaryFun, immutable(int)[]))([1, 2, 3]) > > > Is this acceptable? Yes, closed. --
[Issue 14367] Print warnings by default
https://issues.dlang.org/show_bug.cgi?id=14367 --- Comment #7 from bearophile_h...@eml.cc --- (In reply to Don from comment #5) > Bearophile's comment 4 is something different. It is a real issue. I think > it would best be fixed by removing warnings from the compiler entirely > (which is in practice what Bearophile is asking for, if they are enabled by > default they are just errors). Nope. Warnings active on default should not stop compilation. So they are still different from errors. (Note that other good languages acts like I have suggested D to act). What I am asking is an obvious improvement for the D compiler. --
[Issue 4945] Bad error message with wrong struct literal
https://issues.dlang.org/show_bug.cgi?id=4945 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 8892 *** --
[Issue 8892] Wrong diagnostic for static array assignment
https://issues.dlang.org/show_bug.cgi?id=8892 --- Comment #11 from Kenji Hara --- *** Issue 4945 has been marked as a duplicate of this issue. *** --
[Issue 5540] Probable bug-hiding redundancies
https://issues.dlang.org/show_bug.cgi?id=5540 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #7 from Infiltrator --- I think that you're being a little too zealous. For instance, foo() in your last example, and any function in general, may not necessarily be pure (in the mathematical sense) so they may produce different results and/or side-effects. --
[Issue 15422] associative array of nested struct - crash on usage
https://issues.dlang.org/show_bug.cgi?id=15422 Ivan Kazmenko changed: What|Removed |Added CC||ga...@mail.ru Summary|Crash on nested struct |associative array of nested ||struct - crash on usage --- Comment #1 from Ivan Kazmenko --- Able to reproduce this on win32/win64. Original D.learn forum thread is mentioned in URL. An extract from there: With dmd 2.064.2, the example compiles and runs fine. With dmd 2.065.0, it does not compile, complaining that there is no opCmp for `Foo`s. With dmd 2.066.0, and up to the current version dmd 2.069.2, it compiles fine but crashes at runtime. So I'd say it's a regression somewhere between 2.064 and 2.066. --
[Issue 6218] Stack trace possible improvement
https://issues.dlang.org/show_bug.cgi?id=6218 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- I know that the stack trace was improved a while ago; but I don't have a windows machine to test on. Could you see whether the trace is satisfactory for you now? --
[Issue 5993] Strange thread exceptions with DMD 2.053 beta 13th May
https://issues.dlang.org/show_bug.cgi?id=5993 --- Comment #4 from David Bryant --- (In reply to Infiltrator from comment #3) > Is this still an issue in 2.069? IIRC this was fixed and the user code that broke resumed working. I think this bug is a relic now. Apologies for not following it up. --
[Issue 6187] compiler could use move semantics for appending temporaries to an array
https://issues.dlang.org/show_bug.cgi?id=6187 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- Can I assume that this has been fixed? 2.069 outputs only the "dtor" and no postblit. --
[Issue 5993] Strange thread exceptions with DMD 2.053 beta 13th May
https://issues.dlang.org/show_bug.cgi?id=5993 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #3 from Infiltrator --- Is this still an issue in 2.069? Is there a test case? --
[Issue 5669] Constructor calls should be valid inside final switch
https://issues.dlang.org/show_bug.cgi?id=5669 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- The first example still fails to compile with messages about constructors behind labels. The second compiles with 2.069 though. --
[Issue 5546] Assigning and initializing structs from functions make more copies than necessary
https://issues.dlang.org/show_bug.cgi?id=5546 Infiltrator changed: What|Removed |Added Status|NEW |RESOLVED CC||lt.infiltra...@gmail.com Resolution|--- |WORKSFORME --- Comment #3 from Infiltrator --- 2.069 produces the desired output: Creating temp Creating copy Forwarding copy Returning global Copying global Deleting global Deleting copy Deleting temp --
[Issue 5376] writeln doesn't print immutable lazy sequences
https://issues.dlang.org/show_bug.cgi?id=5376 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #2 from Infiltrator --- 2.069 prints the types and contents of the sequences: [-1, -2, -3] const(MapResult!(unaryFun, const(int)[]))([1, 2, 3]) immutable(MapResult!(unaryFun, immutable(int)[]))([1, 2, 3]) Is this acceptable? --
[Issue 5351] Add template mixin for Range Primitives using random access
https://issues.dlang.org/show_bug.cgi?id=5351 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- Are you suggesting that this boilerplate mixin should be added to phobos? It seems too inflexible for general use. --
[Issue 15429] New: [std.stdio] Broken link in documentation
https://issues.dlang.org/show_bug.cgi?id=15429 Issue ID: 15429 Summary: [std.stdio] Broken link in documentation Product: D Version: D2 Hardware: All URL: http://dlang.org/phobos/ OS: All Status: NEW Severity: enhancement Priority: P3 Component: phobos Assignee: nob...@puremagic.com Reporter: r.97...@gmail.com In the documentation of std.stdio.File.this: Explanation of Parameter stdioOpenMode has a link to http://%20%20%20%20%20%20%20%20cplusplus.com/reference/clibrary/cstdio/fopen.html, so '%20's must be removed. --
[Issue 5137] Compiler tips
https://issues.dlang.org/show_bug.cgi?id=5137 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- I don't know whether it's necessary to add another class of compiler messages. It might be enough to just make these warnings. It would be helpful especially useful for @nogc. --
[Issue 4945] Bad error message with wrong struct literal
https://issues.dlang.org/show_bug.cgi?id=4945 Infiltrator changed: What|Removed |Added CC||lt.infiltra...@gmail.com --- Comment #1 from Infiltrator --- dmd 2.069 shows the error as Error: cannot implicitly convert expression ([1, 2]) of type int[] to int[1] Would you call this fixed? --
[Issue 4858] Cannot call synchronized method through super
https://issues.dlang.org/show_bug.cgi?id=4858 Infiltrator changed: What|Removed |Added Status|NEW |RESOLVED CC||lt.infiltra...@gmail.com Resolution|--- |WORKSFORME --- Comment #1 from Infiltrator --- Works in 2.069. --
[Issue 4668] Troubles with 'auto ref'
https://issues.dlang.org/show_bug.cgi?id=4668
Infiltrator changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||lt.infiltra...@gmail.com
Resolution|--- |WORKSFORME
--- Comment #1 from Infiltrator ---
I'm sure that you probably know this by now, but here goes.
int foo(T)(auto ref T[] arr) { // The auto is invalid as we already have ref
T[] to specify the type
arr.length += 1;
return 0;
}
void main() {
foo([1]); // This call will not work because [1] is not an lvalue
int[] a = [2];
foo(a);
auto f = &foo!int;
int[] b = [3];
f(b);
assert(b.length == 1); // This needs to be changed to == 2 to pass on
success
}
Modified working version:
int foo(T)(ref T[] arr) {
arr.length += 1;
return 0;
}
void main() {
int[] a = [2];
foo(a);
auto f = &foo!int;
int[] b = [3];
f(b);
assert(b.length == 2); // Changed to == 2 to pass on success
}
--
[Issue 6133] Improvements to RedBlackTree
https://issues.dlang.org/show_bug.cgi?id=6133 Infiltrator changed: What|Removed |Added Assignee|lt.infiltra...@gmail.com|nob...@puremagic.com --
[Issue 15428] __traits(compiles, super()) cause error "multiple constructor calls" later
https://issues.dlang.org/show_bug.cgi?id=15428 --- Comment #1 from Ketmar Dark --- p.s. or, maybe, it should only check that flag, but never change. --
[Issue 15428] __traits(compiles, super()) cause error "multiple constructor calls" later
https://issues.dlang.org/show_bug.cgi?id=15428 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 15428] New: __traits(compiles, super()) cause error "multiple constructor calls" later
https://issues.dlang.org/show_bug.cgi?id=15428
Issue ID: 15428
Summary: __traits(compiles, super()) cause error "multiple
constructor calls" later
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ket...@ketmar.no-ip.org
compiling the following code produces "multiple constructor calls" error:
class A {
this () {}
}
class B : A {
this () {
static if (__traits(compiles, super())) super();
}
}
`compiles` trait should not either set or check `parent constructor called`
flag.
--
[Issue 15401] partialSort should accept two ranges
https://issues.dlang.org/show_bug.cgi?id=15401 --- Comment #3 from Infiltrator --- (In reply to Andrei Alexandrescu from comment #2) > (In reply to Infiltrator from comment #1) > > Once issue 15421 is fixed, this is a simple matter of > > topN(l, r); > > sort(l); > > > > Which brings us to the question of: should partialSort(Range, index) be > > changed to call partialSort(r[0..n], r[n..$]) to reduce duplication or is > > there a large performance difference in the two topNs? > > Affirmative. Sorry, do you mean affirmative to how to implement partialSort(Range, Range); or affirmative to changing partialSort(Range, index) to call the (Range, Range) version; or affirmative to there being too large of a performance difference between the two versions of topN? --
[Issue 15427] dynamic casting functions should be available in TypeInfo_Class
https://issues.dlang.org/show_bug.cgi?id=15427
--- Comment #2 from Ketmar Dark ---
sample patch:
diff --git a/src/object.d b/src/object.d
index 097fc5a..6eb9163 100644
--- a/src/object.d
+++ b/src/object.d
@@ -21,6 +21,8 @@ private
{
extern (C) Object _d_newclass(const TypeInfo_Class ci);
extern (C) void rt_finalize(void *data, bool det=true);
+extern (C) void* _d_dynamic_cast(Object o, ClassInfo c);
+extern (C) int _d_isbaseof(ClassInfo oc, ClassInfo c);
}
// NOTE: For some reason, this declaration method doesn't work
@@ -860,6 +862,17 @@ unittest
*/
class TypeInfo_Class : TypeInfo
{
+final void* dynamicCast (Object o)
+{
+return (o !is null ? _d_dynamic_cast(o, this) : null);
+}
+
+// is this typeinfo base of `o`?
+final bool baseOf (Object o)
+{
+return (o !is null ? (_d_isbaseof(typeid(o), this) != 0) : false);
+}
+
override string toString() const { return info.name; }
override bool opEquals(Object o)
--
