[Issue 16170] New: std.algorithm.sorting.partition has many issues
https://issues.dlang.org/show_bug.cgi?id=16170 Issue ID: 16170 Summary: std.algorithm.sorting.partition has many issues Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com * The SwapStrategy.semistable branch does not call save for result, therefore this breaks with forward ranges * The SwapStrategy.unstable !isDynamicArray branch does not call save for result, therefore this breaks with forward ranges * The SwapStrategy.unstable !isDynamicArray branch requires a bidirectional range, only forward range primitives are tested for * is(typeof(swap(result.front, r.front))) is never tested for A lot of this stems from the fact that arrays are the only means of testing for this function --
[Issue 15498] Unhelpful error message "destructors, postblits and invariants are not allowed in overlapping fields"
https://issues.dlang.org/show_bug.cgi?id=15498 joeyemm...@yahoo.com changed: What|Removed |Added CC||joeyemm...@yahoo.com --- Comment #8 from joeyemm...@yahoo.com --- I am getting this too, definitely don't have any unions. My issue seems to be caused by some kind of import ordering problem, reordering some of my imports makes it go away. Making a minimized reproduction might be hard. --
[Issue 16169] nWayUnion assertion failure
https://issues.dlang.org/show_bug.cgi?id=16169 --- Comment #1 from Justin Whear --- The suggested fix in my previous comment actually just hides the issue in some situations. Changing one of the `iota(1,3)` lines in the test cases causes a popFront on an empty iota range. --
[Issue 16169] New: nWayUnion assertion failure
https://issues.dlang.org/show_bug.cgi?id=16169
Issue ID: 16169
Summary: nWayUnion assertion failure
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: critical
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: jus...@economicmodeling.com
nWayUnion fails when used with chunkBy with the following:
object.Exception@/home/justin/.dvm/compilers/dmd-2.071.1-b2/linux/bin/../../src/phobos/std/container/binaryheap.d(234):
Cannot call front on an empty heap.
Using this test case:
import std.range, std.algorithm;
void main(string[] args)
{
auto ror = [
iota(1,3),
iota(2,3),
iota(1,3),
];
auto un = nWayUnion(ror).chunkBy!`a==b`;
import std.stdio;
writeln(un);
}
Altering
https://github.com/dlang/phobos/blob/master/std/algorithm/setops.d#L812 to
check `_heap.empty` seems to correct the problem, but raises the issue of how
the _heap and _ror are getting out of sync. Removing the `chunkBy` from the
test case also eliminates the issue, suggesting that it's the conjunction of
the two.
--
[Issue 15704] @safe code should not allow copying of void[]
https://issues.dlang.org/show_bug.cgi?id=15704 Nick Treleaven changed: What|Removed |Added CC||ntrel-...@mybtinternet.com --- Comment #1 from Nick Treleaven --- Shouldn't we just disallow all writes to a void[] in safe code? --
[Issue 12822] Delegate .ptr assignment considered @safe
https://issues.dlang.org/show_bug.cgi?id=12822 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/73301fec8727569aedd6f9f94a2217a38a525d24 Actually test compiler output for issue 12822 This is a fix-up for pull #5851. https://github.com/dlang/dmd/commit/f7d88d54d8f499ed05a9ecd3b28c819c8ecdf8bb Merge pull request #5865 from denis-sh/patch-2 Actually test compiler output for issue 12822 --
[Issue 15900] [REG 2.071] (Import deprecation) Public import ignored when using fully qualified name
https://issues.dlang.org/show_bug.cgi?id=15900
--- Comment #2 from Timothee Cour ---
(In reply to Timothee Cour from comment #1)
> (In reply to Vladimir Panteleev from comment #0)
> > / test.d /
> > import std.datetime;
> >
> > unittest
> > {
> > cast(void)core.time.hnsecs(1);
> > }
> > //
> >
> > $ dmd -w -unittest -o- test.d
> > test.d(5): Deprecation: module core.time is not accessible here, perhaps add
> > 'static import core.time;'
> >
> > However, std.datetime publicly imports core.time, so the warning is
> > spurious. The code compiles fine when NOT using the fully-qualified name.
>
> still there in 2.071.1 beta 2
this is also broken:
fun.d:
public import std.string
public static import std.string
main.d:
import fun;
void main(){
auto a=std.string.isNumeric("12");
// module std.string is not accessible here, perhaps add 'static import
std.string;'
}
--
[Issue 15900] [REG 2.071] (Import deprecation) Public import ignored when using fully qualified name
https://issues.dlang.org/show_bug.cgi?id=15900
Timothee Cour changed:
What|Removed |Added
CC||timothee.co...@gmail.com
--- Comment #1 from Timothee Cour ---
(In reply to Vladimir Panteleev from comment #0)
> / test.d /
> import std.datetime;
>
> unittest
> {
> cast(void)core.time.hnsecs(1);
> }
> //
>
> $ dmd -w -unittest -o- test.d
> test.d(5): Deprecation: module core.time is not accessible here, perhaps add
> 'static import core.time;'
>
> However, std.datetime publicly imports core.time, so the warning is
> spurious. The code compiles fine when NOT using the fully-qualified name.
still there in 2.071.1 beta 2
--
[Issue 15538] final switch statement raises an exception even though all cases are covered under certain conditions
https://issues.dlang.org/show_bug.cgi?id=15538 Johannes Loher changed: What|Removed |Added Attachment #1573|0 |1 is obsolete|| --- Comment #1 from Johannes Loher --- Created attachment 1600 --> https://issues.dlang.org/attachment.cgi?id=1600&action=edit new code example --
[Issue 16168] New: isCopyable trait for value types
https://issues.dlang.org/show_bug.cgi?id=16168 Issue ID: 16168 Summary: isCopyable trait for value types Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com We have hasElaborateCopyConstructor, but we don't have something that tells us if copying is disabled or not. --
[Issue 16150] Rework overview of D's features page
https://issues.dlang.org/show_bug.cgi?id=16150 --- Comment #2 from greensunn...@gmail.com --- I just created the issue as a reminder of Andrei's recent comment: > "overview of special features of D" -> "overview of D's differentiating > features". That page needs to be redone... (at https://github.com/dlang/dlang.org/pull/1314) --
[Issue 16150] Rework overview of D's features page
https://issues.dlang.org/show_bug.cgi?id=16150 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com --- Comment #1 from Jack Stouffer --- What about it specifically is outdated? I went through it about six months ago and cleaned everything up. --
[Issue 16019] Implement a way to check GC usage stats from application
https://issues.dlang.org/show_bug.cgi?id=16019 --- Comment #1 from Dicebot --- https://github.com/dlang/druntime/pull/1591 --
[Issue 16149] foreach_reverse can't handle index variable of type int
https://issues.dlang.org/show_bug.cgi?id=16149
--- Comment #7 from Steven Schveighoffer ---
(In reply to Ketmar Dark from comment #6)
> (In reply to Steven Schveighoffer from comment #5)
> > int x = a.length would continue to be invalid (on 64-bit CPU). It's just for
> > foreach_reverse.
>
> then i'll inevitably ask why `int x = a.length;` is invalid, but
> `foreach_reverse (int x, v; a)` is valid. that `foreach` obviously does the
> assign under the hood (at least this is the most practical way to imagine
> it).
foreach_reverse could be implemented like this:
for(size_t __idx = a.length; __idx; --__idx)
{
int x = cast(int)(__idx - 1);
auto v = a[__idx-1];
... // your code
}
In fact, if foreach was implemented similarly (always using hidden size_t to
iterate and assigning to your chosen variable as the index), it wouldn't get
into an infinite loop.
> the only way to skip that "hidden assign" is to redefive `foreach_reverse`
> completely — by still using increasing index in it, so x will go from 0 upto
> limit. otherwise you just introducing a random pseudo-solution by randomly
> breaking the rules.
The definition of foreach_reverse on an array is that it works exactly like
foreach, but visits the elements in reverse. There is no definition of how it
does this, so my implementation is valid. (in fact, the spec says the index
must be int, uint, or size_t, but I think this is a relic from 32-bit, non VRP
days).
The fact that the implementation rejects it is an implementation detail
leaking. It's not a *bad* thing, but clearly this is the case of the compiler
being too cautious, because it's OK with you being stupid in foreach.
--
[Issue 16096] Linking to static library: can't parse __DATA/__objc_imageinfo
https://issues.dlang.org/show_bug.cgi?id=16096 --- Comment #3 from Jacob Carlborg --- https://github.com/dlang/dmd/pull/5862 --
