[Issue 19196] DMD thinks storage size for pointer or dynamic array isn't always known
https://issues.dlang.org/show_bug.cgi?id=19196
| changed:
What|Removed |Added
CC||dhase...@gmail.com
--- Comment #2 from | ---
Reduced testcase that doesn't rely on phobos:
---
struct Foo(T)
{
alias F = typeof(T.tupleof);
}
struct B
{
// Error: struct `test.A` no size because of forward reference
Foo!(B)[] arr;
}
---
In typesem.d:3495, we call `mt.sym.size(e.loc);`. We use it as a shortcut to
run semantic analysis on the type before getting the type tuple. This results
in a bad error message, but it's straightforward to improve that error message.
Obviously, some stuff won't fly, so we can't glibly leave everything to a later
semantic step. The fix required to make this work fully is to run minimal
semantic analysis during tupleof, lazily finish that semantic analysis, and
only error out then.
That would catch the obvious problem of:
---
struct Foo
{
static if (!hasElaborateDestructor!B) ~this() {}
}
struct B
{
Foo foo;
}
---
But would let the original example compile.
Unfortunately, that level of change is beyond me at the moment.
--
[Issue 19193] deprecated attribute on enum members in templates is ignored
https://issues.dlang.org/show_bug.cgi?id=19193 Mike Franklin changed: What|Removed |Added Keywords||pull CC||slavo5...@yahoo.com --- Comment #1 from Mike Franklin --- Attempted fix: https://github.com/dlang/dmd/pull/8621 --
[Issue 19196] DMD thinks storage size for pointer or dynamic array isn't always known
https://issues.dlang.org/show_bug.cgi?id=19196 Abscissa changed: What|Removed |Added Summary|DMD thinks storage size for |DMD thinks storage size for |pointer or dynamic array is |pointer or dynamic array |unknown |isn't always known --
[Issue 340] [Tracker] Forward reference bugs and other order-of-declaration issues
https://issues.dlang.org/show_bug.cgi?id=340 Abscissa changed: What|Removed |Added Depends on||19196 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=19196 [Issue 19196] DMD thinks storage size for pointer or dynamic array is unknown --
[Issue 19105] Bogus recursive template expansion via getSymbolsByUDA
https://issues.dlang.org/show_bug.cgi?id=19105 Abscissa changed: What|Removed |Added Blocks||340 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=340 [Issue 340] [Tracker] Forward reference bugs and other order-of-declaration issues --
[Issue 340] [Tracker] Forward reference bugs and other order-of-declaration issues
https://issues.dlang.org/show_bug.cgi?id=340 Abscissa changed: What|Removed |Added Depends on||19105 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=19105 [Issue 19105] Bogus recursive template expansion via getSymbolsByUDA --
[Issue 19196] DMD thinks storage size for pointer or dynamic array is unknown
https://issues.dlang.org/show_bug.cgi?id=19196 Abscissa changed: What|Removed |Added Blocks||340 Referenced Issues: https://issues.dlang.org/show_bug.cgi?id=340 [Issue 340] [Tracker] Forward reference bugs and other order-of-declaration issues --
[Issue 19196] DMD thinks storage size for pointer or dynamic array is unknown
https://issues.dlang.org/show_bug.cgi?id=19196 Abscissa changed: What|Removed |Added Summary|DMD thinks storage size of |DMD thinks storage size for |dynamic array is unknown|pointer or dynamic array is ||unknown --- Comment #1 from Abscissa --- Same result if "Foo!(A)[]" is changed to "Foo!(A)*" --
[Issue 19196] New: DMD thinks storage size of dynamic array is unknown
https://issues.dlang.org/show_bug.cgi?id=19196
Issue ID: 19196
Summary: DMD thinks storage size of dynamic array is unknown
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: bus_dlangzi...@semitwist.com
struct Foo(T)
{
import std.traits: hasElaborateDestructor;
static if(hasElaborateDestructor!A) {}
}
struct A
{
B b;
}
struct B
{
// Error: struct `test.A` no size because of forward reference
Foo!(A)[] arr;
}
--
[Issue 19134] [C++] static const y = new Derived(); ->pointer cast from const(Derived) to immutable(void*)** is not supported at compile time
https://issues.dlang.org/show_bug.cgi?id=19134 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19058] __traits(getUnitTests) stops working with separate compilation in dmd 2.081.0
https://issues.dlang.org/show_bug.cgi?id=19058 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 19058] __traits(getUnitTests) stops working with separate compilation in dmd 2.081.0
https://issues.dlang.org/show_bug.cgi?id=19058 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/3a686c04cd777d89cf9343ab39dacd600934ffcb Fix issue 19058 - __traits(getUnitTests) works again with separate compilation https://github.com/dlang/dmd/commit/758c5ac13c1687ff5c8722eeb7bce86eb7f1c3b5 Merge pull request #8542 from atilaneves/fix-traits-get-unittest Fix issue 19058 - __traits(getUnitTests) works again with separate co… --
[Issue 19134] [C++] static const y = new Derived(); ->pointer cast from const(Derived) to immutable(void*)** is not supported at compile time
https://issues.dlang.org/show_bug.cgi?id=19134 --- Comment #4 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/b952c845f77264d40253e2e144625fdb0c301804 Fix Issue 19134 And revert to D vptr semantics in constructors of extern(C++) classes, i.e., call the most derived override in base constructors. 2.081 introduced a breaking change here, using the most derived override before the super() call and the current class' afterwards. The proper mid-term solution is probably to emit fully C++-compatible constructors for extern(C++) classes, calling the super ctor right at the start and then blitting vptr and class-specific fields from the init symbol. extern(C++) classes (and structs) should get an implicit default ctor (only if there's no other ctor in the class case). extern(C++) classes could then be allocated and properly constructed via C++ `new`; struct declarations in C++ headers for extern(C++) structs wouldn't need to duplicate the field initializers and could simply declare the default ctor (emitted by the D compiler and blitting the init symbol). https://github.com/dlang/dmd/commit/50833f0a98df9ac1f1c78db4dd24743aad300539 Merge pull request #8533 from kinke/fix19134 [stable] Fix Issue 19134 - [C++] static const y = new Derived(); ->pointer cast from const(Derived) to immutable(void*)** is not supported at compile time merged-on-behalf-of: Rainer Schuetze --
[Issue 19195] New: Support pragma to specify linker directives
https://issues.dlang.org/show_bug.cgi?id=19195 Issue ID: 19195 Summary: Support pragma to specify linker directives Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com MSVC emits a bunch of "/FAILIFMISMATCH:" directives to object files. These express the state of various conditions during compilation, and guard against incorrect linking. Please add a pragma to emit these to object files in the same way as pragma(lib, ) does for the "/DEFAULTLIB:" directive. Perhaps a general `pragma(linkdirective, "text")` could be added to support raw directives as required, and future-proof against this class of problem. For example: pragma(linkdirective, "/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2"); May appear in a source file under a version() where struct's are specified accordingly to match such configuration of the MSCRT. --
[Issue 19194] New: version for `-mscrtlib` specification
https://issues.dlang.org/show_bug.cgi?id=19194 Issue ID: 19194 Summary: version for `-mscrtlib` specification Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com The MSCRT libs have data structures appearing in the ABI which are defined differently for each build of the lib. Please create a builtin version which is defined for each selection of `-mscrtlib` so code can detect and match the data structures from the lib. *** Splitting https://issues.dlang.org/show_bug.cgi?id=18999 for simplicity --
[Issue 19193] New: deprecated attribute on enum members in templates is ignored
https://issues.dlang.org/show_bug.cgi?id=19193
Issue ID: 19193
Summary: deprecated attribute on enum members in templates is
ignored
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: elpenguin...@gmail.com
```
void main() {
cast(void)X!int.A.b;
}
template X(T) {
enum A {
deprecated b
}
}
```
Compiles with no complaint. Should issue a deprecation message.
Issue exists in DMD 2.082.0 beta.
--
[Issue 19175] @safe code can escape local array references
https://issues.dlang.org/show_bug.cgi?id=19175 Radu Racariu changed: What|Removed |Added CC||radu.raca...@gmail.com --- Comment #5 from Radu Racariu --- Under dip1000, what I think is that slicing a static array should always be considered scope. Also, calling a functions with a scope slice with the parameter for the slice not annotated as scope should result in an error if the compiler can't prove that the parameter can't escape. --
[Issue 11959] Phobos should not declare public symbols in version(unittest) blocks
https://issues.dlang.org/show_bug.cgi?id=11959 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/db819575f13b6de9a726e74e3ce29aaa0be1b361 Fix issue 11959 - Set private symbols declared in version(unittest) blocks https://github.com/dlang/phobos/commit/dc40232b6074e53c13aa47e1ef4d0b5990745fc5 Merge pull request #6681 from BBasile/pub-symbol-unittest Fix issue 11959 - Set private symbols declared in version(unittest) blocks merged-on-behalf-of: Petar Kirov --
[Issue 11959] Phobos should not declare public symbols in version(unittest) blocks
https://issues.dlang.org/show_bug.cgi?id=11959 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 11431] std.file.slurp fails with Windows newlines
https://issues.dlang.org/show_bug.cgi?id=11431 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 11431] std.file.slurp fails with Windows newlines
https://issues.dlang.org/show_bug.cgi?id=11431 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9ca114d141bf0c8cdf949b10b7396653d649de6e fix issue 11431 - std.file.slurp fails with Windows newlines https://github.com/dlang/phobos/commit/f4c6d5c25e61684594036c2f959d70dcef325365 Merge pull request #6680 from BBasile/issue-11431 fix issue 11431 - std.file.slurp fails with Windows newlines merged-on-behalf-of: Vladimir Panteleev --
[Issue 19148] Alignment of section does not reflect the maximum alignment of its contents
https://issues.dlang.org/show_bug.cgi?id=19148 --- Comment #9 from Yuxuan Shui --- (In reply to Joakim from comment #8) > OK, if you're so sure it's a problem in dmd's backend, a pull request is > welcome. While I know where the problem is, I don't know what is the proper fix. So I would need some help. --
[Issue 19192] New: DMD generates invalid code for covariants involving template classes
https://issues.dlang.org/show_bug.cgi?id=19192
Issue ID: 19192
Summary: DMD generates invalid code for covariants involving
template classes
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: blocker
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: pun...@coverify.org
tested with DMD 2.081.2 and with LDC 1.10
$ rdmd covariant.d
[]
$ rdmd -version=COVARIANT covariant.d
[1635151715, 1851877746, 1631727220, 1965564274, 1735290732, 774462811,
7496002, 0, 4802768, 0, 4492600, 0, 4492620, 0, 4492632, 0, 4492772, 0,
4448724, 0, 4448744, 0, 0, 0, 4505724, 0, 0]
core.exception.AssertError@covariant.d(55): Assertion failure
// covariant.d
interface Foo {
int[] vars();
Foo troll();
}
class Frop: Foo {
int[] vars() {
assert(false);
}
Foo troll() {
assert(false);
}
}
abstract class Barbee : Foo {}
class Bar(V): Barbee {
Barber!(V) _barber;
this(Barber!(V) barber) {
_barber = barber;
}
int[] vars() {
return _barber.vars;
}
version (COVARIANT) alias COVARTYPE = typeof(this);
else alias COVARTYPE = Foo;
COVARTYPE troll() {
return _barber.troll()[0];
}
}
class Barber(V) {
Bar!(V)[] _elems;
int[] vars() {
return [];
}
auto troll() {
return this;
}
void build(size_t v) {
_elems.length = v;
for (size_t i; i!=v; ++i) _elems[i] = new Bar!(V)(this);
}
Bar!(V) opIndex(Foo indx) {
return new Bar!(V)(this);
}
Bar!(V) opIndex(size_t n) {
build(n+1);
return _elems[n];
}
}
void main() {
import std.stdio;
auto barber = new Barber!(ulong[])();
auto frop = new Frop();
Foo foo = barber[frop];
Foo fool = foo.troll();
auto ll = fool.vars; writeln(ll);
assert (ll.length == 0);
}
--
[Issue 15732] std.function partial does not work with function / delegate references
https://issues.dlang.org/show_bug.cgi?id=15732 Johannes Loher changed: What|Removed |Added Status|NEW |RESOLVED CC||johannes.lo...@fg4f.de Resolution|--- |FIXED --- Comment #4 from Johannes Loher --- It seems, this was not actually closed. Closing it now. --
[Issue 18755] std.typecons.Rebindable breaks @safe-ty
https://issues.dlang.org/show_bug.cgi?id=18755
Johannes Loher changed:
What|Removed |Added
CC||johannes.lo...@fg4f.de
--- Comment #1 from Johannes Loher ---
This also applies to std.typecons.UnqualRef because they use the same
implementation which is responsible for this:
---
class Foo {
auto opCast(T)() @system immutable pure nothrow {
*(cast(uint*)0xdeadbeef) = 0xcafebabe;
return T.init;
}
}
void main() @safe {
import std.typecons;
auto r = UnqualRef!(immutable Foo)(new Foo); // oops
}
---
The reason for the breakage is that they both implement this opAssign, which
gets called by the constructor:
---
void opAssign(T another) @trusted pure nothrow @nogc
{
stripped = cast(U) another;
}
---
Notice how this performs the cast in an @trusted context.
The problem with this is that we actually need to do this, because casting is
not @safe, but in this case we are only casting away immutability etc. which is
actually verified manually to be safe in this case.
To get around this, we would need to check, if there is a user defined opCast
and if it is provided, check if is safe. If it is not safe, we can either
decide to not instanciate Rebindable / UnqualRef, or we can instanciate
versions of them, which are not @safe (i.e. we omit the @trusted attributes at
the corresponding places).
What do you think would be the correct thing to do in this case?
Here is a basic implementation, which does the necessary checks:
---
template hasElaborateCast(T)
{
import std.traits : hasMember;
enum hasElaborateCast = hasMember!(T, "opCast");
}
template hasSafeElaborateCast(T, U)
{
enum hasSafeElaborateCast = hasElaborateCast!T && __traits(compiles, ()
@safe{ T.init.opCast!U; });
}
private mixin template RebindableCommon(T, U, alias This)
if ((is(T == class) || is(T == interface) || isAssociativeArray!T) &&
(!hasElaborateCast!T || hasSafeElaborateCast!(T, U)))
/* ... */
---
In this case, I put in as a template constraint, but as mentioned, we could
also put it in static ifs to decide whether the implementation should be
@trusted or not.
--
