[Issue 17355] Path to lib64 and $(DMDInstallDir) not correct

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17355

--- Comment #1 from Thomas  ---
Additional notes: No other Visual Studio versions are installed, although the
new vs2017 is installed on another drive (not c: ).

--

[Issue 17355] New: Path to lib64 and $(DMDInstallDir) not correct

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17355

  Issue ID: 17355
   Summary: Path to lib64 and $(DMDInstallDir) not correct
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: visuald
  Assignee: nob...@puremagic.com
  Reporter: thomas.hedst...@mail.com

After installing DMD 2.074.0 and Visual D 0.44.2 the DMD x64 builds cannot find
phobos64.lib.
(LINK : fatal error LNK1104: cannot open file 'phobos64.lib')
Using VS2017 Community (Toolset 2017 and/or toolset 2015 tested thinking it was
a linker problem).

After some more testing it seems there are maybe two problems:
1. When adding and absolute path to "C:\D\dmd2\windows\lib64" in Visual D
global settings "Library path" it works. Missing library path to lib64 ?
2. But, trying relative path $(DMDInstallDir)windows\lib64 to conform with
other path settings, it does not work.

During compilation the $(DMDInstallDir) seems to be ".\", seems wrong.

Variables:
DMDInstallDir=.\
VCTOOLSINSTALLDIR=P:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.10.25017\
VSINSTALLDIR=P:\Program Files (x86)\Microsoft Visual Studio\2017\Community\
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.1\


Note: Compilation from command line "dmd -m64" on the same source works
regardless.

--

[Issue 17354] An overload in a final class can silently hide base methods

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17354

--- Comment #1 from b2.t...@gmx.com ---
No it's not detected in the first (final class) and detected in the second

--

[Issue 17354] New: An overload in a final class can silently hide base methods

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17354

  Issue ID: 17354
   Summary: An overload in a final class can silently hide base
methods
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

Try this:


  final class Foo
  {
bool opEquals(const Object) const {return true;}
  }

  void main(){}

Then this:

  class Foo
  {
bool opEquals(const Object) const {return true;}
  }

  void main(){}


In the first case the hijacking is detected. in the second, everything compiles
finely. This is why jenkins test failed here:
https://github.com/dlang/dmd/pull/6731#issuecomment-297327652

--

[Issue 15692] Allow struct member initializer everywhere

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=15692

--- Comment #3 from Jacob Carlborg  ---
(In reply to Lionello Lunesu from comment #2)
> My 2c: this is more D-like,
> 
> auto foo = cast(Foo){ a: 3, b: 4 };

I disagree, this looks weird.

--

[Issue 13607] BigInt math not usable in @safe code

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13607

--- Comment #6 from hst...@quickfur.ath.cx ---
What should be done about the inline asm heavily used by the BigInt
implementation?  We could use the sledgehammer approach and slap @trusted on
all the inline asm code, but I'm a bit hesitant to do that.

--

[Issue 16303] covariant delegates should implicitly convert

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=16303

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6731

--

[Issue 17349] Covariant overrides should be allowed

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17349

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6731

--

[Issue 17353] is expression type specialization matching strips const

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17353

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--

[Issue 13607] BigInt math not usable in @safe code

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=13607

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

   What|Removed |Added

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

--- Comment #5 from hst...@quickfur.ath.cx ---
A further step in this direction:

https://github.com/dlang/phobos/pull/5354

It's still not complete; BigInt is a pretty deep rabbit warren that will need
some time to completely sort out. One step at a time!

--

[Issue 17351] Static const array can't be evaluated at compile time when passed as ref argument

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17351

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
This issue is not particular to arrays. The following code also fails to
compile:

bool fun(S)(ref S a) { return true; } // (1)
void main()
{
static const int sa2 = 1;
static assert(fun(sa2));
}

--

[Issue 17352] [REG 2.075a] Internal error: ddmd/backend/elfobj.c 1739 on duplicate definition

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17352

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

   What|Removed |Added

 CC||b2.t...@gmx.com
Summary|Internal error: |[REG 2.075a] Internal
   |ddmd/backend/elfobj.c 1739  |error:
   |on duplicate definition |ddmd/backend/elfobj.c 1739
   ||on duplicate definition

--- Comment #2 from b2.t...@gmx.com ---
x86-64 seems to be affected too but in a different way. The example provided
previously compiles and links, instead of complaining about double definition.

--

[Issue 17353] New: is expression type specialization matching strips const

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17353

  Issue ID: 17353
   Summary: is expression type specialization matching strips
const
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: david.ecka...@sociomantic.com

const(T[]) matches an is-expression which it shouldn't match:

---
alias const(int[]) T;
static if (is(T U == U[]))
static assert(is(T == U[])); // fails
---

The "static if" and "static assert" conditions should be equivalent so the
"static assert" should never fail. Instead the "static if" behaves as if the
is-expression would contain Unqual!T instead of T.

--

[Issue 17352] Internal error: ddmd/backend/elfobj.c 1739 on duplicate definition

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17352

--- Comment #1 from Ketmar Dark  ---
some details regarding the bug:

previously, dmd happily creates .o file, and then linker complains about
duplicate definition. and now, i have no way to know *what* symbol was defined
multiple times.

so this is not about "compiler doesn't check for two `foo()`s", it's about
compiler ICEing now, and i have no way to know which symbol i redefined.

--

[Issue 17352] Internal error: ddmd/backend/elfobj.c 1739 on duplicate definition

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17352

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 17352] New: Internal error: ddmd/backend/elfobj.c 1739 on duplicate definition

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17352

  Issue ID: 17352
   Summary: Internal error: ddmd/backend/elfobj.c 1739 on
