[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #9 from Walter Bright bugzi...@digitalmars.com --- (In reply to Jacob Carlborg from comment #8) If I understand you correctly the current ModuleInfo would be renamed to _ModuleInfo and a new immutable alias would be added, named ModuleInfo? Yes. The ModuleInfo I have declared would be immutable? Yes. That could work. I will work for the function where I found the problem but it returns the module info and I have not looked yet how the returned value is used. --
[Issue 13101] Cherry-picks for v2.066.0-rc1
https://issues.dlang.org/show_bug.cgi?id=13101 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #1 from safety0ff.bugz safety0ff.b...@gmail.com --- https://github.com/D-Programming-Language/druntime/commit/a4877f8a9e78546af10eb2bdcaa29e12ad271f27 --
[Issue 13036] Cherry-picks for v2.065.1-b1
https://issues.dlang.org/show_bug.cgi?id=13036 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #7 from safety0ff.bugz safety0ff.b...@gmail.com --- https://github.com/D-Programming-Language/druntime/commit/a4877f8a9e78546af10eb2bdcaa29e12ad271f27 --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #10 from Walter Bright bugzi...@digitalmars.com --- Did the alias thang: https://github.com/D-Programming-Language/druntime/pull/886 https://github.com/D-Programming-Language/dmd/pull/3754 --
[Issue 13117] New: Executable size of hello world explodes from 472K to 2.7M
https://issues.dlang.org/show_bug.cgi?id=13117
Issue ID: 13117
Summary: Executable size of hello world explodes from 472K to
2.7M
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: dbugrepor...@gmail.com
Compiled with dmd_2.066.0~b3-0_amd64 (or ~b2) hello world executable becomes
2.7 megabytes while with 2.065 it's 472 kilobytes.
import std.stdio;
void main() {
writeln(hello);
}
--
[Issue 13118] New: Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118
Issue ID: 13118
Summary: Allow non-`@nogc` stuff in `@nogc` function contracts
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code should compile:
---
void f() @nogc
in { new int; }
body { }
---
Note this is already the case for `nothrow` functions as one can throw
`Exception`s in contracts which allows e.g. use `assert(expr, format(...))`.
--
[Issue 13118] Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc ---
(In reply to Denis Shelomovskij from comment #0)
This code should compile:
---
void f() @nogc
in { new int; }
body { }
---
Note this is already the case for `nothrow` functions as one can throw
`Exception`s in contracts which allows e.g. use `assert(expr, format(...))`.
I think this is a bad idea. The point of @nogc is to be sure the GC will not be
called or used inside a piece of code. This ER invalidates that. For this ER to
be accepted I'll want a @reallynogc added to D that really forbids the use of
GC.
--
[Issue 13117] Executable size of hello world explodes from 472K to 2.7M
https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- Issue does not occur in Windows platform. -m32 With git head: 145,436 bytes With 2.065:138,268 bytes -m64 With git head: 259,584 bytes With 2.065:257,536 bytes --
[Issue 13102] Cannot parse 184467440737095516153.6L
https://issues.dlang.org/show_bug.cgi?id=13102 --- 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/dbb1b02b3b825d430b2891fdc0593ce51816cd1c fix Issue 13102 - Cannot parse 184467440737095516153.6L https://github.com/D-Programming-Language/dmd/commit/0e905729ac0902fc38c6bde137479b8833157389 Merge pull request #3753 from WalterBright/fix13102 [REG2.065] Issue 13102 - Cannot parse 184467440737095516153.6L --
[Issue 13119] New: `struct` constructor attributes inferred like field destructor is called on initialization
https://issues.dlang.org/show_bug.cgi?id=13119
Issue ID: 13119
Summary: `struct` constructor attributes inferred like field
destructor is called on initialization
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code should compile:
---
struct S
{
this(int) @safe pure nothrow @nogc { }
~this() { }
}
struct T
{
S s;
this(int) @safe pure nothrow @nogc
{
s = S(0); // line 13
}
}
---
main.d(13): Error: pure function 'main.T.this' cannot call impure function
'main.S.~this'
main.d(13): Error: safe function 'main.T.this' cannot call system function
'main.S.~this'
main.d(13): Error: @nogc function 'main.T.this' cannot call non-@nogc function
'main.S.~this'
---
Note there is no errors for `nothrow` attribute.
--
[Issue 13120] New: Body of `foreach` over string with transcoding ignores function attributes
https://issues.dlang.org/show_bug.cgi?id=13120
Issue ID: 13120
Summary: Body of `foreach` over string with transcoding ignores
function attributes
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: verylonglogin@gmail.com
This code should NOT compile:
---
void f() { }
void g(char[] s) pure @nogc
{
foreach(dchar dc; s)
f();
}
---
The behaviour above is correct for `@safe` attribute, but this attribute fails
in case of a template.
This code should NOT compile:
---
void f() { }
void g()(char[] s)
{
foreach(dchar dc; s)
f();
}
void h() @safe pure @nogc
{
g(null);
}
---
--
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #11 from Kenji Hara k.hara...@gmail.com --- (In reply to Walter Bright from comment #9) (In reply to Jacob Carlborg from comment #8) If I understand you correctly the current ModuleInfo would be renamed to _ModuleInfo and a new immutable alias would be added, named ModuleInfo? Yes. The ModuleInfo I have declared would be immutable? Yes. That could work. I will work for the function where I found the problem but it returns the module info and I have not looked yet how the returned value is used. I don't think it's good idea. It would introduce confusing than benefits. --
[Issue 13113] cannot build druntime's gc.d with -debug=INVARIANT, bad @nogc inference?
https://issues.dlang.org/show_bug.cgi?id=13113 safety0ff.bugz safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #2 from safety0ff.bugz safety0ff.b...@gmail.com --- Does reverting the invariant portion of [1] allow it to compile? [1] https://github.com/D-Programming-Language/druntime/commit/f5d3f42316cf38a6c267cf625e94ded45aea9f6b#diff-6f1ab0423fff9dcd084ecf9a677dc426L1456 --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #12 from Walter Bright bugzi...@digitalmars.com --- (In reply to Kenji Hara from comment #11) I don't think it's good idea. It would introduce confusing than benefits. Please explain. What confusion? --
[Issue 13117] Executable size of hello world explodes from 472K to 2.7M
https://issues.dlang.org/show_bug.cgi?id=13117 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- Not again! Dammit, this should be tested for in the autotester suite. --
[Issue 13113] cannot build druntime's gc.d with -debug=INVARIANT, bad @nogc inference?
https://issues.dlang.org/show_bug.cgi?id=13113
--- Comment #3 from Rainer Schuetze r.sagita...@gmx.de ---
Does reverting the invariant portion of [1] allow it to compile?
I haven't actually reverted the code, but commenting out the contents of
Gcx.invariant didn't help. Commenting out the destructor of Treap DOES help.
Here is a further reduction of the test case:
class Gcx
{
invariant() {}
Treap!int tr;
}
struct Treap(E)
{
~this() {} // no error if this line is removed
}
--
[Issue 13118] Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118
--- Comment #2 from Denis Shelomovskij verylonglogin@gmail.com ---
(In reply to bearophile_hugs from comment #1)
(In reply to Denis Shelomovskij from comment #0)
This code should compile:
---
void f() @nogc
in { new int; }
body { }
---
Note this is already the case for `nothrow` functions as one can throw
`Exception`s in contracts which allows e.g. use `assert(expr, format(...))`.
I think this is a bad idea. The point of @nogc is to be sure the GC will not
be called or used inside a piece of code. This ER invalidates that. For this
ER to be accepted I'll want a @reallynogc added to D that really forbids the
use of GC.
I don't see any difference here with `nothrow` which can be violated in
contracts allowing e.g. `format` calls.
--
[Issue 12448] in argument for std.string.toStringz
https://issues.dlang.org/show_bug.cgi?id=12448 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #10 from Jonathan M Davis jmdavisp...@gmx.com --- There is no guarantee that the result of toStringz does not escape the function, so using in for parameter to toStringz would be fundamentally wrong, since in implies scope. And since scope hasn't been fully implemented, the problem wouldn't even be caught. Rather, we risk ending up with such code breaking when scope actually gets fully implemented - which is why I'd argue that using in is almost always bad. We should just avoid using scope and in until they're properly implemented IMHO. --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #13 from Kenji Hara k.hara...@gmail.com --- (In reply to Walter Bright from comment #12) (In reply to Kenji Hara from comment #11) I don't think it's good idea. It would introduce confusing than benefits. Please explain. What confusion? All D programmers would assume that unqualified type name T is a mutable type, and const(T) is const, immutable(T) is immutable. But, the proposed idea will break the assumption - all ModuleInfo, const(ModuleInfo), immutable(ModuleInfo) will be same immutable. it's very confusing situation. --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #14 from Jacob Carlborg d...@me.com --- (In reply to Kenji Hara from comment #13) All D programmers would assume that unqualified type name T is a mutable type, and const(T) is const, immutable(T) is immutable. But, the proposed idea will break the assumption - all ModuleInfo, const(ModuleInfo), immutable(ModuleInfo) will be same immutable. it's very confusing situation. Hmm, that's a good point. --
[Issue 2803] template + default argument = doesn't work
https://issues.dlang.org/show_bug.cgi?id=2803
Denis Shelomovskij verylonglogin@gmail.com changed:
What|Removed |Added
CC||verylonglogin@gmail.com
Hardware|x86 |All
Version|unspecified |D2
--- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com ---
Simplified testcase:
---
void fun(T)(T = 0) { }
void main() { fun(); }
---
main.d(3): Error: template main.fun cannot deduce function from argument types
!()(), candidates are:
main.d(1):main.fun(T)(T = 0)
---
--
[Issue 9698] Template default parameters are not checked for validity
https://issues.dlang.org/show_bug.cgi?id=9698 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1 from Denis Shelomovskij verylonglogin@gmail.com --- *** Issue 9934 has been marked as a duplicate of this issue. *** --
[Issue 9934] template default argument should be semantically analysed
https://issues.dlang.org/show_bug.cgi?id=9934 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||verylonglogin@gmail.com Resolution|--- |DUPLICATE --- Comment #5 from Denis Shelomovskij verylonglogin@gmail.com --- *** This issue has been marked as a duplicate of issue 9698 *** --
[Issue 9698] Template default parameters are not checked for validity
https://issues.dlang.org/show_bug.cgi?id=9698 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #2 from Denis Shelomovskij verylonglogin@gmail.com --- Also one can see discussion of duplicate Issue 9934. --
[Issue 13121] New: std.algorithm.joiner should return a bidirectional range if possible
https://issues.dlang.org/show_bug.cgi?id=13121 Issue ID: 13121 Summary: std.algorithm.joiner should return a bidirectional range if possible Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: Phobos Assignee: nob...@puremagic.com Reporter: schue...@gmx.net http://forum.dlang.org/thread/lpkbhpkhqtdkbgksl...@forum.dlang.org?page=2#post-lpsib4:242c8t:241:40digitalmars.com --
[Issue 12448] in argument for std.string.toStringz
https://issues.dlang.org/show_bug.cgi?id=12448 --- Comment #11 from bearophile_h...@eml.cc --- (In reply to Jonathan M Davis from comment #10) we risk ending up with such code breaking when scope actually gets fully implemented Implementing scope/in will just disallow some current wrong usages, so it will just break code, it will not introduce actual (silent) bugs, that are the dangerous ones. --
[Issue 13114] old opCmp requirement for AA keys should be detected for classes
https://issues.dlang.org/show_bug.cgi?id=13114 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Hardware|x86 |All OS|Mac OS X|All --- Comment #2 from Kenji Hara k.hara...@gmail.com --- I think we cannot actually fix this issue. I don't know what to do here. CC'ing major players on this issue to make sure it gets noticed. Compiler cannot detect all invalid cases. We should give up that do things perfectly. https://github.com/D-Programming-Language/dmd/pull/3757 --
[Issue 13122] New: std.algorithm.cartesianProduct output type immutability
https://issues.dlang.org/show_bug.cgi?id=13122
Issue ID: 13122
Summary: std.algorithm.cartesianProduct output type
immutability
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
void main() {
import std.algorithm: cartesianProduct;
immutable a = ABC;
foreach (t1; cartesianProduct(a, a))
pragma(msg, typeof(t1));
immutable b = ABCd;
foreach (t2; cartesianProduct(b, b))
pragma(msg, typeof(t2));
}
The latest dmd 2.066beta3 outputs:
Tuple!(dchar, dchar)
Tuple!(immutable(dchar), immutable(dchar))
Expected output:
Tuple!(dchar, dchar)
Tuple!(dchar, dchar)
--
[Issue 12448] in argument for std.string.toStringz
https://issues.dlang.org/show_bug.cgi?id=12448 --- Comment #12 from Jonathan M Davis jmdavisp...@gmx.com --- (In reply to bearophile_hugs from comment #11) (In reply to Jonathan M Davis from comment #10) we risk ending up with such code breaking when scope actually gets fully implemented Implementing scope/in will just disallow some current wrong usages, so it will just break code, it will not introduce actual (silent) bugs, that are the dangerous ones. Just because code breakage isn't silent doesn't mean that it's good. It isn't even properly defined what scope is supposed to mean, so you can't even know for sure what correct usage is. In theory, it's only supposed to be used with parameters which don't escape a function, but since that's not well-defined, it's arguably impossible to know for sure whether you're using it correctly, and even if we knew for sure exactly what it meant, if you still end up using it in the wrong way, then your code will break when scope is properly implemented, whereas it wouldn't break if you just didn't use it. So, using scope or in before they're properly implemented really doesn't buy you anything, and it risks breaking code once they are implemented. Regardless, putting scope on toStringz is fundamentally wrong, because it's not guaranteed that the pointer being returned doesn't refer to the string being passed in. And even if we don't know exactly what constitutes escaping a function, I think that it's pretty clear that returning a pointer to the contents of the in parameter would mean that the parameter escaped the function. --
[Issue 13118] Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #3 from yebblies yebbl...@gmail.com ---
(In reply to Denis Shelomovskij from comment #0)
This code should compile:
---
void f() @nogc
in { new int; }
body { }
---
Note this is already the case for `nothrow` functions as one can throw
`Exception`s in contracts which allows e.g. use `assert(expr, format(...))`.
assert throws an error and does not violate nothrow.
--
[Issue 13118] Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118
--- Comment #4 from bearophile_h...@eml.cc ---
(In reply to yebblies from comment #3)
assert throws an error and does not violate nothrow.
This compiles, but is it good?
void foo() nothrow
in {
throw new Exception(null);
} body {
}
void main() {}
--
[Issue 13118] Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118
--- Comment #5 from yebblies yebbl...@gmail.com ---
(In reply to bearophile_hugs from comment #4)
This compiles, but is it good?
void foo() nothrow
in {
throw new Exception(null);
} body {
}
void main() {}
I think it's a bug. 'debug' blocks do skip checking, but seeing as pure, @safe
and @nogc are enforced it's probably just been overlooked.
--
[Issue 13118] Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118 Dicebot pub...@dicebot.lv changed: What|Removed |Added CC||pub...@dicebot.lv --- Comment #6 from Dicebot pub...@dicebot.lv --- I believe contracts should not be treated any specially for @nogc Instead throwing an errors (including AssertError) should be replaced with HLT same as it is done for assert(false) in release builds. It will keep basic sanity checks in place without sacrificing @nogc guarantees. --
[Issue 13123] New: Disallow throwing contracts for nothrow functions
https://issues.dlang.org/show_bug.cgi?id=13123
Issue ID: 13123
Summary: Disallow throwing contracts for nothrow functions
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
dmd 2.066beta3 compiles this code:
void foo() nothrow
in {
throw new Exception(null);
} body {
}
void main() {}
--
[Issue 13118] Allow non-`@nogc` stuff in `@nogc` function contracts
https://issues.dlang.org/show_bug.cgi?id=13118 --- Comment #7 from bearophile_h...@eml.cc --- (In reply to yebblies from comment #5) I think it's a bug. 'debug' blocks do skip checking, but seeing as pure, @safe and @nogc are enforced it's probably just been overlooked. Filed as Issue 13123 --
[Issue 13124] New: std.algorithm.until with not-boolean predicates too
https://issues.dlang.org/show_bug.cgi?id=13124
Issue ID: 13124
Summary: std.algorithm.until with not-boolean predicates too
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
This code:
void main() {
import std.stdio, std.algorithm;
auto s = abcacaacba;
s.filter!(c = c.among!('a', 'b')).writeln;
}
Outputs:
abaaaba
While this code:
void main() {
import std.stdio, std.algorithm;
auto s = hello how\nare you;
s.until!(c = c.among!('\n', '\r')).writeln;
}
Gives with dmd 2.066beta3:
...\dmd2\src\phobos\std\algorithm.d(5690,33): Error: cannot implicitly convert
expression (__lambda1(front(this._input))) of type uint to bool
test.d(4,7): Error: template instance test.main.until!((c) = c.among!('\x0a',
'\x0d'), string) error instantiating
So I suggest to improve std.algorithm.until, to allow that code.
Timon Gehr comments:
private bool predSatisfied() // -- don't say bool here
{
static if (is(Sentinel == void))
return unaryFun!pred(_input.front); // or cast here
else
return startsWith!pred(_input, _sentinel); // and here
}
--
[Issue 13101] Cherry-picks for v2.066.0-rc1
https://issues.dlang.org/show_bug.cgi?id=13101 David Nadlinger c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #2 from David Nadlinger c...@klickverbot.at --- This fixes a critical issue in a newly added API, and needs to be included before the release (or the affected functions removed): https://github.com/D-Programming-Language/druntime/pull/890 --
[Issue 13125] New: Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125
Issue ID: 13125
Summary: Cannot implicitly convert string* to __va_list_tag*
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: d...@me.com
This code compiled in DMD 2.065.0 but fails in DMD 2.066.0-b3:
import core.vararg;
void main ()
{
string a;
core.vararg.va_list b = a;
}
The error message is: Error: cannot implicitly convert expression ( a) of
type string* to __va_list_tag*.
This is from DWT [1] and [2].
[1]
https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L81
[2]
https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L385
--
[Issue 13125] Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125 Jacob Carlborg d...@me.com changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X|All --
[Issue 13126] New: Error: redundant storage class 'static'
https://issues.dlang.org/show_bug.cgi?id=13126 Issue ID: 13126 Summary: Error: redundant storage class 'static' Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: d...@me.com This code compiled in DMD 2.065.0 but not in DMD 2.066.0-b3: static static void foo (); The error message I get is: Error: redundant storage class 'static'. Wouldn't it be possible to give a deprecation message about this? --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #15 from Walter Bright bugzi...@digitalmars.com --- (In reply to Kenji Hara from comment #13) All D programmers would assume that unqualified type name T is a mutable type, There were some bumps in transitioning to the immutable alias 'string', but it all turned out for the best. The compiler complains if you do anything wrong, and this proposal fixes the breaking code issue. --
[Issue 13111] GC.realloc returns invalid memory for large reallocation
https://issues.dlang.org/show_bug.cgi?id=13111 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Version|unspecified |D2 Resolution|--- |FIXED --
[Issue 13113] cannot build druntime's gc.d with -debug=INVARIANT, bad @nogc inference?
https://issues.dlang.org/show_bug.cgi?id=13113 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com --- The trouble seems to be that destructors are getting their attributes inferred, while invariants are not. --
[Issue 13114] old opCmp requirement for AA keys should be detected for classes
https://issues.dlang.org/show_bug.cgi?id=13114 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13114] old opCmp requirement for AA keys should be detected for classes
https://issues.dlang.org/show_bug.cgi?id=13114 --- 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/411fbfea24e5a3c8f8833ee62a6bc5409c7cac41 fix Issue 13114 - old opCmp requirement for AA keys should be detected for classes https://github.com/D-Programming-Language/dmd/commit/1efe1ad230aae55b341a81c2418596c2e636d0d4 Merge pull request #3757 from 9rnsr/fix13114 Issue 13114 - old opCmp requirement for AA keys should be detected for classes --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #16 from Jacob Carlborg d...@me.com --- Find another project with the same error. --
[Issue 13125] Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- The trouble is that va_list was a void* in 2.065, but is now a magic type that is handled specially by the back end. Doing what you're doing in this code is really not supportable. I'm not sure what dwt is doing there, so don't have an immediate suggested fix. --
[Issue 13125] Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125 --- Comment #2 from Jacob Carlborg d...@me.com --- (In reply to Walter Bright from comment #1) Doing what you're doing in this code is really not supportable. Yeah, the code looks suspicious. I'm not sure what dwt is doing there, so don't have an immediate suggested fix. I think the intention is to forward the varargs of trace [1] to doVarArgFormat [2], but first prepend the fmt argument to the varargs. [1] https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L79 [2] https://github.com/d-widget-toolkit/base/blob/master/src/java/lang/util.d#L385 --
[Issue 13127] New: Cannot deduce function with int[][] argument and in parameter
https://issues.dlang.org/show_bug.cgi?id=13127
Issue ID: 13127
Summary: Cannot deduce function with int[][] argument and in
parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: d...@me.com
This code works in DMD 2.065.0 but not in 2.066.0-b3:
void foo (T)(in T[] src, T[] dest);
void main ()
{
int[][] a;
foo(a, a);
}
The error message is:
main.d(14): Error: template main.foo cannot deduce function from argument types
!()(int[][], int[][]), candidates are:
main.d(9):main.foo(T)(in T[] src, T[] dest)
If I remove in or if a is of type int[] it compiles.
--
[Issue 13125] Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125 --- Comment #3 from Walter Bright bugzi...@digitalmars.com --- I also seriously doubt that DWT code actually worked on 2.065 on Posix 64 bits, even though it compiled. --
[Issue 13125] Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125 --- Comment #4 from Jacob Carlborg d...@me.com --- (In reply to Walter Bright from comment #3) I also seriously doubt that DWT code actually worked on 2.065 on Posix 64 bits, even though it compiled. It doesn't support 64bit yet. --
[Issue 13126] Error: redundant storage class 'static'
https://issues.dlang.org/show_bug.cgi?id=13126 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/3759 --
[Issue 13126] Error: redundant storage class 'static'
https://issues.dlang.org/show_bug.cgi?id=13126 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Kenji Hara k.hara...@gmail.com --- (In reply to Jacob Carlborg from comment #0) Wouldn't it be possible to give a deprecation message about this? No, it was _just_ an accepts-invalid bug and it will be properly fixed in 2.066. feature deprecation cycle should be enabled if the original code have valid meaning in old D semantics and then the semantics will be changed to another valid one. --
[Issue 13126] Error: redundant storage class 'static'
https://issues.dlang.org/show_bug.cgi?id=13126 --- Comment #3 from Walter Bright bugzi...@digitalmars.com --- I agree that it was invalid code that should never have been accepted, but it was harmless enough and I was thinking along the lines of easing the transition. Jacob, is this really a problem to fix? Is static static pervasive in your code, or just one spot? --
[Issue 13126] Error: redundant storage class 'static'
https://issues.dlang.org/show_bug.cgi?id=13126 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from bearophile_h...@eml.cc --- (In reply to Walter Bright from comment #3) and I was thinking along the lines of easing the transition. Easing the transitions is acceptable (perhaps a bit faster in this case). What's important is to actually remove bugs/sloppiness from D. --
[Issue 13126] Error: redundant storage class 'static'
https://issues.dlang.org/show_bug.cgi?id=13126 --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- (In reply to bearophile_hugs from comment #4) What's important is to actually remove bugs/sloppiness from D. I don't think anyone suggested otherwise. --
[Issue 13126] Error: redundant storage class 'static'
https://issues.dlang.org/show_bug.cgi?id=13126 --- Comment #6 from Jacob Carlborg d...@me.com --- (In reply to Walter Bright from comment #3) I agree that it was invalid code that should never have been accepted, but it was harmless enough and I was thinking along the lines of easing the transition. Yes, easing the transition would be nice. Jacob, is this really a problem to fix? Is static static pervasive in your code, or just one spot? No, it's not a problem to fix. It's just one spot, so far. I'm getting new regressions after fixing this. Calming that D is stable and ready for production but not be able to easy transitions like this doesn't go hand in hand in my opinion. Especially since the extra static was probably a noop to being with. There have been regressions in DWT for every release since, probably, 2.050. --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #17 from Walter Bright bugzi...@digitalmars.com --- (In reply to Jacob Carlborg from comment #16) Find another project with the same error. ?? --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 --- Comment #18 from Jacob Carlborg d...@me.com --- (In reply to Walter Bright from comment #17) (In reply to Jacob Carlborg from comment #16) Find another project with the same error. ?? I'm just indicating that there are more than one project that is affected by this. --
[Issue 13125] Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Hardware|All |x86_64 --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- (In reply to Jacob Carlborg from comment #4) (In reply to Walter Bright from comment #3) I also seriously doubt that DWT code actually worked on 2.065 on Posix 64 bits, even though it compiled. It doesn't support 64bit yet. This current problem should only appear on 64 bits, and only on posix systems. How did you run into it? --
[Issue 13025] Tools repository does not build on Ubuntu
https://issues.dlang.org/show_bug.cgi?id=13025 --- Comment #13 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/94c35b9116fe43157738988ffba5aa2d88e0ec2a fix Issue 13025 - Tools repository does not build on Ubuntu - reference __bss_start and _end using weak symbols to workaround a diagnostic linker bug https://github.com/D-Programming-Language/druntime/commit/7474e953a913125a43daad8d2c11464e795d6b6c Merge pull request #889 from MartinNowak/fix13025 fix Issue 13025 - Tools repository does not build on Ubuntu --
[Issue 13025] Tools repository does not build on Ubuntu
https://issues.dlang.org/show_bug.cgi?id=13025 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13116] Should not be able to return ref to 'this'
https://issues.dlang.org/show_bug.cgi?id=13116 hst...@quickfur.ath.cx changed: What|Removed |Added Version|unspecified |D2 --
[Issue 13084] ModuleInfo.opApply delegate expects immutable parameter
https://issues.dlang.org/show_bug.cgi?id=13084 David Nadlinger c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #19 from David Nadlinger c...@klickverbot.at --- (In reply to Jacob Carlborg from comment #18) I'm just indicating that there are more than one project that is affected by this. Affected by what? If you know one, why not name it? --
[Issue 13125] Cannot implicitly convert string* to __va_list_tag*
https://issues.dlang.org/show_bug.cgi?id=13125 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Walter Bright bugzi...@digitalmars.com --- I'm going to resolve this as invalid because: 1. I'm pretty sure it never did work, even if it compiled. va_list doesn't work that way. At least now the compiler flags that this construct won't work. 2. va_list is magic on Posix 64, and this is allowed by the C Standard. We can't make the compiler make this work and be compliant with C varargs. 3. What DWT is doing is not the right way to do things with va_list. 4. DWT will need work to port it to 64 bits, as it never has yet run on 64. --
[Issue 13117] Executable size of hello world explodes from 472K to 2.7M
https://issues.dlang.org/show_bug.cgi?id=13117 --- Comment #3 from Walter Bright bugzi...@digitalmars.com --- I just tried this, and am seeing 394,000 size executables. I cannot reproduce your results. --
[Issue 13110] Allow -run as last argument
https://issues.dlang.org/show_bug.cgi?id=13110 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com Hardware|x86 |All OS|Mac OS X|All --
[Issue 13128] New: std.container.array.Array.stableLinearRemove is erroneously an alias to std.algorithm.remove (and linearRemove is not stable)
https://issues.dlang.org/show_bug.cgi?id=13128
Issue ID: 13128
Summary: std.container.array.Array.stableLinearRemove is
erroneously an alias to std.algorithm.remove (and
linearRemove is not stable)
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: jakobov...@gmail.com
Array provides linear removal, but the `stableLinearRemove` alias for the
non-boolean specialization points to std.algorithm.remove, not its own
`linearRemove` member as it should.
However, it turns out that while Array tries to make removal stable, a bug
prevents it from actually being stable at the moment:
---
import std.container : Array;
import std.stdio : writeln;
void main()
{
auto arr = Array!int(1, 2);
auto r = arr[];
arr.linearRemove(arr[0 .. 1]);
writeln(r); // Range violation
}
---
--
[Issue 13113] cannot build druntime's gc.d with -debug=INVARIANT, bad @nogc inference?
https://issues.dlang.org/show_bug.cgi?id=13113 --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- https://github.com/D-Programming-Language/dmd/pull/3760 --
