[Issue 17772] Wrong C++ mangled names for templated functions

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17772

Илья Ярошенко  changed:

   What|Removed |Added

   Keywords||betterC, C++, wrong-code

--

[Issue 17772] New: Wrong C++ mangled names for templated functions

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17772

  Issue ID: 17772
   Summary: Wrong C++ mangled names for templated functions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com



_Z3fooIiEiv (D) vs _ZN5SPACE3fooIiEET_v(C++)
_Z4foo2IiEiv(D) vs _Z4foo2IiET_v   (C++)




// D
DMD64 D Compiler v2.076.0-b1-dirty

```
extern(C++, SPACE)
T foo(T)(){ T t; return t;}

extern(C++)
T foo2(T)(){ T t; return t;}


pragma(msg, mangledName!(foo!int));
pragma(msg, mangledName!(foo2!int));```

output:

_Z3fooIiEiv
_Z4foo2IiEiv


// C++ (clang++ for macos and linux)

```
namespace SPACE
{
template
T foo() { T t; return t;}

int bar(){ return foo(); }
}

template
T foo2() { T t; return t;}

int bar2(){ return foo2(); }
```

clang++ -emit-llvm  -S -std=c++14 test_exc.cpp

output:

; Function Attrs: nounwind ssp uwtable
define linkonce_odr i32 @_ZN5SPACE3fooIiEET_v() #1 {
  %1 = alloca i32, align 4
  %2 = load i32, i32* %1, align 4
  ret i32 %2
}

; Function Attrs: nounwind ssp uwtable
define linkonce_odr i32 @_Z4foo2IiET_v() #1 {
  %1 = alloca i32, align 4
  %2 = load i32, i32* %1, align 4
  ret i32 %2
}

--

[Issue 17765] void initialisation of out parameters

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17765

--- Comment #2 from Nicholas Wilson  ---
Yeah the compiler was not able to determine that all values were assigned
despite there being no conditional logic for the initialisation:

foreach(i; 0 .. M-1)
{
corr[i][i] = 1.0;
for (auto j = i+1; j < M; j++)
{
corr[i][j] = 0.0;
for (auto k = 0; k < N; k++)
corr[i][j] += data[k][i] * data[k][j];
corr[j][i] = corr[i][j];
}
}
foreach(i; 0 .. M) corr[M-1][i] = 0.0;
corr[M-1][M-1] = 1.0;

>I was wondering if this could more of an implementation detail in the function 
>itself.
>
> i.e.:
>
> void g(out float[M][M] corr)
> {
> corr = void; // disables the initial write
> }

That would also work and would probably be less effort in the compiler and less
confusing.

> This shouldn't be allowed in @safe code.

Definitely.

--

[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17767

--- Comment #4 from Iain Buclaw  ---
(In reply to ecstatic.coder from comment #3)
> Please could you simply download the latest file from Github and compile
> locally with your own version of gdc.
> 
> https://github.com/senselogic/RECAST/blob/master/recast.d
> 
> If it compiles fine with your version, then I know it's just a compiler
> version problem, not a compiler bug, and this will eventually be solved once
> I will be able to use the same version as you :)

I initially got a link error, but when pushing out phobos 2.076 it worked fine.

The internal error in both places seem to suggest a bug in earlier versions of
the front-end, in particular, a bogus Dsymbol was passed to the backend.

You're going to have to try multiple versions of dmd here, possible starting
from 2.066 or 2.068, and noting any differences between versions.

What I expect you to find is, that 2.066 ICE'd, 2.071 works, 2.075 regressed
and has linker errors, and 2.076 is fine again.

--

[Issue 17761] [REG2.075] dmd 2.075.1 creates object files that can't be linked by ld.bfd

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17761

Martin Nowak  changed:

   What|Removed |Added

   Keywords||link-failure, pull

--- Comment #4 from Martin Nowak  ---
My version `ld.bfd -v`
GNU ld version 2.27-24.fc26

Was able to reproduce this in an ArchLinux container.

ld.bfd -v
GNU ld (GNU Binutils) 2.28.0.20170506


https://github.com/dlang/dmd/pull/7093

--

[Issue 16177] Inner exception cannot be caught by specific type; becomes a collateral of the original exception

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16177

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 17673] regex(["\\\\\\\\|\\\\\"", "\"|$"]) - wrong whichPattern

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17673