duplicate definition
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

=== bug.d ===
void foo () {}
void foo () {}
void main () {}


dmd bug.d
Internal error: ddmd/backend/elfobj.c 1739

introduced around commit a48acfedcc3d011e4050bb3b37b51866698daa05 (use linkonce
for Elf code COMDATs)

--

[Issue 17351] New: Static const array can't be evaluated at compile time when passed as ref argument

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17351

  Issue ID: 17351
   Summary: Static const array can't be evaluated at compile time
when passed as ref argument
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lucia.mcojoc...@gmail.com

Static const arrays can't be evaluated at compile time when they are passed as
__ref__ arguments to a function. 

bool fun(S)(ref S[3] a) { return true; } // (1)
void main()
{
static const int[3] sa2 = 1;
static assert(fun(sa2));
}

staticcomp.d(8): Error: static variable sa2 cannot be read at compile time
staticcomp.d(8):called from here: fun(sa2)
staticcomp.d(8):while evaluating: static assert(fun(sa2))

Non-ref param implementation compiles without errors.
bool fun(S)(S[3] a) { return true; }   // (2)

Defining both (1) and (2) overloads in the same program fails to pick the
non-ref overload and gives the same compilation error.

--

[Issue 17350] New: bitmanip checks min, while Ternary does not have this property

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17350

  Issue ID: 17350
   Summary: bitmanip checks min, while Ternary does not have this
property
   Product: D
   Version: D2
  Hardware: x86_64
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: sascha.or...@gmail.com

Trying this 

import std.bitmanip; 
import std.typecons; 
void main(){}

struct S1
{
mixin(taggedPointer!(
Val*, "vv",
bool, "b1", 1,
bool, "b2", 1,
bool, "b3", 1));
}

struct S2
{
mixin(taggedPointer!(
Val*, "vv",
ubyte, "t", 3));
}

struct S3
{
mixin(taggedPointer!(
Val*, "vv",
Ternary, "t", 3));
}

struct Val
{
size_t dummy; 
}

I got an error: 
bitmanip.d(94,20): Error: no property 'min' for type 'Ternary'
bitmanip.d(127,20): Error: no property 'min' for type 'Ternary'
bitmanip.d(183,15): Error: template instance
std.bitmanip.createAccessors!("_vv_t", Ternary, "t", 3LU, 0LU) error
instantiating
bitmanip.d(243,11): instantiated from here: createFields!("_vv_t", 0LU,
Ternary, "t", 3, ulong, "", 61LU)
bitmanip.d(314,26): instantiated from here: createTaggedReference!(Val*, 8LU,
"vv", Ternary, "t", 3)
test62.d(17,8): instantiated from here: taggedPointer!(Val*, "vv", Ternary,
"t", 3)

I understand, that it is not possible to order a Ternary without
implifications. However, as the size allows it, it should be possible to use it
as a pointer discriminator.

--

[Issue 17349] New: Covariant overrides should be allowed

2017-04-26 Thread via Digitalmars-d-bugs 
https://issues.dlang.org/show_bug.cgi?id=17349

  Issue ID: 17349
   Summary: Covariant overrides should be allowed
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

The following:

  class C {
void bar();
void foo(void* p);
  }

  class D : C {
override void bar() const;// works
override void foo(const void* p); // error
  }

produces the error:

  test.d(8): Error: function test.D.foo does not override any function, did you
mean to override 'test.C.foo'?

when it should compile successfully.

The covariance check is only done on the 'this' pointer. The problem is in the
compiler function findVtblIndex().

--