[Issue 16081] New: CTFE mistakes for arr in cast

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16081

  Issue ID: 16081
   Summary: CTFE mistakes  for arr in cast
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ag0ae...@gmail.com

Encountered by Era Scarecrow in D.learn:
http://forum.dlang.org/post/mzzpcdzuovajqygue...@forum.dlang.org


size_t f()
{
  size_t[] arr = [13];
  return *(cast(size_t*) );
}

void main()
{
import std.stdio;
enum ct = f();
auto rt = f();
writeln(ct, " ", rt);
}


Prints: "13 1".

The expected value is 1 for both. A "not supported" error during CTFE would
also be acceptable, as happens when  is assigned to a variable first. Looks
like CTFE mistakes  for arr here.

--


[Issue 16080] Internal error: backend\cgobj.c 3406 when building static library

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16080

Sönke Ludwig  changed:

   What|Removed |Added

   Severity|major   |regression

--- Comment #1 from Sönke Ludwig  ---
Introduced in 2.071.0, still happens in 2.071.1-b1

--


[Issue 16080] Internal error: backend\cgobj.c 3406 when building static library

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16080

Sönke Ludwig  changed:

   What|Removed |Added

   Keywords||ice, ice-on-valid-code

--


[Issue 16080] New: Internal error: backend\cgobj.c 3406 when building static library

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16080

  Issue ID: 16080
   Summary: Internal error: backend\cgobj.c 3406 when building
static library
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: slud...@outerproduct.org

Taking the following three modules:

a.d:
---
struct A() {
static immutable A a;
}
---

b1.d
---
import a;
---

b2.d
---
import a;
void test2() {
A!() v = A!().a;
}
---

Running "dmd -lib b1.d b2.d" results in:
Internal error: backend\cgobj.c 3406

Changing the order or taking away either b1.d or b2.d from the command line
will make the build succeed.

--


[Issue 15925] [REG 2.071] Import declaration from mixin templates are ignored

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15925

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #8 from Martin Nowak  ---
Weird, need to work on this.

With 2.071.0 -transition=import works as expected (but -transition=checkimports
doesn't report an error).
With the latest nightly dmd-2016-05-26 it will accept the code w/o
-transition=import b/c we haven't yet merged back the revert.
With the latest stable 64f3fdb27 it will fail even with -transition=import.

--


[Issue 15966] [REG 2.071] {public,protected} imports in base class ignored on symbol lookup

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=15966

--- Comment #13 from Martin Nowak  ---
Works as expected with -transition=import/checkimports and that behavior is
already covered by test cases.

--


[Issue 16065] Provide digitally signed binaries for Windows

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16065

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

   What|Removed |Added

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

--- Comment #4 from b2.t...@gmx.com ---
"-4" for the windows certificate because

- It is not free. It's a commercial system, e.g there are companies whose
buisness it to sell them.

- Companies who deliver them for free do it only for FOSS. but DMD is not fully
FOSS.

- This system usually just reassures people who know nothing to software but
since DMD are dedicated to programmers this is not useful at all.

- This system means nothing unless the software checks itself for the
certificate at run-time (e.g windows only checks on execution if the UAC is
toggled on).

Windows certificates are just a trick invented in the early 2010's to steal the
money of the developers. The impact on the secutity is very low since this
system would have been useful ten years before (early 2000's, XP, the freeware
galore, ...) when Windows was still the main platform used as malware vector.

I would advice you not to lose time to obtain that DMD, the tools and the
installer, get signed. ;)

--


[Issue 16065] Provide digitally signed binaries for Windows

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16065

--- Comment #3 from Sobirari Muhomori  ---
A more reliable mechanism would be a PGP signature. If you check against only
one key, it will be equivalent to key pinning. Oh, and the ultimate security is
to build everything from source.

--


[Issue 16079] New: memoize should cache objects too

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16079

  Issue ID: 16079
   Summary: memoize should cache objects too
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

I don't see any reason why memoize should execute this code twice.

   int executed = 0;
T median(T)(T[] nums) {
import std.algorithm: sort;
executed++;
nums.sort();
if (nums.length % 2)
return nums[$ / 2];
else
return (nums[$ / 2 - 1]
+ nums[$ / 2]) / 2;
}

alias fastMedian = memoize!(median!int);

assert(fastMedian([7, 5, 3]) == 5);
assert(fastMedian([7, 5, 3]) == 5);

assert(executed == 1); // ERROR, 2

--


[Issue 16062] Add 'clear' method to OutBuffer (std.outbuffer)

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16062

greensunn...@gmail.com changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from greensunn...@gmail.com ---
I absolutely agree that there should be a "standard D way" as for other range
types

See also this discussion on Github:
https://github.com/dlang/phobos/pull/3362

--


[Issue 16063] DLL projects seem to ignore DllMain, won't link

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16063

--- Comment #3 from Manu  ---
Ah, I don't think I've ever used optlink since your 32bit COFF work was merged
;)

--


[Issue 9149] Disallow converting delegates to const

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=9149

--- Comment #15 from Sobirari Muhomori  ---
If we have syntax to declare delegates with function attributes and
disambiguate context attributes, why not implement contravariance check? It's
likely to be big and complex, but it's pure, doesn't change the compiler state,
doesn't even allocate memory, only takes two const types and returns bool -
unlikely to cause serious side effects.

--


[Issue 16078] New: %e (scientific notation) should be supported for all integer-like types

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16078

  Issue ID: 16078
   Summary: %e (scientific notation) should be supported for all
integer-like types
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

I expected the following to work:

```
import std.bigint;
import std.stdio;
void main()
{
writefln("%e", BigInt(100_000));
}
```

It turns out that "%e" is only supported for floating point types and even
doesn't work for built-in int/long.

--


[Issue 16077] [CodeView] no language information in MS-COFF debug information

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16077

Rainer Schuetze  changed:

   What|Removed |Added

   Keywords||pull, symdeb

--- Comment #1 from Rainer Schuetze  ---
https://github.com/dlang/dmd/pull/5808

--


[Issue 16077] New: [CodeView] no language information in MS-COFF debug information

2016-05-26 Thread via Digitalmars-d-bugs
https://issues.dlang.org/show_bug.cgi?id=16077

  Issue ID: 16077
   Summary: [CodeView] no language information in MS-COFF debug
information
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: r.sagita...@gmx.de

The codeview debug information generated by dmd for MS-COFF does not contain
any language information which could be used by a debugger to select the
expression evaluator.

This can be implemeted by adding a S_COMPILE record.

The OMF debug information contains this record, but only pretends to be C/C++.

--