[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #9 from Eyal  ---
> Or functioning as designed, just not properly documented.

> This part of TypeInfo is meant to be used internally. I don't think this 
> corner case warrants a compiler change, as the current state is completely 
> usable.

Not by Weka or by Andrei Alexandrescu, apparently, as both inserted terrible
bugs into production code with this.

Do you think a warning in the manual would have prevented these bugs? Do you
doubt that the next usages of this function will create similar bugs?

> Every time we change the compiler, it may break other things. I don't think 
> it's worth the risk for such a small improvement. Not to mention it will 
> bloat all object files. Why break things for the vast majority of people when 
> the fix is simple for those who have been misled by the incomplete docs?

Note the "fix" I am requesting does not require bloating the object files. A
compile-time error about use of the "init" value of a static array's typed id
is enough.  Generating a special TypeInfo object for static arrays doesn't
sound like rocket science.


Claiming the interface should be terrible to simplify the implementation is
classic worse-is-better, and I think D aspires to be truly better.

--

[Issue 16319] std.experimental.allocator.make subtly wrong with nested classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16319

--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/b96a330b77d2c947c7c9f50e9d954b31cdf3c82e
fix issue 16319

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #8 from Steven Schveighoffer  ---
(In reply to ag0aep6g from comment #7)
> I.e., it's a long-standing bug.

Or functioning as designed, just not properly documented.

> Pretty much every bug fix can be considered a breaking change. I don't think
> we need to live with this, just because someone may be relying on behavior
> that's clearly going against documentation.

This part of TypeInfo is meant to be used internally. I don't think this corner
case warrants a compiler change, as the current state is completely usable.

> If they don't use it, their code won't get broken by the fix.

Every time we change the compiler, it may break other things. I don't think
it's worth the risk for such a small improvement. Not to mention it will bloat
all object files. Why break things for the vast majority of people when the fix
is simple for those who have been misled by the incomplete docs?

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #7 from ag0ae...@gmail.com ---
(In reply to Steven Schveighoffer from comment #6)
> I mean it's a doc issue in that the documentation doesn't reflect what
> initializer() actually does (and has always done).

I.e., it's a long-standing bug.

> There isn't much to say
> except that I don't think we can change the behavior at this point without
> breaking things.

Pretty much every bug fix can be considered a breaking change. I don't think we
need to live with this, just because someone may be relying on behavior that's
clearly going against documentation.

> It's been this way since 2009, so most people don't use it or care about it,
> or they would have hit this issue before.

If they don't use it, their code won't get broken by the fix.

> I realize we can't get your time
> back looking for this issue, but I think at this point, the best thing to do
> is fix the docs and fix any code that was done using this incorrect
> assumption.

I disagree. I think fixing the code to behave as documented is the way to go.

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #6 from Steven Schveighoffer  ---
I mean it's a doc issue in that the documentation doesn't reflect what
initializer() actually does (and has always done). There isn't much to say
except that I don't think we can change the behavior at this point without
breaking things.

It's been this way since 2009, so most people don't use it or care about it, or
they would have hit this issue before. I realize we can't get your time back
looking for this issue, but I think at this point, the best thing to do is fix
the docs and fix any code that was done using this incorrect assumption.

(In reply to Eyal from comment #5) 

> The reason is that this kind of assignment always goes through a stack
> allocation. When x.init is a large value, it unnecessarily allocates a huge
> chunk of stack. Our stacks are of limited size (fibers). This explodes.

I think this is a legitimate improvement to suggest.

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #5 from Eyal  ---
I disagree, a function which has subtle corner cases that cause cryptic bugs is
never a "documentation issue". Maybe if it were called "unsafe_init_val" --
you'd know that documentation is crucial here. Otherwise you go on your merry
way until you explode.

I've seen only 2 uses of the init value on generic types, in our production
code and in std.lib.algorithm:initailizeAll.  *Both of these cases* had
cryptic, terrible bugs due to this behavior of typeid(T).init!  If D's standard
library can't get the use of typeid().init right, is it a legitimate function
to expose?

> > Additionally, x = x.init  would work without blowing up the stack when x is
> > large, and then accessing typeid() would be unnecessary.

> I'm not sure what this means.

The only reason we need to use typeid(x).init() is because we cannot really do:

  x = x.init; 

The reason is that this kind of assignment always goes through a stack
allocation. When x.init is a large value, it unnecessarily allocates a huge
chunk of stack. Our stacks are of limited size (fibers). This explodes.

So we work around it using typeid(x).init() and explicit memory copies (similar
to what initializeAll does).

If the compiler had properly implemented x = x.init without superfluous huge
stack allocations, we'd have no trouble because we wouldn't need to use
typeid().init() in the first place (though perhaps this is an LDC-specific
problem)

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #4 from Steven Schveighoffer  ---
typeid(T).initializer is not meant to be used without understanding what it
does in all cases. There are other subtle issues with it.

I think this is just a documentation issue. I can see where this would cause
problems :(

(In reply to Eyal from comment #3)
> Additionally, x = x.init  would work without blowing up the stack when x is
> large, and then accessing typeid() would be unnecessary.

I'm not sure what this means.

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #3 from Eyal  ---
The workaround is pretty clear.

But this is nasty! Anyone who uses typeid(T).init in a generic way (not caring
what T is) is going to be broken.

It would be better to have typeid(staticArr).init throw a compile-time error
than to return the wrong result.

We've spent many hours reproducing and chasing this bug in a production build.

Additionally, x = x.init  would work without blowing up the stack when x is
large, and then accessing typeid() would be unnecessary.

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #2 from Steven Schveighoffer  ---
It has been this way since the beginning (traced it back to this commit:
https://github.com/dlang/druntime/commit/1532910c769ab718a528c94c9157fecebd753c66)

Looking at the code, there really isn't a way to fix it without altering the
Object API or the compiler, both of which would break a lot of things.

We could have the compiler store the entire static array data into the data
section. This seems wasteful to say the least.

Is there not a way to handle TypeInfo_StaticArray specially? As far as I know,
it's going to be the only type that behaves this way.

Alternatively, you can check tsize() to see what the real size should be, and
then if that doesn't match initializer().length (use initializer instead of
init(), as init() is deprecated), then replicate if your plan is to initialize
to the initializer value.

--

[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #1 from Eyal  ---
As a result, std.algorithm:initializeAll is also buggy:

import std.stdio;
unittest {
struct Int {
~this() {}
int x = 3;
}
import std.algorithm : initializeAll;
Int[2] xs = [Int(1), Int(2)];
struct R {
bool done;
bool empty() { return done; }
ref Int[2] front() { return xs; }
void popFront() { done = true; }
}
writeln(xs);
initializeAll(R());
writeln(xs);
}

Prints out:
[Int(1, 7FE7FED92000), Int(2, 7FE7FED92000)]
[Int(3, null), Int(0, 73)]

The second field being printed for Int seems like *yet another* bug.

--

[Issue 14740] __traits(allMembers) returns erroneous 'this' member for types declared in functions.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14740

Max Alibaev  changed:

   What|Removed |Added

 CC||o...@ololo.im

--

[Issue 16387] getSymbolsByUDA works with structs but fails with classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16387

gruen_tob...@web.de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|nob...@puremagic.com|gruen_tob...@web.de

--

[Issue 16387] getSymbolsByUDA works with structs but fails with classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16387

gruen_tob...@web.de changed:

   What|Removed |Added

   Assignee|gruen_tob...@web.de |nob...@puremagic.com

--

[Issue 16394] New: TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

  Issue ID: 16394
   Summary: TypeInfo.init() for static arrays returns single
element instead of whole array
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: e...@weka.io

unittest {
void prop(T)() {
assert(T.sizeof == typeid(T).tsize, "typeid(" ~ T.stringof ~ ").tsize
broken");
assert(T.sizeof == typeid(T).init().length, "typeid(" ~ T.stringof ~
").init broken");
}
prop!int;
prop!(int[3]);
}

Crashes for the 4th assertion, because init() returns a void[] array of size 4
instead of 12.

--

[Issue 16392] drop win32.mak

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16392

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--- Comment #1 from Lodovico Giaretta  ---
(In reply to greensunny12 from comment #0)
> 2) just drop win32.mak (windows 10 includes a full ubuntu bash anyways)

I don't think this is really an option. Windows 10 bash produces posix
executables, not windows ones. So it is only ok if posix.mak can be used to
cross-compile for windows. Even if that is the case, the Windows 10 bash
currently has some limitations that make it not production-ready.

--

[Issue 16393] New: Move install.sh to a more stable machine

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16393

  Issue ID: 16393
   Summary: Move install.sh to a more stable machine
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

Idk whats wrong with Jan's FreeBSD setup, but we still get many broken builds:

e.g.: https://travis-ci.org/dlang/dmd/jobs/152411758

$ for i in {0..4}; do curl -fsS -A "$CURL_USER_AGENT" --max-time 5
https://dlang.org/install.sh -O && break || [ $i -ge 4 ] || sleep $((1 << $i));
done
curl: (7) couldn't connect to host
curl: (7) couldn't connect to host
curl: (7) couldn't connect to host
curl: (7) couldn't connect to host
curl: (7) couldn't connect to host

--

[Issue 16387] getSymbolsByUDA works with structs but fails with classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16387

gruen_tob...@web.de changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|gruen_tob...@web.de

--

[Issue 16387] getSymbolsByUDA works with structs but fails with classes

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16387

gruen_tob...@web.de changed:

   What|Removed |Added

 CC||gruen_tob...@web.de

--- Comment #1 from gruen_tob...@web.de ---
Somehow related to Issue 14740. 

The problem is that MyClass is inside a function, and therefore will get a
additional "this" member. The "this" member is inaccsessible, so if the library
tries to search attribtues it will fail at this "this" member.

--

[Issue 16390] __traits not accepted where a type is expected

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16390

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #4 from Jonathan M Davis  ---
Similarly,

template members(T)
{
alias members = __traits(allMembers, T);
}

doesn't work, whereas

template members(T)
{
alias members = AliasSeq!(__traits(allMembers, T));
}

does. And that's even more bizarre when you consider not only that AliasSeq is
supposed to be equivalent to the "tuple" that the compiler uses for stuff like
the result of __traits(allMembers, T), but this code

import std.meta;

template members(T)
{
alias members = AliasSeq!(__traits(allMembers, T));
}

struct S
{
int i;
string s;
}

void main()
{
pragma(msg, __traits(allMembers, S));
pragma(msg, AliasSeq!(__traits(allMembers, S)));
pragma(msg, members!S);
}

prints

tuple("i", "s")
tuple("i", "s")
tuple("i", "s")

meaning that all 3 are equivalent as far as pragma(msg, ...) is concerned. And
changing main to

pragma(msg, typeof(__traits(allMembers, S)));
pragma(msg, typeof(AliasSeq!(__traits(allMembers, S;
pragma(msg, typeof(members!S));

results in

(string, string)
(string, string)
(string, string)

So, it really seems like the fact that the result of __traits can't be aliased
is a bug. And if it's not a bug, then it's an unnecessary (and confusing)
inconsistency, and IMHO, it really should be fixed.

--

[Issue 14027] segmentation fault in dmd in some circular import situation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14027

Ali Cehreli  changed:

   What|Removed |Added

   Keywords||industry
 CC||acehr...@yahoo.com

--

[Issue 16301] CTFE execution of opApply keeps wrong "this" context in foreach's body

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16301

Ali Cehreli  changed:

   What|Removed |Added

   Keywords||industry
 CC||acehr...@yahoo.com

--

[Issue 15094] __traits(getMember) fails when the source is a struct/class field

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15094

Ali Cehreli  changed:

   What|Removed |Added

   Keywords||industry
 CC||acehr...@yahoo.com

--

[Issue 14451] static-foreach uses huge stack for no reason

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14451

Ali Cehreli  changed:

   What|Removed |Added

   Keywords||industry
 CC||acehr...@yahoo.com

--

[Issue 16390] __traits not accepted where a type is expected

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16390

--- Comment #3 from b2.t...@gmx.com ---
(In reply to Lodovico Giaretta from comment #2)
> (In reply to b2.temp from comment #1)
> If this was meant to be a workaround, it doesn't seem to work for me (the
> trait returns a type, while typeof expects an expression).
> 
> If it was meant to be another situation where __traits should be allowed but
> are not, it looks like they are currently allowed inside typeof.

Yes, second case, sorry. It clearly doesn't work with the parent __traits.

--

[Issue 16390] __traits not accepted where a type is expected

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16390

--- Comment #2 from Lodovico Giaretta  ---
(In reply to b2.temp from comment #1)
> This is really common to use typeof() on the result of a __traits()
> 
> template ParentType(T)
> {
> alias ParentType = typeof(__traits(parent, T));
> }

If this was meant to be a workaround, it doesn't seem to work for me (the trait
returns a type, while typeof expects an expression).

If it was meant to be another situation where __traits should be allowed but
are not, it looks like they are currently allowed inside typeof.

--

[Issue 16390] __traits not accepted where a type is expected

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16390

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #1 from b2.t...@gmx.com ---
This is really common to use typeof() on the result of a __traits()

template ParentType(T)
{
alias ParentType = typeof(__traits(parent, T));
}

--

[Issue 16392] New: drop win32.mak

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16392

  Issue ID: 16392
   Summary: drop win32.mak
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

AFAIK it's a huge pain to keep the win32.mak up-to-date and requires a lot of
work & resources that would be spent more wisely on important matters.
Ideas

1) use reggae (or another cross-platform buildtool) for dlang.org
2) just drop win32.mak (windows 10 includes a full ubuntu bash anyways)

--

[Issue 16389] "const" should be inferred for template methods

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16389

--- Comment #3 from Andrei Alexandrescu  ---
(In reply to greenify from comment #2)
> > Currently defining const and non-const versions of methods in generic code 
> > is redundant and error-prone.
> 
> FWIW isn't inout a solution to a similar problem? In any case inout needs
> rebranding

Deduction is different because there's no qualifier applied if the method is
never used on a const object.

--

[Issue 16389] "const" should be inferred for template methods

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16389

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #2 from greenify  ---
> Currently defining const and non-const versions of methods in generic code is 
> redundant and error-prone.

FWIW isn't inout a solution to a similar problem? In any case inout needs
rebranding

--

[Issue 16389] "const" should be inferred for template methods

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16389

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
One can do this already, though I agree it would be nice if this was the
default:

struct S
{
   int _x;
   int x(this T)() { return _x; }
}

void main()
{
   S s;
   const S cs;
   writeln(s.x, cs.x);
}

--

[Issue 16391] New: please add rt_loadLibrary/rt_unloadLibrary support for osx

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16391

  Issue ID: 16391
   Summary: please add rt_loadLibrary/rt_unloadLibrary support for
osx
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: lp...@126.com

please add rt_loadLibrary/rt_unloadLibrary support for osx

--

[Issue 14633] DDoc: false warnings for missing parameters on template declaration

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14633

Lionello Lunesu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 16388] Throwing constructors must destroy fully constructed fields

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16388

Ali Cehreli  changed:

   What|Removed |Added

 CC||acehr...@yahoo.com

--

[Issue 15907] Unjustified "is not visible from module" deprecation warning when using getMember trait

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15907

Ali Cehreli  changed:

   What|Removed |Added

   Keywords||industry

--