[Issue 10566] Implement Unicode Collation Algorithm (UCA)
https://issues.dlang.org/show_bug.cgi?id=10566 Philippe Cadieux-Pelletier philly.di...@gmail.com changed: What|Removed |Added CC||philly.di...@gmail.com --- Comment #1 from Philippe Cadieux-Pelletier philly.di...@gmail.com --- Although Unicode support is definitely needed, implementing this in D is quite ambitious. Perhaps we could instead simply make a wrapper around either OS API or C++ std locale. Shouldn't be that hard to port code from boost::locale and at least D users would have something until TR10 is implemented natively in D (if ever considering the complexity!). --
[Issue 12965] DMD sets ELFOSABI to ELFOSABI_LINUX on all systems
https://issues.dlang.org/show_bug.cgi?id=12965 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/d8e5f55c9b94e831b6d178a20e34144933c3fc32 Fix issue 12965 - DMD sets ELFOSABI to ELFOSABI_LINUX on all systems https://github.com/D-Programming-Language/dmd/commit/b4b9908d74ed74b06177849a1fdba61bf7df411b Merge pull request #3687 from jasonbking/osabi Fix issue 12965 - DMD sets ELFOSABI to ELFOSABI_LINUX on all systems --
[Issue 12973] Local import std.math for exponentiation gives undefined identifier std
https://issues.dlang.org/show_bug.cgi?id=12973 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc --- What compiler version and OS are you using? With the latest dmd alpha it doesn't show me this error since lot of time. --
[Issue 12974] Integer constant exponentiation gives wrong value
https://issues.dlang.org/show_bug.cgi?id=12974 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc --- This seems to pass on my 32 bit system: assert((3uL)^^40uL == 12157665459056928801uL); // error --
[Issue 12974] Integer constant exponentiation gives wrong value
https://issues.dlang.org/show_bug.cgi?id=12974 --- Comment #2 from bearophile_h...@eml.cc --- ulong(uint.max) ^^ 40UL is something like: 208158641954659548848625708480171133381207412524816152551724014122904182251 307912571997657650065254566688428866939275444029732004368372970852338827367 264791762120127429330987166710374655101628820795072338450535380344923607954 436493529260566657177085349603902288285849258947350283095860468263104249444 251291644696840982120081667552033239985460311393336090041066199773922562599 18212890625 --
[Issue 12974] Integer constant exponentiation gives wrong value
https://issues.dlang.org/show_bug.cgi?id=12974 --- Comment #3 from bearophile_h...@eml.cc --- So I don't see the bug. --
[Issue 12974] Integer constant exponentiation gives wrong value
https://issues.dlang.org/show_bug.cgi?id=12974
--- Comment #4 from safety0ff.bugz safety0ff.b...@gmail.com ---
(In reply to bearophile_hugs from comment #1)
This seems to pass on my 32 bit system:
assert((3uL)^^40uL == 12157665459056928801uL); // error
A quick check on dpaste suggests that it passes in 2.065 and fails in git.
I suspect it's just a const-folding change that enables that line to get
CT-evaluated in git versus 2.065 because the other expression fails in both.
(In reply to bearophile_hugs from comment #2)
ulong(uint.max) ^^ 40UL is something like:
208158641954659548848625708480171133381207412524816152551724014122904182251
307912571997657650065254566688428866939275444029732004368372970852338827367
264791762120127429330987166710374655101628820795072338450535380344923607954
436493529260566657177085349603902288285849258947350283095860468263104249444
251291644696840982120081667552033239985460311393336090041066199773922562599
18212890625
Typo, the exponent was supposed to be 2uL.
Corrected:
//CODE: http://dpaste.dzfl.pl/ef7cd3cfd32d
import std.math;
void main()
{
ulong uimax = uint.max;
assert(uimax^^2uL == 18446744065119617025uL); //passes
ulong three = 3uL;
assert(three^^40uL == 12157665459056928801uL); // passes
assert((cast(ulong)uint.max)^^2uL == 12157665459056928801uL); // error
assert((3uL)^^40uL == 12157665459056928801uL); // error
}
--
[Issue 7019] implicit constructors are inconsistently allowed
https://issues.dlang.org/show_bug.cgi?id=7019
--- Comment #16 from Denis Shelomovskij verylonglogin@gmail.com ---
(In reply to Kenji Hara from comment #15)
(In reply to Denis Shelomovskij from comment #14)
static assert(!__traits(compiles, { S2 s2 = { 5 }; })); // fails
static assert(!__traits(compiles, { S2 s2 = { s: 5 }; })); // fails
These are expected behavior.
The target type of the argument '5' can be determined to S, so implicit
constructor call is handled.
How does `S2 s2 = { 5 }` differ from `f(5)` or `S2 s2 = S2(5)`? IMO the only
clean rule is:
Implicit conversion exists iff target type is explicitly stated.
What is wrong with this rule? What rules and why are preferred?
--
[Issue 12974] Integer constant exponentiation gives wrong value
https://issues.dlang.org/show_bug.cgi?id=12974
--- Comment #5 from bearophile_h...@eml.cc ---
With the latest alpha compiler this works correctly on my Windows 32 bit:
void main() {
import std.math;
immutable ulong r2 = 12157665459056928801uL;
immutable ulong three = 3uL;
assert(three ^^ 40uL == r2); // OK
assert(3uL ^^ 40uL == r2); // OK
}
While this shows the problem:
void main() {
import std.math;
ulong X = uint.max;
assert(X ^^ 2uL == 18446744065119617025uL); // OK
assert(ulong(uint.max) ^^ 2uL == 12157665459056928801uL); // Fails
}
--
[Issue 12974] Integer constant exponentiation gives wrong value
https://issues.dlang.org/show_bug.cgi?id=12974
safety0ff.bugz safety0ff.b...@gmail.com changed:
What|Removed |Added
Hardware|All |x86_64
--- Comment #6 from safety0ff.bugz safety0ff.b...@gmail.com ---
(In reply to bearophile_hugs from comment #5)
While this shows the problem:
void main() {
import std.math;
ulong X = uint.max;
assert(X ^^ 2uL == 18446744065119617025uL); // OK
assert(ulong(uint.max) ^^ 2uL == 12157665459056928801uL); // Fails
}
Bah, I screwed up the constants, that second constant is the one for 3^40.
The bug is still there on 64bit once I fixed the constants.
http://dpaste.dzfl.pl/51133cbb1d74
Marking as 64 bit only.
--
[Issue 12980] New: Undefined behavior: Assignment of static string to dynamic string
https://issues.dlang.org/show_bug.cgi?id=12980
Issue ID: 12980
Summary: Undefined behavior: Assignment of static string to
dynamic string
Product: D
Version: D2
Hardware: x86_64
OS: Mac OS X
Status: NEW
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: yuriy.gluk...@gmail.com
import std.stdio;
char[10] getSomeString()
{
char[10] result;
int i = 0;
for (char a = '0'; a = '9'; ++a)
{
result[i++] = a;
}
return result;
}
class A
{
this()
{
m = getSomeString();
}
string m;
}
void main()
{
A a = new A();
writeln(STRING: , a.m); // At this point a.m points to somewhere in stack
and thus contains invalid value.
}
--
[Issue 12980] Undefined behavior: Assignment of static string to dynamic string
https://issues.dlang.org/show_bug.cgi?id=12980
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc ---
(In reply to Yuriy from comment #0)
char[10] getSomeString()
{
char[10] result;
int i = 0;
for (char a = '0'; a = '9'; ++a)
{
result[i++] = a;
}
return result;
}
D is not fully memory-safe. A starting point to avoid such troubles is to
require a [] at that return point:
}
return result[];
}
--
[Issue 12980] Undefined behavior: Assignment of static string to dynamic string
https://issues.dlang.org/show_bug.cgi?id=12980 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution|--- |INVALID --- Comment #2 from Jonathan M Davis jmdavisp...@gmx.com --- This code is perfectly legal. It just isn't safe. And if @safe were properly implemented with regards to slicing static arrays, and you marked your code here with @safe, then the compiler would generate an error when the static array was sliced. Unfortunately however, slicing static arrays is currently a hole in @safe: https://issues.dlang.org/show_bug.cgi?id=8838 But regardless, there's no bug in the language in your example, just in your code. It's not marked with @safe, so it's @system, so even if bug# 8838 were fixed, your code would still compile, because @system code is not checked for memory safety, and it's perfectly possible to do unsafe things with memory in @system code. --
[Issue 12980] Undefined behavior: Assignment of static string to dynamic string
https://issues.dlang.org/show_bug.cgi?id=12980 --- Comment #3 from Yuriy yuriy.gluk...@gmail.com --- Ah, ok. Initially the bug was found when using std.digest.toHexString instead of getSomeString in my example. So should we add a @safe to toHexString and then wait for 8838 fix? --
[Issue 12981] New: Can't refer to 'outer' from mixin template
https://issues.dlang.org/show_bug.cgi?id=12981
Issue ID: 12981
Summary: Can't refer to 'outer' from mixin template
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: pub...@dicebot.lv
This code works in D1 (and prints B as expected):
===
template AAA(T)
{
class A
{
alias typeof(this.outer) x;
}
}
class B
{
mixin AAA!(int);
pragma(msg, A.x);
}
void main() {}
===
With current git master:
a.d(3): Error: variable this forward referenced
a.d(11): Error: mixin a.B.AAA!int error instantiating
a.d(13):while evaluating pragma(msg, A.x)
I don't know at which point it stopped working in D2. It has been found during
porting of some of Sociomantic code.
--
[Issue 12981] Can't refer to 'outer' from mixin template
https://issues.dlang.org/show_bug.cgi?id=12981 Dicebot pub...@dicebot.lv changed: What|Removed |Added Keywords||industry --
[Issue 12980] Undefined behavior: Assignment of static string to dynamic string
https://issues.dlang.org/show_bug.cgi?id=12980 --- Comment #4 from bearophile_h...@eml.cc --- (In reply to Yuriy from comment #3) Ah, ok. Initially the bug was found when using std.digest.toHexString instead of getSomeString in my example. Yes toHexString returns an array by value. This is not common in D APIs. As more and more D code returns small arrays by value (to allow them to be @nogc and increase performance), this kind of problems and bugs will become sufficiently common that D programmers will be more aware of them and so they will avoid them... :-) --
[Issue 12982] New: internal error when using array expression as an argument
https://issues.dlang.org/show_bug.cgi?id=12982 Issue ID: 12982 Summary: internal error when using array expression as an argument Product: D Version: D2 Hardware: x86 OS: Linux Status: NEW Severity: minor Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: pet...@mech.uq.edu.au Created attachment 1364 -- https://issues.dlang.org/attachment.cgi?id=1364action=edit sample source file The DMD 2.065 compiler fails with internal error when I try to pass the result of an array expression as a function argument. There is no problem when I assign the result to an array and then pass a reference to that array. See the attached source file for the transcript. --
[Issue 12982] internal error when using array expression as an argument
https://issues.dlang.org/show_bug.cgi?id=12982 Peter Jacobs pet...@mech.uq.edu.au changed: What|Removed |Added CC||pet...@mech.uq.edu.au --
[Issue 12982] internal error when using array expression as an argument
https://issues.dlang.org/show_bug.cgi?id=12982 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc --- D vector ops are designed to never allocate memory. An operation like 2.0*a[] doesn't mutate the array 'a', so there's nowhere for the result to go. So this is not a bug, and I think this issue should be closed as invalid. --
[Issue 12982] internal error when using array expression as an argument
https://issues.dlang.org/show_bug.cgi?id=12982
--- Comment #2 from bearophile_h...@eml.cc ---
This code:
double[] f1(double[] x) {
double[] result = x.dup;
result[] = x[] * 3.0;
return result;
}
void main() {
import std.stdio;
double[] a = [1.0, 2.0];
writeln(a= , a);
double[] b = f1(2.0 * a[]);
writeln(b= , b);
}
I am not seeing a internal compiler error:
test.d(11): Error: array operation a[] * 2.0 without assignment not
implemented
But I agree the error message should be improved. So if you want we can turn
this issue in a diagnostic enhancement request.
--
[Issue 12958] core.checkedint.mulu is broken
https://issues.dlang.org/show_bug.cgi?id=12958 --- Comment #3 from David Nadlinger c...@klickverbot.at --- (In reply to David Bregman from comment #2) To do the full thing, I'm pretty sure we essentially need to use addu() (inlined of course) to sum the partials. I agree. So here's my proposed solution (below): The overflow checks are written in such a way that DMD is able to generate branchless code (I checked the assembler). At first glance, this looks good, but chances are I've missed to check some other edge cases. To this end, it would be awesome if somebody could write a quick test harness that verifies random multiplication results using BigInt arithmetic. Let me also note that performance does not really matter here, as any such explicit implementation will be much slower than simply using the appropriate hardware instructions (mul/seto or mul/jno/mov). LDC will map the functions onto the respective LLVM intrinsics, and I suppose DMD will do something similar. --
[Issue 12982] internal error when using array expression as an argument
https://issues.dlang.org/show_bug.cgi?id=12982 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com --- (In reply to bearophile_hugs from comment #2) I am not seeing a internal compiler error: test.d(11): Error: array operation a[] * 2.0 without assignment not implemented This is a dup of issue 12179, and the ICE is fixed in git-head. *** This issue has been marked as a duplicate of issue 12179 *** --
[Issue 12179] [ICE](e2ir.c 1861) with array operation
https://issues.dlang.org/show_bug.cgi?id=12179 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||pet...@mech.uq.edu.au --- Comment #6 from Kenji Hara k.hara...@gmail.com --- *** Issue 12982 has been marked as a duplicate of this issue. *** --
[Issue 12982] internal error when using array expression as an argument
https://issues.dlang.org/show_bug.cgi?id=12982 --- Comment #4 from bearophile_h...@eml.cc --- (In reply to Kenji Hara from comment #3) This is a dup of issue 12179, and the ICE is fixed in git-head. *** This issue has been marked as a duplicate of issue 12179 *** An error message like assignment not implemented is worth a little diagnostic enhancement request. --
[Issue 12983] New: overload not recognized depending on order of declaration
https://issues.dlang.org/show_bug.cgi?id=12983
Issue ID: 12983
Summary: overload not recognized depending on order of
declaration
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: nilsboss...@googlemail.com
---
cat test.d code
alias I = int;
class B(T) {alias MyC = C!string;}
class C(T) : B!float
{
void m() {f(0);}
}
alias MyB = B!float;
void f();
void f(I);
code
dmd -c -o- test.d
---
test.d(5): Error: None of the overloads of 'f' are callable using argument
types (int), candidates are:
test.d(8):test.f()
test.d(9):test.f(I)
test.d(2): Error: template instance test.C!string error instantiating
test.d(7):instantiated from here: B!float
---
Works when f(I) is declared before f() or before MyB.
--
[Issue 12984] New: Cannot interpret [template] at compile time depending on order of declaration
https://issues.dlang.org/show_bug.cgi?id=12984
Issue ID: 12984
Summary: Cannot interpret [template] at compile time
depending on order of declaration
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: nilsboss...@googlemail.com
---
cat test.d code
template Tpl() {static if(true) enum Tpl = true;}
void f()() if(Tpl!());
class B {alias MyD = D!int;} // 4
class C : B {} // 5
class D(T) {alias MyE = E!float;}
class E(T) : D!int
{
void m()
{
auto c = new C; // 12
f(); // 13
}
}
code
dmd -c -o- test.d
---
test.d(2): Error: Cannot interpret Tpl!() at compile time
test.d(7): Error: template instance test.E!float error instantiating
test.d(4):instantiated from here: D!int
---
Works when lines 4 and 5 are swapped.
Works when lines 12 and 13 are swapped.
Possibly related to issue 12983.
--
[Issue 12983] overload not recognized depending on order of declaration
https://issues.dlang.org/show_bug.cgi?id=12983 --- Comment #1 from Nils nilsboss...@googlemail.com --- Possibly related to issue 12984. --
[Issue 12885] const union wrongly converts implicitly to mutable
https://issues.dlang.org/show_bug.cgi?id=12885 Nils nilsboss...@googlemail.com changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|nilsboss...@googlemail.com |nob...@puremagic.com --- Comment #1 from Nils nilsboss...@googlemail.com --- As issue 12883 has been closed as invalid, I don't have a plan how to go about this. Unassigning from me. --
[Issue 11575] [dox] std.algorithm.remove navigation link points to wrong place
https://issues.dlang.org/show_bug.cgi?id=11575 --- Comment #1 from hst...@quickfur.ath.cx --- Moreover, overloads on the same identifier will cause the same problem. --
[Issue 11575] [dox] std.algorithm.remove navigation link points to wrong place
https://issues.dlang.org/show_bug.cgi?id=11575 Brad Anderson e...@gnuk.net changed: What|Removed |Added Status|NEW |RESOLVED CC||e...@gnuk.net Resolution|--- |DUPLICATE --- Comment #2 from Brad Anderson e...@gnuk.net --- *** This issue has been marked as a duplicate of issue 6017 *** --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 Brad Anderson e...@gnuk.net changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #14 from Brad Anderson e...@gnuk.net --- *** Issue 11575 has been marked as a duplicate of this issue. *** --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #15 from hst...@quickfur.ath.cx --- Has the dlang.org docs been updated to document $DDOC_ANCHOR? --
[Issue 11847] Importing package.d module causes qualified name lookup to fail for sub modules
https://issues.dlang.org/show_bug.cgi?id=11847 sigod sigod.m...@gmail.com changed: What|Removed |Added CC||sigod.m...@gmail.com --
[Issue 5005] Remove restrictions on module/package with same name.
https://issues.dlang.org/show_bug.cgi?id=5005 sigod sigod.m...@gmail.com changed: What|Removed |Added CC||sigod.m...@gmail.com --- Comment #6 from sigod sigod.m...@gmail.com --- This feature was added not so long ago: http://dlang.org/module Issue must be closed as invalid/solved. --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #16 from hst...@quickfur.ath.cx --- Pull 1174 does *not* fix the problem, unfortunately. :-( Struct members still show up as global names rather than qualified with the containing struct name. --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #17 from hst...@quickfur.ath.cx --- Correction: pull 1174 fixes the problem for non-template members, but members of template structs, etc., still show up as top-level symbols. --
[Issue 12958] core.checkedint.mulu is broken
https://issues.dlang.org/show_bug.cgi?id=12958
--- Comment #4 from David Bregman uber.da...@gmail.com ---
If performance is not a concern, then it's much easier - just use a slow
division to check:
ulong mulu(ulong x, ulong y, ref bool overflow)
{
immutable xy = x*y;
if(x xy/x != y) {
overflow = true;
}
return xy;
}
--
[Issue 12985] New: Better error message for not supported array operation
https://issues.dlang.org/show_bug.cgi?id=12985
Issue ID: 12985
Summary: Better error message for not supported array operation
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
void foo(int[] b) {}
void main() {
int[2] a = [1, 2];
foo(a[] * 2);
}
dmd 2.066alpha gives:
test.d(4,9): Error: array operation a[] * 2 without assignment not implemented
I suggest a better error message like:
test.d(4,9): Error: array operations that allocate memory are not supported for
performance reasons
See also issue 10307
--
[Issue 12986] New: keywords allowed in module names if no ModuleDeclaration is used
https://issues.dlang.org/show_bug.cgi?id=12986 Issue ID: 12986 Summary: keywords allowed in module names if no ModuleDeclaration is used Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: sigod.m...@gmail.com Related to: https://issues.dlang.org/show_bug.cgi?id=456 I opened new issue because old one was about D1. I suggest that: 1. Or keywords must be disallowed for module names completely. 2. Or documentation must be modified to explain hidden feature. Actually currently it speaks only about package names. In issue 456 was said that this change will break some of phobos' modules. Now as I see it will only break `unittest.d`. --
[Issue 12982] internal error when using array expression as an argument
https://issues.dlang.org/show_bug.cgi?id=12982 --- Comment #5 from Peter Jacobs pet...@mech.uq.edu.au --- (In reply to bearophile_hugs from comment #4) (In reply to Kenji Hara from comment #3) This is a dup of issue 12179, and the ICE is fixed in git-head. *** This issue has been marked as a duplicate of issue 12179 *** An error message like assignment not implemented is worth a little diagnostic enhancement request. The error message in comment 2 is clear enough. Thank you. --
[Issue 12987] New: topN should return the top portion of the range
https://issues.dlang.org/show_bug.cgi?id=12987 Issue ID: 12987 Summary: topN should return the top portion of the range Product: D Version: D2 Hardware: x86 OS: Mac OS X Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: and...@erdani.com This oversight makes topN really awkward to use with pipes and filters. See e.g. http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/D 25:23 where I use sort and take instead of topN. --
[Issue 12987] topN should return the top portion of the range
https://issues.dlang.org/show_bug.cgi?id=12987 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Hardware|x86 |All Assignee|nob...@puremagic.com|xi...@live.com OS|Mac OS X|All --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #18 from hst...@quickfur.ath.cx --- I've found the reason: emitAnchorName() is unable to find the parent symbol of a template member because the .parent pointer is only set when semantic is run, but at the time of ddoc generation, the template may not even be instantiated yet, so all the .parent pointers of the member DSymbol's are NULL. --
[Issue 12968] DMD inline asm outputs wrong XCHG instruction
https://issues.dlang.org/show_bug.cgi?id=12968 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12968] DMD inline asm outputs wrong XCHG instruction
https://issues.dlang.org/show_bug.cgi?id=12968 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/6f013e558501c7b736656bec12ee241bd6f65684 Fix issue 12968 - Incorrect codgen for xchg with R8 https://github.com/D-Programming-Language/dmd/commit/9ddfff545a12d9c3b4df4829e3d4f8c90679cc02 Merge pull request #3690 from Orvid/issue12968 Fix issue 12968 - incorrect codegen --
[Issue 10366] Ddoc: Symbols in template classes don't get fully qualified anchors
https://issues.dlang.org/show_bug.cgi?id=10366 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #1 from hst...@quickfur.ath.cx --- https://github.com/D-Programming-Language/dmd/pull/3693 --
[Issue 7804] Cannot alias __traits directly
https://issues.dlang.org/show_bug.cgi?id=7804 sigod sigod.m...@gmail.com changed: What|Removed |Added CC||sigod.m...@gmail.com --
[Issue 6017] std.algorithm.remove has a wrong link
https://issues.dlang.org/show_bug.cgi?id=6017 --- Comment #19 from hst...@quickfur.ath.cx --- Found the fix: https://github.com/D-Programming-Language/dmd/pull/3693 Unfortunately, it seems to be unrelated to the specific issue in this bug; see instead: issue #10366. --
[Issue 10366] Ddoc: Symbols in template classes don't get fully qualified anchors
https://issues.dlang.org/show_bug.cgi?id=10366 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e351b82230e2519332f7f48f773913fcc929acef Ddoc should output qualified anchors for template members. Fixes [issue 10366] (https://issues.dlang.org/show_bug.cgi?id=10366). https://github.com/D-Programming-Language/dmd/commit/973fda41734b6009c98ab8d7cb3fa816575da558 Add tests for issue 10366. --
[Issue 12970] Enclosing @system attribute is precedence than postfix @safe
https://issues.dlang.org/show_bug.cgi?id=12970 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12970] Enclosing @system attribute is precedence than postfix @safe
https://issues.dlang.org/show_bug.cgi?id=12970 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8ffe47a05165227751bd08d981c860c52be33ec4 fix Issue 12970 - Enclosing @system attribute is precedence than postfix @safe https://github.com/D-Programming-Language/dmd/commit/8f0d587b3e01789860294cac5c41d5c5889b4e6b Merge pull request #3688 from 9rnsr/fix12970 Issue 12970 - Enclosing @system attribute is precedence than postfix @safe --
[Issue 11616] Introduce virtual keyword and remove virtual-by-default
https://issues.dlang.org/show_bug.cgi?id=11616 Issue 11616 depends on issue 12801, which changed state. Issue 12801 Summary: virtual keyword added to compiler without being added to language specification https://issues.dlang.org/show_bug.cgi?id=12801 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --
[Issue 12801] virtual keyword added to compiler without being added to language specification
https://issues.dlang.org/show_bug.cgi?id=12801 Kapps opantm2+db...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||opantm2+db...@gmail.com Resolution|--- |WONTFIX --- Comment #2 from Kapps opantm2+db...@gmail.com --- The virtual keyword has been removed. --
[Issue 10233] [Tracker] Grammar issues
https://issues.dlang.org/show_bug.cgi?id=10233 Issue 10233 depends on issue 12801, which changed state. Issue 12801 Summary: virtual keyword added to compiler without being added to language specification https://issues.dlang.org/show_bug.cgi?id=12801 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --
[Issue 10705] recursive alias declaration
https://issues.dlang.org/show_bug.cgi?id=10705 Jesse Phillips jesse.k.phillip...@gmail.com changed: What|Removed |Added CC||jesse.k.phillip...@gmail.co ||m --- Comment #1 from Jesse Phillips jesse.k.phillip...@gmail.com --- Before the compiler can define what ShortRect is it must first create a Rect!short, to create a Rect!short it needs to know what a ShortRect is. This might be more of an enhancement than bug. --
[Issue 12540] Algebraic recursive alias declaration when a class contains an Algebraic member that can accept itself
https://issues.dlang.org/show_bug.cgi?id=12540 Jesse Phillips jesse.k.phillip...@gmail.com changed: What|Removed |Added CC||jesse.k.phillip...@gmail.co ||m --- Comment #1 from Jesse Phillips jesse.k.phillip...@gmail.com --- I think this is a duplicate of issue 10705. --
[Issue 10366] Ddoc: Symbols in template classes don't get fully qualified anchors
https://issues.dlang.org/show_bug.cgi?id=10366
--- Comment #3 from hst...@quickfur.ath.cx ---
Apparently, there is still one case that doesn't work, when there's a template
function inside a templated struct or class:
--
struct S(T) {
void func(U)(U u) { }
}
--
--
[Issue 10366] Ddoc: Symbols in template classes don't get fully qualified anchors
https://issues.dlang.org/show_bug.cgi?id=10366
--- Comment #4 from hst...@quickfur.ath.cx ---
Oops, forgot the ddoc comments:
-
///
struct S(T) {
///
void func(U)(U u) { }
}
-
--
