[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com --- However it might also be related to: https://issues.dlang.org/show_bug.cgi?id=12657 --
[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- Confirmed. --
[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661 Dmitry Olshansky dmitry.o...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #3 from Dmitry Olshansky dmitry.o...@gmail.com --- I suspect it's new bloody @nogc + auto-inference. So a symbol in phobos is detected as @nogc w/o debug and consequently mangles with 'Ni'. Later in user program it's not-@nogc in debug and mangles differently. Now it should just generate a new instantiation not present in compiled library but somehow it doesn't happen. --
[Issue 3827] Warn against and then deprecate implicit concatenation of adjacent string literals
https://issues.dlang.org/show_bug.cgi?id=3827
--- Comment #32 from bearophile_h...@eml.cc ---
A new bug of mine caused by the implicit concatenation of strings. The point of
this little program is to show the Phobos isNumeric function:
void main() {
import std.stdio, std.string, std.array;
foreach (const s; [12, 12\t, hello12, -12, 02
0-12, +12, 1.5, 1,000, 1_000,
0x10, 0b1010___00110011,
-0b10101, 0x10.5])
writefln(`isNumeric(%s): %s`, s, s.strip().isNumeric(true));
}
As you see the last example 02 of the first row of the array literal lacks a
comma.
I have found this bug with the DScanner tool.
--
[Issue 12644] Some std.math functions are not yet @nogc
https://issues.dlang.org/show_bug.cgi?id=12644
--- Comment #1 from bearophile_h...@eml.cc ---
Also:
void main() @nogc {
import std.math: log, acos;
auto x1 = log(2.2);
auto x2 = acos(0.0);
}
--
[Issue 12228] Identifiers 'this' and 'super' should not be allowed as base classes
https://issues.dlang.org/show_bug.cgi?id=12228 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Keywords||pull Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com Summary|Compiler allows 'this' in |Identifiers 'this' and |BaseClassList |'super' should not be ||allowed as base classes --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/3505 --
[Issue 9535] incomplete documentation for std.range.recurrence and std.range.sequence
https://issues.dlang.org/show_bug.cgi?id=9535 --- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com --- Looks like I missed the deadline, was busy with other pulls. --
[Issue 12662] New: std.range.retro is not @nogc
https://issues.dlang.org/show_bug.cgi?id=12662
Issue ID: 12662
Summary: std.range.retro is not @nogc
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
void main() @nogc {
import std.range: retro;
int[] data;
foreach_reverse (x; data) {} // OK
foreach (x; data.retro) {} // Error
}
DMD 2.066alpha gives:
test.d(5,5): Error: @nogc function 'D main' cannot call non-@nogc function
'std.range.retro!(int[]).retro.Result!().Result.front'
--
[Issue 1371] Compiler rejects valid delegate.
https://issues.dlang.org/show_bug.cgi?id=1371 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com Hardware|x86 |All OS|Linux |All --
[Issue 1870] Reproduce offending lines in error messages for string mixins
https://issues.dlang.org/show_bug.cgi?id=1870
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
Something seems to be outputted nowadays:
-
string get()
{
return
int x;
int y;
int z = x + b;;
}
void main()
{
mixin(get());
}
-
test.d-mixin-13(15): Error: undefined identifier b
The only problem is, where is test.d-mixin-13?
--
[Issue 12632] Out of range indexing for tuple subtype emits a bad diagnostic
https://issues.dlang.org/show_bug.cgi?id=12632 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com --- *** This issue has been marked as a duplicate of issue 12093 *** --
[Issue 12096] Allow body to be used as an identifier
https://issues.dlang.org/show_bug.cgi?id=12096 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution|--- |WONTFIX --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com --- Seems like Andrei Walter have come to the conclusion that we won't fix this. Closing. https://github.com/D-Programming-Language/dmd/pull/3227 --
[Issue 12093] bad error message: Error: no [] operator overload for type Tuple!(string, string)
https://issues.dlang.org/show_bug.cgi?id=12093 --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com --- *** Issue 12632 has been marked as a duplicate of this issue. *** --
[Issue 10661] Add secureZeroMemory function in Phobos
https://issues.dlang.org/show_bug.cgi?id=10661 David Nadlinger c...@klickverbot.at changed: What|Removed |Added CC||c...@klickverbot.at --- Comment #1 from David Nadlinger c...@klickverbot.at --- +1, this is essential for resilient crypto code. --
[Issue 12663] New: Wrong error message for mutation of immutable static array
https://issues.dlang.org/show_bug.cgi?id=12663
Issue ID: 12663
Summary: Wrong error message for mutation of immutable static
array
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
immutable static int[] data = [1];
static this() {
data.length++;
}
void main() {}
DMD 2.066alpha gives an error message that is both wrong in contents and refers
to the wrong line:
test2.d(1,31): Error: constant 1u is not an lvalue
Expected is an error message like:
test2.d(3,5): Error: cannot modify immutable expression data
--
[Issue 12664] New: @nogc for lazy arguments too
https://issues.dlang.org/show_bug.cgi?id=12664
Issue ID: 12664
Summary: @nogc for lazy arguments too
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
(Issue understood with a little help from Dicebot.)
This compiles:
void foo(int delegate() @nogc x) @nogc {
auto r = x();
}
void main() {
foo(() = 1);
}
This too compiles, performing inference:
void foo(Deleg)(Deleg x) @nogc {
auto r = x();
}
void main() {
foo(() = 1);
}
But this code:
void foo(lazy int x) @nogc {
auto r = x(); // Error
}
void main() {
foo(1);
}
Gives with DMD 2.066alpha:
test.d(2,15): Error: @nogc function 'test.foo' cannot call non-@nogc delegate
'x'
I think the third program should compile.
--
[Issue 12642] Avoid some heap allocation cases for fixed-size arrays
https://issues.dlang.org/show_bug.cgi?id=12642 --- Comment #3 from bearophile_h...@eml.cc --- Another comment by Timon Gehr: The front end already distinguishes dynamic and static array literals (in a limited form), this distinction should simply carry through to code generation and static array literals should be allowed in @nogc code. --
[Issue 12664] @nogc for lazy arguments too
https://issues.dlang.org/show_bug.cgi?id=12664 Sobirari Muhomori dfj1es...@sneakemail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Sobirari Muhomori dfj1es...@sneakemail.com --- The third example can't infer attributes because it doesn't create the delegate, and can't accept arbitrary type info because it's not templated. --
[Issue 12664] @nogc for lazy arguments too
https://issues.dlang.org/show_bug.cgi?id=12664
--- Comment #2 from bearophile_h...@eml.cc ---
(In reply to Sobirari Muhomori from comment #1)
The third example can't infer attributes because it doesn't create the
delegate, and can't accept arbitrary type info because it's not templated.
Thank you, I understand now :-)
Is it a good idea to allow annotations for lazy arguments?
void foo(T)(lazy @nogc x) @nogc {
auto r = x();
}
void main() {
foo(1);
}
I guess lazy arguments are not used commonly enough to deserve such
improvements.
--
[Issue 12664] @nogc for lazy arguments too
https://issues.dlang.org/show_bug.cgi?id=12664
--- Comment #3 from bearophile_h...@eml.cc ---
(In reply to bearophile_hugs from comment #2)
void foo(T)(lazy @nogc x) @nogc {
auto r = x();
}
void main() {
foo(1);
}
Sorry, I meant to write:
void foo(lazy @nogc x) @nogc {
--
[Issue 12664] @nogc for lazy arguments too
https://issues.dlang.org/show_bug.cgi?id=12664 --- Comment #4 from Sobirari Muhomori dfj1es...@sneakemail.com --- Yes, annotation could do the trick. --
[Issue 12665] New: Cannot create enum of struct within the struct, if the struct has a constructor (cannot create a struct until its size is determined)
https://issues.dlang.org/show_bug.cgi?id=12665
Issue ID: 12665
Summary: Cannot create enum of struct within the struct, if the
struct has a constructor (cannot create a struct
until its size is determined)
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: s...@iname.com
Blocks: 340
DMD 2.065 Win32
--
struct DateInterval {
int value;
this(int v) { value = v; }
enum YEAR = DateInterval(365);
}
--
C:\Users\Stewart\Documents\Programming\D\Tests\bugsdmd datetime.d
datetime.d(5): Error: cannot create a struct until its size is determined
--
Same error occurs if I use either
enum {
YEAR = DateInterval(365)
}
or
enum : DateInterval {
YEAR = DateInterval(365)
}
instead. However,
enum DateInterval YEAR = DateInterval(365);
compiles without error.
This has broken Stewart's Utility Library.
--
[Issue 340] [Tracker] Forward reference bugs and other order-of-declaration issues
https://issues.dlang.org/show_bug.cgi?id=340 Stewart Gordon s...@iname.com changed: What|Removed |Added Depends on||12665 --
[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661 j...@red.email.ne.jp changed: What|Removed |Added Keywords||link-failure --- Comment #4 from j...@red.email.ne.jp --- I see. Sorry for my mistake. I inspected it a little. Exposed by Phobos.lib: _D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList11addIntervalMFNaNbNeiikZk Needed by user program: _D3std3uni38__T13InversionListTS3std3uni8GcPolicyZ13InversionList11addIntervalMFNaNeiikZk Their difference is that the latter lacks 'Nb' aka nothrow. The same about the three functions. --
[Issue 12661] [REG2.066a] std.regex with -debug causes linker errors
https://issues.dlang.org/show_bug.cgi?id=12661 --- Comment #5 from j...@red.email.ne.jp --- Finally, I found that std.range.SortedRange.this() breaks the nothrow-ability. It holds a number of debug statements and some of them may throw. Therefore, attributes don't match when -debug added. But I cannot understand why older revisions do work. --
[Issue 12665] Cannot create enum of struct within the struct, if the struct has a constructor (cannot create a struct until its size is determined)
https://issues.dlang.org/show_bug.cgi?id=12665 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- This has been like this since 2.062. I've seen another bug report like this somewhere. --
[Issue 10661] Add secureZeroMemory function in Phobos
https://issues.dlang.org/show_bug.cgi?id=10661 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com --- So who wants to implement it? --
[Issue 11011] core.time.Duration has example code which cannot compile
https://issues.dlang.org/show_bug.cgi?id=11011 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Keywords||pull CC||andrej.mitrov...@gmail.com Component|Phobos |druntime Assignee|nob...@puremagic.com|andrej.mitrov...@gmail.com Summary|struct core.time.Duration |core.time.Duration has |member this is not |example code which cannot |accessible |compile --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com --- https://github.com/D-Programming-Language/druntime/pull/780 --
[Issue 10661] Add secureZeroMemory function in Phobos
https://issues.dlang.org/show_bug.cgi?id=10661 --- Comment #3 from bearophile_h...@eml.cc --- (In reply to Walter Bright from comment #2) So who wants to implement it? How do you like to implement it? As a special case, or introducing some kind of generic and reusable annotation, like @keep_function that tells the D compiler to never optimize away the calls to a specific function? I don't know what other cases there are of functions that must never be removed. --
[Issue 12666] New: @nogc std.array.front, popFront, and more
https://issues.dlang.org/show_bug.cgi?id=12666
Issue ID: 12666
Summary: @nogc std.array.front, popFront, and more
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
import std.algorithm: map;
immutable data = [1];
void main() @nogc {
foreach (w; data.map!((x) @nogc pure nothrow = x)) {}
}
test.d(4,5): Error: @nogc function 'D main' cannot call non-@nogc function
'test.main.MapResult!(__lambda1, immutable(int)[]).MapResult.popFront'
test.d(4,5): Error: @nogc function 'D main' cannot call non-@nogc function
'test.main.MapResult!(__lambda1, immutable(int)[]).MapResult.front'
Taking a better look the problem seems to be in std.array.front (and popFront):
@property ref T front(T)(T[] a) @safe pure nothrow
if (!isNarrowString!(T[]) !is(T[] == void[]))
{
assert(a.length, Attempting to fetch the front of an empty array of ~
T.stringof);
return a[0];
}
void main() @nogc {
auto data = [1];
data.front;
}
A possible solution:
import std.traits: isNarrowString;
@property ref T front(T)(T[] a) @safe pure nothrow
if (!isNarrowString!(T[]) !is(T[] == void[]))
{
enum msg = Attempting to fetch the front of an empty array of ~
T.stringof;
assert(a.length, msg);
return a[0];
}
void main() @nogc {
auto data = [1];
data.front;
}
A small disadvantage of this solution is that the error message is now computed
statically, increasing binary size. But those array functions are too much
important, otherwise lot of other ranges can't work in @nogc code.
--
[Issue 12666] @nogc std.array.front, popFront, and more
https://issues.dlang.org/show_bug.cgi?id=12666 --- Comment #1 from bearophile_h...@eml.cc --- (In reply to bearophile_hugs from comment #0) enum msg = Attempting to fetch the front of an empty array of ~ T.stringof; assert(a.length, msg); A little shorter code, that requires less changes: assert(a.length, ctEval!(Attempting to fetch the front of an empty array of ~ T.stringof)); Where ctEval is a very small construct that should be added to Phobos that forces the evaluation of an expression at compile-time. --
[Issue 11162] Cannot use implicit ctor call with enum members
https://issues.dlang.org/show_bug.cgi?id=11162 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||k.hara...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- @Kenji: Do you think this is a bug or an invalid issue? It could go either way I guess. --
[Issue 11093] Can't compile DMD with VS12
https://issues.dlang.org/show_bug.cgi?id=11093 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution|--- |WORKSFORME --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com --- If you can reproduce this with git-head please reopen. Thanks. --
[Issue 11094] Disuniform error messages with overloaded + and ^ operators
https://issues.dlang.org/show_bug.cgi?id=11094
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com ---
Note that it is unrelated to the overloads, you could have a single opBinary to
reproduce:
-
struct Foo
{
Foo opBinary(string op)(in Foo r) if (op == + || op == ^)
{
return Foo();
}
}
void main()
{
const x = Foo();
auto r1 = x + Foo();
auto r2 = x ^ Foo();
}
-
--
[Issue 11093] Can't compile DMD with VS12
https://issues.dlang.org/show_bug.cgi?id=11093 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com --- I can't reproduce this problem. This was either fixed since the issue was reported, or it was never broken. I don't understand why you advocate removing an entire optimized variant of the function when it would be simpler to #define __pascal to nothing. Which is what is already done in vcbuild/warnings.h, so I don't know where your error comes from. --
[Issue 11079] Attributes for template functions should be visible when used with traits
https://issues.dlang.org/show_bug.cgi?id=11079 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com --- Walter's comment from here: https://github.com/D-Programming-Language/dmd/pull/3501#issuecomment-41484446 Should it work? No. It's not a function until it is instantiated. In fact, the attributes cannot be determined until it is instantiated, because attributes are inferred on function templates. So I'm marking this as invalid. But maybe a set of better docs need to be made for the traits page. --
[Issue 11694] std.traits.SetFunctionAttributes does not conserve constness
https://issues.dlang.org/show_bug.cgi?id=11694 Issue 11694 depends on issue 12653, which changed state. Issue 12653 Summary: Add the getFunctionAttributes trait https://issues.dlang.org/show_bug.cgi?id=12653 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12653] Add the getFunctionAttributes trait
https://issues.dlang.org/show_bug.cgi?id=12653 --- 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/989b73fc2d4f93be0cf5ed19fdfb060629fa49eb Fix Issue 12653 - Implement the getFunctionAttributes trait. https://github.com/D-Programming-Language/dmd/commit/b65f13e528b235927494bff6ac22ea38acc3cf44 Merge pull request #3501 from AndrejMitrovic/Fix12653 Issue 12653 - Implement the getFunctionAttributes trait. --
[Issue 12651] TemplateArgsOf accepts nonsensical arguments
https://issues.dlang.org/show_bug.cgi?id=12651 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12651] TemplateArgsOf accepts nonsensical arguments
https://issues.dlang.org/show_bug.cgi?id=12651 --- 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/1e78567964f36c62df83de1e050bd907a180b606 fix Issue 12651 - TemplateArgsOf accepts nonsensical arguments https://github.com/D-Programming-Language/dmd/commit/68aa8cc276c97dceab6746b629014ed3c782bbc8 Merge pull request #3502 from 9rnsr/fix12651 Issue 12651 - TemplateArgsOf accepts nonsensical arguments --
[Issue 11511] DDoc - C variadic parameters cannot be properly documented
https://issues.dlang.org/show_bug.cgi?id=11511 --- 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/a01afe0188d0b7a26cb4dcebf0b3a8b97f027c56 Fix Issue 11511 - DDoc - C variadic parameters cannot be properly documented. https://github.com/D-Programming-Language/dmd/commit/65a67f99ad642378a4c3aea321af8ef9f5e4918f Merge pull request #3503 from AndrejMitrovic/Fix11511 Issue 11511 - DDoc C variadic parameters cannot be properly documented. --
[Issue 12667] New: Enforce static constructors lexical order in a module to respect their use order
https://issues.dlang.org/show_bug.cgi?id=12667
Issue ID: 12667
Summary: Enforce static constructors lexical order in a module
to respect their use order
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: accepts-invalid, diagnostic
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
This was inspired by a problem found by spec in D.learn:
http://forum.dlang.org/thread/gjbhmzkohtmlthnog...@forum.dlang.org
This reduced program:
struct Foo {
static this() {
Bar b;
int x = b.data[0]; // RangeError
}
}
struct Bar {
static int[] data;
static this() {
data.length++;
}
}
void main() {}
Gives with DMD 2.066alpha:
core.exception.RangeError@test(4): Range violation
If you swap the position of the Foo and Bar classes in the module you receive
no errors.
As explained here: Static constructors within a module are executed in the
lexical order in which they appear.
http://dlang.org/class.html#StaticConstructor
So, if Foo depends on Bar then Bar static this must appear before Foo one.
A similar example:
struct Foo {
static this() {
Bar b;
int x = b.data[0];
}
}
struct Bar {
immutable static int[] data;
static this() {
data.length++;
}
}
void main() {}
So I suggest to introduce a little D breaking change (that probably is not
going to break a lot of code. In the shown case it just turns a run-time error
in a compile-time one): is it possible and a good idea to raise a compilation
error in such cases where code tries to use Bar static fields before bar static
this() has run? (Perhaps a more fine-grained error is useful, that tracks
single fields, to allow more flexible code of mutually initializing
constructors, or perhaps it's not necessary).
--
[Issue 12668] New: std.traits.functionAttributes should use the new getFunctionAttributes trait
https://issues.dlang.org/show_bug.cgi?id=12668 Issue ID: 12668 Summary: std.traits.functionAttributes should use the new getFunctionAttributes trait Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: pull Severity: normal Priority: P1 Component: Phobos Assignee: andrej.mitrov...@gmail.com Reporter: andrej.mitrov...@gmail.com Self-assigned, pull coming soon. --
[Issue 12090] Make std.concurrency compatible with fibers as threads
https://issues.dlang.org/show_bug.cgi?id=12090 Brad Anderson e...@gnuk.net changed: What|Removed |Added CC||e...@gnuk.net --- Comment #5 from Brad Anderson e...@gnuk.net --- The pull request looks nice. How hard do you think it'd be to add an M:N scheduler to the mix? --
[Issue 12668] std.traits.functionAttributes should use the new getFunctionAttributes trait
https://issues.dlang.org/show_bug.cgi?id=12668 --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com --- https://github.com/D-Programming-Language/phobos/pull/2131 --
[Issue 12669] New: autotester: Weekly Issues resolved graph is out of bounds
https://issues.dlang.org/show_bug.cgi?id=12669 Issue ID: 12669 Summary: autotester: Weekly Issues resolved graph is out of bounds Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: andrej.mitrov...@gmail.com Fairly minor, probably a good problem to have, but in the last graph here: https://auto-tester.puremagic.com/chart.ghtml?projectid=1 The graph has gone off-screen because there were more than 100 issues closed in a few months. Maybe set the graph vertical size to 2x (to use more screen space) and then set the limit to 200? --
[Issue 11011] core.time.Duration has example code which cannot compile
https://issues.dlang.org/show_bug.cgi?id=11011 --- Comment #3 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/ec3317c98d712e6ef2f99a17d6f6ea129e1453ee Fix Issue 11011 - Remove uncompilable example and use a documented unittest. https://github.com/D-Programming-Language/druntime/commit/bc83d2f578b1f96b8143f1c87de8f9da11c5cf6a Merge pull request #780 from AndrejMitrovic/Fix11011 Issue 11011 - Remove uncompilable example and use a documented unittest --
[Issue 11011] core.time.Duration has example code which cannot compile
https://issues.dlang.org/show_bug.cgi?id=11011 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 12670] New: std.algorithm.sum @nogc for simple cases
https://issues.dlang.org/show_bug.cgi?id=12670
Issue ID: 12670
Summary: std.algorithm.sum @nogc for simple cases
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
import std.algorithm: sum;
auto data = [1];
void main() @nogc {
data.sum;
}
Gives with DMD 2.066alpha:
test.d(4,9): Error: @nogc function 'D main' cannot call non-@nogc function
'std.algorithm.sum!(int[]).sum'
--
[Issue 12671] New: std.complex abs and ^^ @nogc
https://issues.dlang.org/show_bug.cgi?id=12671
Issue ID: 12671
Summary: std.complex abs and ^^ @nogc
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
void main() @nogc {
import std.complex;
auto x = complex(1.0, 1.0);
auto y = x ^^ 2;
auto z = x.abs;
}
Gives with DMD 2.066alpha:
test.d(4,14): Error: @nogc function 'D main' cannot call non-@nogc function
'std.complex.Complex!double.Complex.opBinary!(^^, int).opBinary'
test.d(5,15): Error: @nogc function 'D main' cannot call non-@nogc function
'std.complex.abs!double.abs'
--
[Issue 2540] super can not be using in alias statement
https://issues.dlang.org/show_bug.cgi?id=2540 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Version|2.022 |D2 Severity|normal |enhancement --- Comment #5 from Walter Bright bugzi...@digitalmars.com --- This should have been marked as an enhancement. It also produces the behavior illustrated by https://issues.dlang.org/show_bug.cgi?id=12228 --
[Issue 12228] Identifiers 'this' and 'super' should not be allowed as base classes
https://issues.dlang.org/show_bug.cgi?id=12228 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com --- The Issue 2540 definitely introduced this. Looking back on it, 2540 was probably a bad idea, but I think we're stuck with it. Trying to step on its other effects just seems to complicate things even more. I suggest just leaving this one alone. --
[Issue 11307] Make const(T).init and immutable(T).init lvalues
https://issues.dlang.org/show_bug.cgi?id=11307 --- Comment #3 from Kenji Hara k.hara...@gmail.com --- (In reply to monarchdodra from comment #0) .init is a global property, that is marked as rvalue, to prevent it being modified. This is correct behavior. However, when T is const/immutable already, then it is illegal to modify it anyways. Making .init an lvalue for such cases has advantages. Not only to prevent its modification, T.init makes an rvalue to prevent copy construction on its usage. auto t = T.init; If T.init returns an lvalue, initializing t will always invoke T's postblit if exists. --
[Issue 12647] Lazy parameter evaluation should be marked as nothrow
https://issues.dlang.org/show_bug.cgi?id=12647 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #3 from Kenji Hara k.hara...@gmail.com --- *** Issue 12664 has been marked as a duplicate of this issue. *** --
[Issue 12664] @nogc for lazy arguments too
https://issues.dlang.org/show_bug.cgi?id=12664
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #5 from Kenji Hara k.hara...@gmail.com ---
Lazy argument is implicitly converted to scope local delegate. And the
original argument @safe-ty and purity are implicitly treated as they belong to
the caller side.
int foo(lazy int x) pure @safe { return x(); }
int get() { return 1; } // impure un@safe
void main()
{
foo(get()); // OK!
}
So I think that nothrow-ness and @nogc-ability should be treated as same.
*** This issue has been marked as a duplicate of issue 12647 ***
--
