[Issue 14782] Internal error: backend/cod1.c
https://issues.dlang.org/show_bug.cgi?id=14782 Walter Bright changed: What|Removed |Added CC||rswhi...@gmail.com --- Comment #3 from Walter Bright --- *** Issue 14987 has been marked as a duplicate of this issue. *** --
[Issue 14987] Internal error: backend/cod1.c 1711
https://issues.dlang.org/show_bug.cgi?id=14987 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution|--- |DUPLICATE --- Comment #6 from Walter Bright --- *** This issue has been marked as a duplicate of issue 14782 *** --
[Issue 15027] cannot pass arguments of type DirEntry to std.file functions
https://issues.dlang.org/show_bug.cgi?id=15027
--- Comment #4 from Walter Bright ---
The trouble is InputRange has to modify the range.
A solution is to rewrite DirEntry.name from:
@property string name() const pure nothrow
{
return _name;
}
to:
string _name2;
@property ref string name() return const pure nothrow
{
_name2 = _name;
return _name2;
}
but there'll be trouble with that if there are two calls to name() within the
same expression and both try to modify through the ref.
--
[Issue 15027] cannot pass arguments of type DirEntry to std.file functions
https://issues.dlang.org/show_bug.cgi?id=15027 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright --- (In reply to Rainer Schuetze from comment #2) > The main problem is that DirEntry does not qualify as an InputRange, because > the aliased property returns an rvalue. This cannot be passed to popFront > through UFCS as it expectes a ref argument. I think this is correct. If you remove the 'ref' from 'popFront', it works. It also works if DirEntry is defined as: string name; alias name this; i.e. then 'name' becomes an lvalue. popFront() cannot update an rvalue. --
[Issue 15140] New: std.experimental.allocator.building_blocks.free_list.FreeList leaks memory
https://issues.dlang.org/show_bug.cgi?id=15140 Issue ID: 15140 Summary: std.experimental.allocator.building_blocks.free_list.F reeList leaks memory Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: briancsch...@gmail.com Copied from a comment on the merge request on Github: FreeList has no destructor. This means that if there is a free list backed by Mallocator, any memory that user code tried to deallocate but was still on the free list at the time that the list went out of scope will be leaked. --
[Issue 15138] ICE with basic use of stdx.data.json
https://issues.dlang.org/show_bug.cgi?id=15138 --- Comment #3 from monkeywork...@hotmail.com --- Just basic Windows cmd.exe, using Dub to build the program. My directory layout is the standard Dub layout. A top-level project folder containing dub.json et al., as well as a `source` directory containing app.d with the offending code. Navigating to that folder and typing `dub` to run the build process is enough to produce the error. --
[Issue 15139] New: allow foreach over Range*
https://issues.dlang.org/show_bug.cgi?id=15139
Issue ID: 15139
Summary: allow foreach over Range*
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: john.loughran.col...@gmail.com
We should allow foreach over pointers to range types, or alternatively change
std.range.isInputRange to disallow pointers to range types.
Currently we have this:
alias Range = Repeat!int;
static assert(isInputRange!(Range*));
//but
static assert(!isIterable!(typeof(a)*));
//because
static assert(!__traits(compiles, { foreach(_; &a){} }));
so just because you checked whether something is an input range, doesn't mean
you can actually use foreach over it.
One way or another, resolving this would deal with
https://issues.dlang.org/show_bug.cgi?id=11779 and
https://issues.dlang.org/show_bug.cgi?id=15096
Note that pointers to ranges can't pass hasSlicing or IsRandomAccessRange
because of course the indexing would be all wrong.
--
[Issue 15138] ICE with basic use of stdx.data.json
https://issues.dlang.org/show_bug.cgi?id=15138 Marc Schütz changed: What|Removed |Added CC||schue...@gmx.net --- Comment #2 from Marc Schütz --- Which exact command line and directory layout are you using? I cannot reproduce this currently with any of 2.068.1, 2.068.2 or master. --
[Issue 15132] std.algorithm.sort crash on windows
https://issues.dlang.org/show_bug.cgi?id=15132 --- Comment #4 from Steven Schveighoffer --- (In reply to mzf from comment #3) > yes,i call the builtin array sort... > my actual opCmp code is quite complicated,i check the code a long time > and find there are different results on different platforms. Any chance you can try the std.algorithm.sort? It may have more useful error (or more consistent behavior at least). Also, can you narrow down the code to a minimal example that causes the undesired behavior? It's possible there is an issue with the builtin sort. But sort really does require that items it has already sorted are sorted. I'm not sure what steps it assumes are correct. An access violation doesn't seem like it should happen, but it's possibly due to an optimization that is invalid with an invalid opCmp. --
[Issue 15137] core.time: Support Duration/Duration and Duration%Duration
https://issues.dlang.org/show_bug.cgi?id=15137 Vladimir Panteleev changed: What|Removed |Added Keywords||pull --- Comment #1 from Vladimir Panteleev --- https://github.com/D-Programming-Language/druntime/pull/1401 --
[Issue 15138] ICE with basic use of stdx.data.json
https://issues.dlang.org/show_bug.cgi?id=15138 --- Comment #1 from monkeywork...@hotmail.com --- This is using DMD 2.068.2. The code reportedly works with 2.068.1. --
[Issue 15138] New: ICE with basic use of stdx.data.json
https://issues.dlang.org/show_bug.cgi?id=15138
Issue ID: 15138
Summary: ICE with basic use of stdx.data.json
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
The following code:
import stdx.data.json;
void main()
{
string str = `{"a": true, "b": "test"}`;
auto v = parseJSONValue(str);
// The following line causes the problem in 2.068.2
auto obj = v.get!(JSONValue[string]);
}
Fails to compile with the following error:
Assertion failure: 'minst->isRoot() || minst->rootImports()' on line 8013 in
file 'template.c'
stdx.data.json can be found here:
https://github.com/s-ludwig/std_data_json
--
[Issue 15137] New: core.time: Support Duration/Duration and Duration%Duration
https://issues.dlang.org/show_bug.cgi?id=15137
Issue ID: 15137
Summary: core.time: Support Duration/Duration and
Duration%Duration
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
CC: issues.dl...@jmdavisprog.com
Currently porting some D1 code to D2, and some of the D1 code is quite annoying
as rewritten to use core.time.
Example 1:
auto units = [
"days" : TicksPerDay,
"hours" : TicksPerHour,
"seconds" : TicksPerSecond,
];
d_time d = 1234567890;
foreach (name, duration; units)
writefln("%d %s", d/duration, name);
Converting between time units when you don't know the unit during compilation
using core.time is excessively verbose - you have to use something like:
duration.total!"hnsecs" / unit.total!"hnsecs". This is also leaking a low-level
detail (that Duration is internally represented as hnsecs).
Example 2:
fiveMinuteTotals[delta % TicksPerDay / (5*TicksPerMinute)]++;
This calculates collective frequency when during the day events occur, with
five-minute granularity. With core.time, this becomes something like...
fiveMinuteTotals[delta.split!("days", "hnsecs").hnsecs /
5.minutes.total!"hnsecs"]++;
I really don't see any reason why Duration should not support binary / and %
with two Durations.
--
[Issue 15136] If we want toStringz to be fully correct, it needs to stop checking for '\0'
https://issues.dlang.org/show_bug.cgi?id=15136 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic --- +1. If we really need to avoid memory allocations let's just add an overload or something like assumeZeroTerminated or something.. --
[Issue 15060] Can't load a D shared library first, then load a C shared library
https://issues.dlang.org/show_bug.cgi?id=15060 --- Comment #15 from bitwise --- (In reply to bitwise from comment #14) > (In reply to Jacob Carlborg from comment #13) > > [...] > > Right, which is why I am recommending the special pragmas(or pragma). Basically, we need these: pragma(attribute, weak) pragma(visibility, hidden) pragma(section, "__mod_init_func"); pragma(section, "__mod_term_func"); --
[Issue 15060] Can't load a D shared library first, then load a C shared library
https://issues.dlang.org/show_bug.cgi?id=15060 --- Comment #14 from bitwise --- (In reply to Jacob Carlborg from comment #13) > (In reply to bitwise from comment #12) > > (In reply to Jacob Carlborg from comment #10) > > >> DMD already does what's necessary for ELF (Linux, FreeBSD). Just do the > > >> same > > >> for Mach-O and OS X. > > > > That's easier said than done ;) > > :) > > > This is why I was saying we should just add some(or one special one) pragmas > > that will allow this to be done in the front end. > > I don't think this can be completely done in the front end. The code (or > that function) that should be run as a global ctor/dtor need to be placed in > a special segment/section, if I recall correctly. Right, which is why I am recommending the special pragmas(or pragma). --
[Issue 15132] std.algorithm.sort crash on windows
https://issues.dlang.org/show_bug.cgi?id=15132 --- Comment #3 from mzfh...@foxmail.com --- (In reply to Steven Schveighoffer from comment #1) > 1. You are not calling std.algorithm.sort, you are calling builtin array > sort. You need to add the parentheses. > > 2. I don't know that we need to concern ourselves with invalid opCmp yes,i call the builtin array sort... my actual opCmp code is quite complicated,i check the code a long time and find there are different results on different platforms. --
[Issue 15133] Error message is incomprehensible
https://issues.dlang.org/show_bug.cgi?id=15133 Sobirari Muhomori changed: What|Removed |Added Keywords||diagnostic --
[Issue 15060] Can't load a D shared library first, then load a C shared library
https://issues.dlang.org/show_bug.cgi?id=15060 --- Comment #13 from Jacob Carlborg --- (In reply to bitwise from comment #12) > (In reply to Jacob Carlborg from comment #10) > >> DMD already does what's necessary for ELF (Linux, FreeBSD). Just do the > >> same > >> for Mach-O and OS X. > > That's easier said than done ;) :) > This is why I was saying we should just add some(or one special one) pragmas > that will allow this to be done in the front end. I don't think this can be completely done in the front end. The code (or that function) that should be run as a global ctor/dtor need to be placed in a special segment/section, if I recall correctly. --