Dmitry Olshansky  changed:

   What|Removed |Added

   Severity|critical|normal

--

[Issue 17771] foreach over const input range fails

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17771

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Steven Schveighoffer  ---
The compiler doesn't attempt to modify attributes in almost any case.

For instance:

auto foo()
{
   const int x = 5;
   return x;
}

auto y = foo(); // y is const(int), even though it could be just int

So this behavior is consistent. You need to tell the compiler to make the copy
with the correct attributes.

Note that many many ranges are not implicitly copyable to a mutable version, so
this ability would not help in most cases.

One valid enhancement that you could propose is to add a function somewhere in
phobos (probably in typecons) that returns a copy of the item with as many
qualifiers removed as possible. Then your code could become something like:

foreach(x; unqual(r))

--

[Issue 17771] foreach over const input range fails

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17771

Alex Goltman  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #2 from Alex Goltman  ---
If it fails to implicitly copy to a non-const (e.g.  a struct with a pointer
inside) then so be it - but why not make it try at least? as in:

Unqual!(typeof(range)) _r = range;

It seems weird that foreach which intentionally copies the range to avoid
modifying it will fail because a range is an unmodifiable const.

--

[Issue 13262] Cannot send certain shared data to another thread

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13262

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

https://github.com/dlang/phobos/commit/373babe48e186d2e9a54042bd35317c928b14bc3
fix issue 13262 - Ensure shared data can be sent and received via
send/receive. Also now allows all types of shared items to be stored in
a Variant.

https://github.com/dlang/phobos/commit/e2a16ccd4d78ce7288d9abfb253bf64bc6638198
Merge pull request #5694 from schveiguy/fix13262

fix issue 13262 - Cannot send certain shared data to another thread

--

[Issue 13262] Cannot send certain shared data to another thread

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13262

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--

[Issue 17771] foreach over const input range fails

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17771

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |INVALID

--- Comment #1 from Steven Schveighoffer  ---
1. foreach (and D in general) doesn't attempt to change any attributes, it
simply makes a copy via:

auto _r = range;

2. Ranges aren't always copyable to non-const versions implicitly.

So you need to do this yourself or cast:

foreach(x; cast() r)

--

[Issue 17765] void initialisation of out parameters

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17765

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
In the case of out variables, one of the reasons the init is done is to ensure
that the data is all written to.

2 things:

1. If the compiler can prove that the out variable is completely written in all
paths, then the initial write can be removed (could be happening already).
2. If the out = void syntax is accepted, and not all the data is written, then
this should really be an error.

Both require advanced flow analysis, and may not be possible in all cases, so
the result is that in cases where =void is used, not writing all the data is
going to be UB.

Another issue is that the current grammar/syntax defines =X to mean "pass X as
parameter if none specified". =void looks weird, and it also doesn't fit the
grammar if you have required parameters after it.

I was wondering if this could more of an implementation detail in the function
itself.

i.e.:

void g(out float[M][M] corr)
{
corr = void; // disables the initial write
}

This shouldn't be allowed in @safe code.

--

[Issue 8841] Missing line numbers in stack trace?

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=8841

Gerald Jansen  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17727

--

[Issue 17727] addr2line does not understand debug info

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17727

Gerald Jansen  changed:

   What|Removed |Added

 CC||jansen.ger...@gmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=8841

--

[Issue 17761] [REG2.075] dmd 2.075.1 creates object files that can't be linked by ld.bfd

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17761

--- Comment #3 from anonymous4  ---
Maybe depends on OS/ld version.

--

[Issue 17761] [REG2.075] dmd 2.075.1 creates object files that can't be linked by ld.bfd

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17761

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #2 from Martin Nowak  ---
Please always at least add the exact commit hash/tag when referencing external
code in a bug entry. At best use Digger to reduce the test case.
Can't reproduce this with

reggae: 1e499c7b257c23415b1e745b6bd937f889300b85
unit-threaded: 0.7.28
dmd: v2.075.1
dub: 1.4.0

I used `curl -fsS https://dlang.org/install.sh | bash -s dmd-2.075.1` to get
the compiler.

On a sidenote, my dub hash is different than yours, not sure what command line
flags differ.
.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-C42D717244B28E601F8D29F4D95527E

