[Issue 18943] core.internal.hash remove outdated special case for DMD unaligned reads
https://issues.dlang.org/show_bug.cgi?id=18943 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2210 --
[Issue 18943] New: core.internal.hash remove outdated special case for DMD unaligned reads
https://issues.dlang.org/show_bug.cgi?id=18943 Issue ID: 18943 Summary: core.internal.hash remove outdated special case for DMD unaligned reads Product: D Version: D2 Hardware: x86 OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com core.internal.hash has lines dating back to its initial commit on November 16, 2013 that disable unaligned reads when using DMD comment that a DMD bug would prevent inlining. That is not true in the present day so the comment and alternative code branch have no purpose except to confuse. With optimization enabled DMD produces the same code for `return *cast(uint*)x;` and `return ((cast(uint) x[3]) << 24) | ((cast(uint) x[2]) << 16) | ((cast(uint) x[1]) << 8) | (cast(uint) x[0]);` when `x` is `ubyte*`, so this patch is not expected to improve performance except for non-optimized builds. --
[Issue 18942] core.internal.hash can take advantage of alignment info on non-x86
https://issues.dlang.org/show_bug.cgi?id=18942 --- Comment #1 from Nathan S. --- Pull request: https://github.com/dlang/druntime/pull/2209 --
[Issue 18942] core.internal.hash can take advantage of alignment info on non-x86
https://issues.dlang.org/show_bug.cgi?id=18942 Nathan S. changed: What|Removed |Added Summary|core.internal.hash should |core.internal.hash can take |take advantage of alignment |advantage of alignment info |info on non-x86 |on non-x86 --
[Issue 18942] core.internal.hash should take advantage of alignment info on non-x86
https://issues.dlang.org/show_bug.cgi?id=18942 Nathan S. changed: What|Removed |Added Summary|core.internal.hash take |core.internal.hash should |advantage of alignment info |take advantage of alignment |on non-x86 |info on non-x86 --
[Issue 18942] New: core.internal.hash take advantage of alignment info on non-x86
https://issues.dlang.org/show_bug.cgi?id=18942 Issue ID: 18942 Summary: core.internal.hash take advantage of alignment info on non-x86 Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com On machines that do not support unaligned memory access, core.internal.hash should use statically available alignment information to determine when `uint` reads can be used. --
[Issue 18934] std.concurrency receive throws assertion failure if message is a struct containing const data
https://issues.dlang.org/show_bug.cgi?id=18934 Steven Schveighoffer changed: What|Removed |Added Summary|std.concurrency receive |std.concurrency receive |throws assertion failure if |throws assertion failure if |message is a struct of |message is a struct |struct |containing const data --
[Issue 18809] Improve error message on nonexistent property
https://issues.dlang.org/show_bug.cgi?id=18809 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --
[Issue 18934] std.concurrency receive throws assertion failure if message is a struct of struct
https://issues.dlang.org/show_bug.cgi?id=18934 Steven Schveighoffer changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86_64 |All OS|Linux |All --- Comment #3 from Steven Schveighoffer --- PR: https://github.com/dlang/phobos/pull/6544 --
[Issue 18868] Separate compilation generates two static this functions, runs it twice
https://issues.dlang.org/show_bug.cgi?id=18868
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #4 from FeepingCreature ---
This also fixes this issue:
static foreach (entry; ["foo", "bar", "baz"])
{
unittest
{
writeln(entry);
}
}
foo
foo
foo
which happened because all three unittest blocks had the same identifier, based
on line number.
--
[Issue 18934] std.concurrency receive throws assertion failure if message is a struct of struct
https://issues.dlang.org/show_bug.cgi?id=18934
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
Assignee|nob...@puremagic.com|schvei...@yahoo.com
--- Comment #2 from Steven Schveighoffer ---
The issue comes from std.variant.Variant checking the wrong thing when it comes
to constancy.
A smaller test case:
import std.variant;
import std.stdio;
struct S
{
const int x;
}
void main()
{
Variant v = S(1);
writeln(v.get!S); // error
}
The issue is with the check inside std.variant to see if you can copy the given
type to the requested type. The type matches, but the copy would normally fail
because you can't overwrite const data.
However, in the case of v.get!S, it's a move and not a copy. The check should
be on moving the data, not copying. I have tested a fix, will submit a PR.
--
[Issue 17580] Marking methods as synchronized is allowed despite spec
https://issues.dlang.org/show_bug.cgi?id=17580 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- PR: https://github.com/dlang/dmd/pull/8331 --
[Issue 18940] [std.net.curl]Can't run examples on page. cannot implicitly convert expression ... `char[]` to `string`
https://issues.dlang.org/show_bug.cgi?id=18940 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/14fe47491b0ad48a53609019e9454936cd6a3c56 Fix Issue 18940 - [std.net.curl]Can't run examples on page. cannot implicitly convert expression https://github.com/dlang/phobos/commit/0eff855c7c3cf7ac7bfbb27fbfb68f7e32deb32f Merge pull request #6540 from wilzbach/fix-18940 Fix Issue 18940 - [std.net.curl]Can't run examples on page. cannot implicitly convert expression merged-on-behalf-of: Vladimir Panteleev --
[Issue 18941] Memory corruption when using a mixin template
https://issues.dlang.org/show_bug.cgi?id=18941 greenify changed: What|Removed |Added CC||greeen...@gmail.com --
[Issue 7925] extern(C++) delegates?
https://issues.dlang.org/show_bug.cgi?id=7925 Manu changed: What|Removed |Added Keywords||C++, industry --- Comment #1 from Manu --- As in https://issues.dlang.org/show_bug.cgi?id=18928, we have observed that C++ and D method calling convention is different (RVO expectations don't match). This means delegates need to know their calling convention, otherwise they will call incorrectly for the function that's assigned to them. I suggest `extern(C++) delegate` which would guarantee the delegate uses the appropriate C++ calling convention. --
[Issue 18928] extern(C++) bad codegen, wrong calling convention
https://issues.dlang.org/show_bug.cgi?id=18928 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #11 from Rainer Schuetze --- Try this https://github.com/dlang/dmd/pull/8330 --
[Issue 18928] extern(C++) bad codegen, wrong calling convention
https://issues.dlang.org/show_bug.cgi?id=18928 --- Comment #10 from Manu --- Awesome sauce... sadly, for the immediate moment, I really need a fix in DMD >_< --
