[Issue 19014] Compiler imports symbols that aren't actually imported.
https://issues.dlang.org/show_bug.cgi?id=19014 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- I think this has something to do with intrinsics. --
[Issue 19014] New: Compiler imports symbols that aren't actually imported.
https://issues.dlang.org/show_bug.cgi?id=19014
Issue ID: 19014
Summary: Compiler imports symbols that aren't actually
imported.
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: slavo5...@yahoo.com
The following code works as expected:
--- Example 1
void main()
{
if (true)
{
static import core.stdc.math;
}
static assert(!__traits(compiles, core.stdc.math.cos(0)));
}
---
The following code does not work as expected:
--- Example 2
import core.stdc.config;
void main()
{
if (true)
{
static import core.stdc.math;
}
static assert(!__traits(compiles, core.stdc.math.cos(0)));
}
---
When importing `core.stdc.config` it also appears to import `core.stdc.math`
although `core.stdc.config` does not import anything.
--
[Issue 19013] New: Allocation of array that has indirections makes incorrect assumption about zeroing
https://issues.dlang.org/show_bug.cgi?id=19013 Issue ID: 19013 Summary: Allocation of array that has indirections makes incorrect assumption about zeroing Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: minor Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: schvei...@yahoo.com I'm not sure this is super-relevant, but when allocating a block for storing array elements with indirections, the GC zeroes out what it thinks are the bytes that are not going to be used in the allocation. However, the array runtime is clever and allocates enough space to hold the elements plus the array length. For small blocks, the way the array length works, it's stored at the end of the block. This means that for example, a 16-byte block, one byte is requested for length. If you are allocating 8 bytes, this means you request 9 bytes. To the GC, this means it needs to zero the last 7 bytes. If we assume the bit-pattern for the garbage is 0xff, we have the following progression (in groups of 4 bytes ff_ff_ff_ff ff_ff_ff_ff ff_ff_ff_ff ff_ff_ff_ff // block data originally ff_ff_ff_ff ff_ff_ff_ff ff_00_00_00 00_00_00_00 // GC initializes "unused" data 00_00_00_00 00_00_00_00 ff_00_00_00 00_00_00_00 // runtime initializes array data 00_00_00_00 00_00_00_00 ff_00_00_00 00_00_00_08 // runtime sets "used" length to 8 So that weird ff pattern in the middle is an artifact of this procedure. How much will this affect the GC? Probably not a lot. First, the number of bytes that are "garbage" is going to be 1 or 2 bytes. This covers all block sizes up to 2048 bytes. In the cases of 4096 bytes or larger, the array length is a size_t, and is stored at the front, so there should be no garbage. Only 1 or 2 bytes could have an effect, but likely very small as it will be combined with other 0 bytes around it. On little endian systems, they will likely be the least significant bytes, so they probably will point at non-GC memory. But there is still a chance of odd things happening here. I wanted to file this bug to ensure that the behavior is documented. --
[Issue 18984] Debugging stack struct's which are returned causes incorrect debuginfo.
https://issues.dlang.org/show_bug.cgi?id=18984 --- Comment #6 from Manu --- > but I have not been able to > get RVO from C++ to see what happens there. I think if you build with C++14 (RVO guaranteed) and std::move the result to return value you should be able to force it. Copy elision is all bundled up in move semantics. --
[Issue 19009] core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc`
https://issues.dlang.org/show_bug.cgi?id=19009 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/druntime https://github.com/dlang/druntime/commit/4f5b049559d69c9c696c6534302ecbcff30126d5 Fix Issue 19009 - core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc` https://github.com/dlang/druntime/commit/753239f81180bee1bbd62cdbaaa7d2564fee3f3f Merge pull request #2228 from n8sh/hash-nogc Fix Issue 19009 - core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc` merged-on-behalf-of: Steven Schveighoffer --
[Issue 19009] core.internal.hash.hashOf default hash (absent `toHash`) should be `@nogc`
https://issues.dlang.org/show_bug.cgi?id=19009 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19012] New: `scoped` crashes when instantiating an object with `alias this`
https://issues.dlang.org/show_bug.cgi?id=19012
Issue ID: 19012
Summary: `scoped` crashes when instantiating an object with
`alias this`
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: major
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: hauzer...@gmail.com
Steps to reproduce: Run https://run.dlang.io/is/etSXLW
Actual results: Crashes with SIGSEGV.
Expected results: Program runs successfully.
Build: DMD64 D Compiler v2.080.1-dirty on Arch Linux 4.17.2-1-zen x86_64
I see that in #5115 Dmitry Olshansky says that `scoped` is basically a failure
and should be officially deprecated in favor of `scope`. Is that true? Note
that I'm a D newbie, so I'm treading on very new ground here.
Code from the link above, for completeness:
import std.typecons;
class A {
int a;
alias a this;
this(const int a) {
this.a = a;
}
}
void main() {
auto a = scoped!A(0);
}
--
[Issue 19010] new fails on dynamic array aliases
https://issues.dlang.org/show_bug.cgi?id=19010 Basile B. changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #2 from Basile B. --- Grammartically it's valid (it's the first new rule, i.e `new AllocatorArgumentsopt Type`) but since `new` for arrays doesn't return a pointer to an array, allowing this would be a bit pointless because `int[] a = new int[];` would be the same as `int[] a;` --
[Issue 19010] new fails on dynamic array aliases
https://issues.dlang.org/show_bug.cgi?id=19010
ag0aep6g changed:
What|Removed |Added
CC||ag0ae...@gmail.com
--- Comment #1 from ag0aep6g ---
The alias has nothing to do with the error. This gives the same error:
unittest {
int[] t = new int[]; /* Error: new can only create structs, dynamic arrays
or class objects, not int[]'s */
}
(In reply to elpenguino+D from comment #0)
> This doesn't seem to have ever compiled correctly.
As far as I know, `new int[]` is not supposed to compile. The spec [1] is a bit
scarce on this, but `new`ing arrays is only mentioned with explicit lengths.
[1] https://dlang.org/spec/expression.html#new_expressions
--
[Issue 12444] std.array uninitializedArray & minimallyInitializedArray missing APPENDABLE attribute / capacity info
https://issues.dlang.org/show_bug.cgi?id=12444 Steven Schveighoffer changed: What|Removed |Added Status|REOPENED|RESOLVED CC||schvei...@yahoo.com Resolution|--- |DUPLICATE --- Comment #3 from Steven Schveighoffer --- Fixed as a side-effect of issue 18995. std.array.array also had the problem that it wasn't calling the destructors. The solution is to make uninitializedArray use the druntime equivalent function (which sets up all the right bits and the finalizers, including APPENDABLE). *** This issue has been marked as a duplicate of issue 18995 *** --
[Issue 18995] std.array.array doesn't free elements
https://issues.dlang.org/show_bug.cgi?id=18995 Steven Schveighoffer changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #4 from Steven Schveighoffer --- *** Issue 12444 has been marked as a duplicate of this issue. *** --
[Issue 18439] Error: cannot use operator ~= in @nogc delegate 'main.test.__lambda1'
https://issues.dlang.org/show_bug.cgi?id=18439 David Bennett changed: What|Removed |Added CC||davidbenn...@bravevision.co ||m --- Comment #3 from David Bennett --- Just ran into this myself and was going to file an issue but you beat me to it. --
[Issue 18985] bad error message for += operation on shared Object
https://issues.dlang.org/show_bug.cgi?id=18985 --- Comment #6 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/ff23072e11750a83da1078705a16f7d160e793d9 Fix Issue 18985 - bad error message for += operation on shared Object https://github.com/dlang/dmd/commit/f6a4a949d24e3174149069c855d67f52fb31c71c Merge pull request #8360 from RazvanN7/Issue_18985 Fix Issue 18985 - bad error message for += operation on shared Object --
[Issue 18985] bad error message for += operation on shared Object
https://issues.dlang.org/show_bug.cgi?id=18985 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