This is the compiler invocation from dub.

dmd -c
-of.dub/build/unittest-unittest-linux.posix-x86_64-dmd_2075-C42D717244B28E601F8D29F4D95527E0/ut.o
-debug -g -unittest -w -version=Have_reggae -version=Have_unit_threaded -Isrc
-Ipayload
-I../../../home/dawg/.dub/packages/unit-threaded-0.7.28/unit-threaded/source/
-Jpayload/reggae -Jtests/json bin/ut.d ...

--

[Issue 10157] Vector ops with different types

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=10157

--- Comment #3 from anonymous4  ---
Hmm... vector ops are array ops?

--

[Issue 17766] Wrong choice of generic mutable/const/immutable methods

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17766

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

[Issue 10157] Vector ops with different types

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=10157

anonymous4  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Hardware|x86 |All
 Resolution|FIXED   |---
 OS|Windows |All

--- Comment #2 from anonymous4  ---
void f()
{
ubyte[] a;
char[] b;
a[]=b[];
}
Error: cannot implicitly convert expression `b[]` of type `char[]` to `ubyte[]`

--

[Issue 17761] [REG2.075] dmd 2.075.1 creates object files that can't be linked by ld.bfd

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17761

anonymous4  changed:

   What|Removed |Added

Summary|dmd 2.075.1 creates object  |[REG2.075] dmd 2.075.1
   |files that can't be linked  |creates object files that
   |by ld.bfd   |can't be linked by ld.bfd
   Severity|major   |regression

--

[Issue 17769] dmd accepts conversion from shared(int)* to int* when value comes from method

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17769

anonymous4  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17771] New: foreach over const input range fails

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17771

  Issue ID: 17771
   Summary: foreach over const input range fails
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: alex.golt...@gmail.com

```
static struct NumRange {
int front = 0;
int end = 0;

@property auto length() const { return end - front; }
@property bool empty() const { return length == 0; }
void popFront() { front++; }
}
const r = NumRange(0, 5);
foreach (x; r) {
writeln(x);
}
```
results in
```
Error: mutable method test.main.NumRange.popFront is not callable using a const
object
```
even though foreach copies the input range it gets (as evident from running
foreach on same range twice), so it can at least try to copy it to an
non-const.

--

[Issue 17767] Dmd can't link recast.d, Gdc can't compile it and Ldc can perfectly compile it.

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17767

--- Comment #3 from ecstatic.coder  ---
Please could you simply download the latest file from Github and compile
locally with your own version of gdc.

https://github.com/senselogic/RECAST/blob/master/recast.d

If it compiles fine with your version, then I know it's just a compiler version
problem, not a compiler bug, and this will eventually be solved once I will be
able to use the same version as you :)

--

[Issue 17770] Null pointer access in CTFE code

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17770

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Slightly more reduced, and including a variant that throws an AssertError
instead of segfaulting:


struct S { T* t; }
struct T { string name; }

S foo(string name)
{
return S(new T(name[0 .. $]));
}

int bar(string name)
{
version (segfault)
size_t len = name.length; // segfault
else version (asserterror)
string n = name; // AssertError@ddmd/ctfeexpr.d(1854)
return 0;
}

const S s = foo("");
enum b = bar(s.t.name);


--

[Issue 17770] Null pointer access in CTFE code

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17770

Sönke Ludwig  changed:

   What|Removed |Added

   Keywords||CTFE, ice

--

[Issue 17770] New: Null pointer access in CTFE code

2017-08-21 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17770

  Issue ID: 17770
   Summary: Null pointer access in CTFE code
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

Compiling the following snippet with DMD 2.076.0-b1 yields:

object.Error@(0): Access Violation

0x0042FF45

Earlier compiler versions produce similar errors.

---
struct S { T*[] nodes; }
struct T { string name; }

S foo(string text)
{
T*[] ret;
while (text.length) {
auto n = new T;
n.name = text;
text = text[1 .. $];
ret ~= n;
}
return S(ret);
}

string bar(in S doc)
{
foreach (n; doc.nodes)
baz(n);
return null;
}

void baz(in T* node)
{
switch (node.name) {
default:
case "|":
break;
}
}

static const n = foo("xx");
enum b = bar(n);
---

--