[Issue 19666] Compiler executes illegal instruction casting array to struct pointer
https://issues.dlang.org/show_bug.cgi?id=19666 ag0aep6g changed: What|Removed |Added Keywords||ice CC||ag0ae...@gmail.com --
[Issue 19667] New: .offsetof cannot be used on non-public members of aggregates in different modules
https://issues.dlang.org/show_bug.cgi?id=19667
Issue ID: 19667
Summary: .offsetof cannot be used on non-public members of
aggregates in different modules
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: flybo...@gmail.com
Consider the following code:
module mod1;
public struct S {
public int publicField;
private int privateField;
}
-
module mod2;
import mod1;
void main() {
import std.conv : to;
import std.stdio : writeln;
writeln(to!string(S.publicField.offsetof)); //OK
writeln(to!string(S.privateField.offsetof)); //Compiler error
}
This means that is impossible to correctly map the memory layout a given
aggregate from outside of the implementing module using only .offsetof.
I am aware that .tupleof can be used to bypass the protection checks, but using
.tupleof is a hack. Why can .tupleof bypass the checks, but not .offsetof?
--
[Issue 19665] Package modules are meaningless
https://issues.dlang.org/show_bug.cgi?id=19665 --- Comment #5 from Vladimir Panteleev --- (In reply to Adam D. Ruppe from comment #4) > It does bug me that it is inconsistent with other modules though: in no > other case does the filename matter (aside from automatic lookups). You are > allowed to have blargh.d with module whatever.you.want;. So why must this > one special case require the package.d filename? Personally, I always considered that mismatching module and file names was just the implementation being overly permissive. It only works with certain build systems and breaks a number of other assumptions for various tooling, so I'm happy to write that off in the "it works but don't do that" category. --
[Issue 19665] Package modules are meaningless
https://issues.dlang.org/show_bug.cgi?id=19665 Adam D. Ruppe changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #4 from Adam D. Ruppe --- It does bug me that it is inconsistent with other modules though: in no other case does the filename matter (aside from automatic lookups). You are allowed to have blargh.d with module whatever.you.want;. So why must this one special case require the package.d filename? but meh, it isn't a bug as it is working as designed. --
[Issue 19665] Package modules are meaningless
https://issues.dlang.org/show_bug.cgi?id=19665 Vladimir Panteleev changed: What|Removed |Added Status|NEW |RESOLVED CC||dlang-bugzilla@thecybershad ||ow.net Resolution|--- |INVALID --- Comment #3 from Vladimir Panteleev --- Not a bug in any D code. Language changes are done via DIPs. You may want to review the discussions for the feature back when it was introduced for clarification on why this feature was designed the way it is. --
[Issue 19666] New: Compiler executes illegal instruction casting array to struct pointer
https://issues.dlang.org/show_bug.cgi?id=19666
Issue ID: 19666
Summary: Compiler executes illegal instruction casting array to
struct pointer
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: andy.pj.han...@gmail.com
```
struct StoreAny {
enum size_t maxSize = (void*).sizeof;
enum size_t maxAlign = (void*).alignof;
align(maxAlign) ubyte[maxSize] store;
@trusted this(T)(T value) {
static assert(T.sizeof <= maxSize && T.alignof <= maxAlign);
*(cast(T*) store) = value;
}
@trusted T as(T)() {
return *(cast(T*) store);
}
}
struct SomeStruct { int x; }
enum StoreAny someEnum = StoreAny(SomeStruct());
void main() {
}
```
Compiling this code causes the compiler to terminate with SIGILL.
There is no error if I instantiate with a primitive, e.g. `StoreAny(0)`.
--
[Issue 19665] Package modules are meaningless
https://issues.dlang.org/show_bug.cgi?id=19665 --- Comment #2 from Victor Porton --- Deprecating, not invalidating. > What's the advantage of > > > foo.d > foo/a.d > > Over > > foo/package.d > foo/a.d The advantage is cleaner idea that it is package foo (and also decreasing the number of path components). --
[Issue 19665] Package modules are meaningless
https://issues.dlang.org/show_bug.cgi?id=19665 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #1 from Seb --- I'm not sure I understand the advantage of deprecating a lot of code about a naming issue. What's the advantage of foo.d foo/a.d Over foo/package.d foo/a.d ? --
[Issue 19665] New: Package modules are meaningless
https://issues.dlang.org/show_bug.cgi?id=19665 Issue ID: 19665 Summary: Package modules are meaningless Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: por...@narod.ru It seems for me a meaningless feature, package modules. Instead of libweb/package.d we could equally well use just libweb.d (without then disallowing as now libweb/ subpackages). Maybe we should reconsider and deprecate package modules, in regard to simply modules having the package name as the name? --
[Issue 19618] Incorrect conversion of function returning `typeof(null)` to function returning an associative array
https://issues.dlang.org/show_bug.cgi?id=19618 Iain Buclaw changed: What|Removed |Added CC||ibuc...@gdcproject.org --- Comment #1 from Iain Buclaw --- It seems that the got auto-resolved without linking a reference to the PR nor commit. https://github.com/dlang/dmd/pull/9272 --
[Issue 16216] struct equality compares padding
https://issues.dlang.org/show_bug.cgi?id=16216 --- Comment #3 from ag0aep6g --- (In reply to Walter Bright from comment #1) > The PR does not affect the `is` comparisons. I'm not sure yet if it should. I think we're good with regards to `is`. The spec says: "For struct objects [...], identity is defined as the bits in the operands being identical." The padding is part of "the bits", so including it in the comparison is correct. I don't know why I thought `is` should behave differently. Maybe I had missed that sentence in the spec. (In reply to Walter Bright from comment #2) > Now fixed for the == and != case. I'm not a fan of calling this "fixed" when it needs a special compiler switch. --
[Issue 19664] New: All tools should be built for 64 bit
https://issues.dlang.org/show_bug.cgi?id=19664 Issue ID: 19664 Summary: All tools should be built for 64 bit Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: enhancement Priority: P1 Component: tools Assignee: nob...@puremagic.com Reporter: d...@me.com All tools shipped with a DMD release should be built for the same architecture. For a 64 bit release, the following tools are built for 32 bit: "dumpobj", "obj2asm" and "shell". This is extra important for macOS since Mojave is the last release where 32 bit applications will work and with DMD 2.085.0 we have deprecated the support for 32 bit on macOS. --
