[Issue 11601] pragma(msg, ...) output not silenced inside is(typeof()) and __traits(compiles, ...)

[d-bugmail--- via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #2 from Simen Kjaeraas  ---
I was apparently a bit hasty in closing this. Encountered the same issue again
today, and testing the code in comment #0 again shows that its behavior has not
been fixed in 2.078.3.

--

[Issue 18546] Improvement: Implicit Class Template Instantiation

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Jonathan M Davis  ---
The normal solution is to use a factory function which can then take advantage
of IFTI. As it stands, the compiler never does any implicit template
instantations except for functions, because for templates that aren't function
templates, it's ambiguous. This particular case is a bit special in that it's
using the type, not a function, but it's also triggering the constructor, which
_is_ a function. So, I don't know. Really, what it comes down to is that some
specific cases of implicitly instantiating templated types could be made to
work, but it can't work in the general case. So, thus far, the solution has
been to simply not support it.

Related: issue #1012.

--

[Issue 18546] New: Improvement: Implicit Class Template Instantiation

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18546
   Summary: Improvement: Implicit Class Template Instantiation
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: default_357-l...@yahoo.de

Why does this not work? Should  this work?

class Foo(T) {
this(T t) { }
}

auto foo = new Foo(5);

C++ can do it...

--

[Issue 14927] GDB cannot be used to debug D programs on OS X

[d-bugmail--- via Digitalmars-d-bugs]

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

Luís Marques  changed:

   What|Removed |Added

 CC||l...@luismarques.eu

--

[Issue 18543] Comments inside string mixin silently short-circuit code

[d-bugmail--- via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan M Davis  ---
Yeah, remember that string mixins are basically like pasting code in place. So,
it's going to act like you pasted that code into your editor, and adding a
comment with // is therefore going to have exactly the same effect as it would
if you pasted code after a //, which means that it's going to be part of the
comment.

--

[Issue 18545] New: Casting away const with cast() triggers alias this, but returns the supertype anyway

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18545
   Summary: Casting away const with cast() triggers alias this,
but returns the supertype anyway
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: default_357-l...@yahoo.de

const Nullable!string a;

Nullable!string b = a; /* This works. */

Nullable!string c = cast() a; /* This asserts in get. */

// Alright, so I guess cast() mistakenly follows the alias this?

// No!

static assert(is(typeof(cast() a) == Nullable!string));

// It follows the alias get this in Nullable, but it returns a Nullable anyway.

// Why!!

--

[Issue 18544] Thread-safety of "proto" GC before initialisation

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
Hm.. actually that doesn't work, because one thread could be adding roots while
the other one is initializing the GC, causing a race.

There may just have to be some sort of lock, even if it's a simple/spin lock.

--

[Issue 18544] Thread-safety of "proto" GC before initialisation

[d-bugmail--- via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
A thought on a potential fix: once you detect ranges being added/removed from
independent threads, then you initialize the GC.

You should be able to do this with an atomic read, and then CAS to a ProtoGC
instance variable that stores the "main thread" id.

The atomic read should be negligible compared to manipulating the roots/ranges
arrays.

--

[Issue 18544] New: Thread-safety of "proto" GC before initialisation

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18544
   Summary: Thread-safety of "proto" GC before initialisation
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@klickverbot.at

https://github.com/dlang/druntime/pull/2057 was merged without thread safety
concerns being addressed.

The code needs to be checked carefully for its behaviour when several threads
are accessing the GC before the ProtoGC has been swapped out with the real
implementation
(https://github.com/dlang/druntime/pull/2057#discussion_r168910433).

If threads are created using the standard "auto t = new Thread(...); […]"
idiom, this is of course not going to be an issue, because the GC will already
have been initialised when the child thread is spawned. However, it is
conceivable that two independent C threads concurrently start to use D(runtime)
code.

--

[Issue 18543] Comments inside string mixin silently short-circuit code

[d-bugmail--- via Digitalmars-d-bugs]

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |INVALID

--

[Issue 18543] Comments inside string mixin silently short-circuit code

[d-bugmail--- via Digitalmars-d-bugs]

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

Andrea Fontana  changed:

   What|Removed |Added

 CC||trik...@gmail.com

--- Comment #1 from Andrea Fontana  ---
Just because you're mixin a single line.
Adding \n will solve the problem

import std.stdio;

void main(string[] args)
{
mixin(""
~"writeln(\"Hello\");"
~"// Some comment\n"
~"assert(0);"
);  
}

your code sounds like:

void main()
{
writeln("hello"); // Some comment assert(0)
}

--

[Issue 18543] New: Comments inside string mixin silently short-circuit code

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18543
   Summary: Comments inside string mixin silently short-circuit
code
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: edi33...@gmail.com

I have recently stumbled upon the following wrong behaviour inside string
mixins.

If you use a single line style comment (//) inside a string mixin, this will
silently short-circuit the code, leading to unexpected behaviour, as you can
see in the example bellow:

import std.stdio;

void main(string[] args)
{
mixin(""
~"writeln(\"Hello\");"
~"// Some comment"  
~"assert(0);"
);  
}

The assert will never get triggered.

If you use multi-line comments (/* */) those are correctly recognized and
everything works as expected.

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #5 from Steven Schveighoffer  ---
Note that == will shortcut and return true if the two instances are the same
object.

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
All I'm saying is that I don't think we need to enforce this. There are reasons
to use ==.

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #3 from Basile B.  ---
With this dll stuff it's hardly applicable...

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #2 from Basile B.  ---
(In reply to Steven Schveighoffer from comment #1)
> I thought in the cases of DLLs, the typeids from different object files
> could be identical, but different instances.

Nobody has said you're wrong. It's even a case where the lowering is invalid.

--

[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
I thought in the cases of DLLs, the typeids from different object files could
be identical, but different instances.

--

[Issue 1654] Array concatenation result should be implicitly castable between mutable and immutable if the elements support it.

[d-bugmail--- via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|Array concatenation should  |Array concatenation result
   |result in mutable or|should be implicitly
   |invariant depending on  |castable between mutable
   |usage   |and immutable if the
   ||elements support it.

--

[Issue 1654] Array concatenation should result in mutable or invariant depending on usage

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #31 from Steven Schveighoffer  ---
I expect at some point for concatenation to be a fully lowered template
function, and at that point, we have all the tools to do this.

You can leave it open if you want, I was just looking through issues I had
reported, and this one just struck me as being very stale, not just in time but
in light of all the developments that have happened in D since 2007.

--

[Issue 18542] New: DMD could generate better assembly for common range check idioms

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18542
   Summary: DMD could generate better assembly for common range
check idioms
   Product: D
   Version: D2
  Hardware: x86_64
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

DMD could generate better assembly for common range check idioms. Take this
program:

---
bool isUpper(dchar c) @safe pure nothrow @nogc
{
// Identical code to current std.ascii : isUpper.
return c <= 'Z' && 'A' <= c;
}
​
void main(string[] args)
{
}
---

Compiled with dmd -O -release, the code for isUpper is:
pushRBP
mov RBP,RSP
cmp EDI,05Ah
ja  LE
cmp EDI,041h
jae L12
LE: xor EAX,EAX
jmp short   L17
L12:mov EAX,1
L17:pop RBP
ret

Compiled with ldc2 -O1, the code for isUpper is:
addl$-65, %edi
cmpl$26, %edi
setb%al
retq

--

[Issue 18541] New: comparison `==` of two typeid() should always be rewritten as a "is"

[d-bugmail--- via Digitalmars-d-bugs]

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

  Issue ID: 18541
   Summary: comparison `==` of two typeid() should always be
rewritten as a "is"
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

I cant see why anyone would want a full bit per bit comparison of the result of
two `typeid()` since `typeid()` returns static instances, shared for each stuff
of a given type. The idea is to have an AST rewrite of

`typeid(T1) == typeid(T2)`  

as 

`typeid(T1) is typeid(T2)`


which is compiled as faster code.

--