[Issue 16042] Identifier on template arguments should consider eponymous member lookup

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

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

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

   What|Removed |Added

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

--

[Issue 16042] Identifier on template arguments should consider eponymous member lookup

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

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

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

https://github.com/dlang/dmd/commit/b2a5fb82d6506291b8a0c72c1e24dc2befb75226
Fix Issue 16042 - Identifier on template arguments should consider eponymous
member lookup

https://github.com/dlang/dmd/commit/5470151e344655df97b2edd3a283e2ea79a6aa75
Merge pull request #7404 from JinShil/fix_16042

Fix Issue 16042 - Identifier on template arguments should consider eponymous
member lookup

--

[Issue 16042] Identifier on template arguments should consider eponymous member lookup

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

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

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

--

[Issue 18099] betterC check throw statements error!

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

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/42ea3732608bc4d877fb0139a00ade9ba9379dd8
fix Issue 18099 - betterC check throw statements error!

https://github.com/dlang/dmd/commit/0a87e133da7fedc0622a26b40705b82d8127bb25
Merge pull request #7539 from WalterBright/fix18099

fix Issue 18099 - betterC check throw statements error!
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 18099] betterC check throw statements error!

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

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

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

   What|Removed |Added

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

--

[Issue 12901] `in`/`out` contracts on struct constructor must require function body

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

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Arguably, the original fix was invalid: it doesn't stop you from writing:


struct S
{
int a;
this(int n) in { a = n; } body {} // or do {}
}


The problem really is allowing assignment to struct members from inside a
contract, which is abuse of the contract feature.  Perhaps the solution should
be to enforce purity on the contract, or, less intrusively, make the contract
body const (i.e., `this` is const inside the contract body).

--

[Issue 12901] `in`/`out` contracts on struct constructor must require function body

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

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

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

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||hst...@quickfur.ath.cx
 Resolution|FIXED   |---

--- Comment #3 from hst...@quickfur.ath.cx ---
Broken by https://github.com/dlang/dmd/pull/7527

--

[Issue 6549] Implement contracts without implementation.

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

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

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

   What|Removed |Added

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

--

[Issue 6549] Implement contracts without implementation.

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

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

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

https://github.com/dlang/dmd/commit/c7d0672b7faa21ead0edd8924c2a719aca94fc21
fix issue 6549 - Implement contracts without implementation

https://github.com/dlang/dmd/commit/d511b9579559d7f3109a7a6aef05b80786612f49
Merge pull request #7527 from ibuclaw/issue6549

fix issue 6549 - Implement contracts without implementation

--

[Issue 12344] .di generation doesn't include contracts in interfaces

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

https://issues.dlang.org/show_bug.cgi?id=12344
Issue 12344 depends on issue 6549, which changed state.

Issue 6549 Summary: Implement contracts without implementation.
https://issues.dlang.org/show_bug.cgi?id=6549

   What|Removed |Added

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

--

[Issue 17985] Implement -stdin for rdmd

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

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

--- Comment #6 from greenify  ---
Fair enough. BTW rdmd doesn't add imports by defaults - only `rdmd --eval
` does.

--

[Issue 17985] Implement -stdin for rdmd

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

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

--- Comment #5 from hst...@quickfur.ath.cx ---
One advantage `echo ... | rdmd -` has over `echo ... | dmd --run -` is that
rdmd inserts a bunch of standard imports into the code, so that you don't have
to keep typing `import std.stdio; ...` in every echo command.

So yes, this is still a valid ER.

--

[Issue 18138] non-shared method overload not accessible through interface

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

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 18138] non-shared method overload not accessible through interface

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

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

--- Comment #2 from Remi Thebault  ---
yes, but the ITest interface has a non-shared method, which is overloaded in
IAtomicTest (IAtomicTest extends ITest), so the non-shared method should be
visible too.

--

[Issue 18139] dmd32: bad conversion of floating-point to string

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

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

--- Comment #1 from Ivan Kazmenko  ---
Walter Bright had the following to say about the issue:

> The issue is really with the DMC++ C runtime library, as that is what Phobos 
> relies on for floating point formatting.

Still, the issue seems to belong to druntime by the tracker classification.
(Or Phobos if the fix would decouple it from snprintf.)

--

[Issue 18139] New: dmd32: bad conversion of floating-point to string

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

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

  Issue ID: 18139
   Summary: dmd32: bad conversion of floating-point to string
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ga...@mail.ru

While exploring quirks of floating-point values, as well as C/C++/D convenience
with them, I stumbled on, in essence, the following (DMD32 on Windows):

void main ()
{
import std.stdio : writefln;
double x = 128.0;// same for real or float
writefln ("%.20a", x);   // 0x1.p+7, right
writefln ("%.20f", x);   // 127.9000, wrong
}

1. The internal representation is fine: the exponent (before shift) is 7, and
the mantissa is all-zeroes (except the "1." part which is not stored).

2. Formatting to a decimal representation goes off in a bad way, giving the
wrong third significant digit.

3. The trail of 9s is the same ~20 decimal digits for every floating-point
type, which suggests that they are all converted to 80-bit real before
formatting.  This obscures their difference in width, which is bad from at
least the learning standpoint.

Point 2 is sad.  One would expect at least the exact powers of two to be stored
exactly.  And indeed they are.  But trying to demonstrate it gives the wrong
impression that they are not.  This adds unnecessary confusion to the already
complex subject of how floating-point values work, and learning the subject
with D becomes much harder.

On the competition front, this already seems to be settled: at least with MinGW
GCC, both C printf and C++ cout correctly display powers of two - and perhaps
any small integers exactly stored as floating-point data, for that matter.

With DMD64, the issue vanishes.  This strongly suggests that 32-bit druntime is
the culprit.  And indeed, the Phobos "formatValue ... if
(is(FloatingPointTypeOf!T) && ...)" for floating-point calls snprintf from
druntime, after which I couldn't easily track it to the source code.  Should
this be so?  And regardless, perhaps snprintf (or Phobos or whatever will do
the dirty work) can adapt a more modern approach so that integers in
floating-point don't get corrupted when converted to string representation? 
Perhaps even without sacrificing much speed.  The most obvious way seems to
just make multiplications by 10, comparisons and subtractions in a loop, and is
likely slow but at least correct for integers.

Original forum thread:
https://forum.dlang.org/post/yzqpwkoycreifdzah...@forum.dlang.org

--

[Issue 18138] non-shared method overload not accessible through interface

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
`i` isn't shared, but the method of the interface requires sharedness. Thus,
the error is legit, imho.
Am I missing something?

--

[Issue 18138] New: non-shared method overload not accessible through interface

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

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

  Issue ID: 18138
   Summary: non-shared method overload not accessible through
interface
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: remi.theba...@gmail.com

Consider the following program and error.
The compiler should not complain.

If ITest is merged with IAtomicTest, the error is gone.
At run-time, methods are correctly dispatched.


interface ITest {
void method();
}

interface IAtomicTest : ITest {
shared void method();
}

class AtomicTest : IAtomicTest {
int member;
override final shared void method() {
import core.atomic : atomicOp;
import std.stdio : writeln;
auto m = atomicOp!"+="(member, 1);
writeln("atomic: ", m);
}
override final void method() {
import std.stdio : writeln;
member += 1;
writeln("non-atomic: ", member);
}
}

void main()
{
auto ao = new shared(AtomicTest);
auto o = new AtomicTest;
ao.method();// fine
o.method(); // fine

auto ai = cast(shared(IAtomicTest))ao;
auto i = cast(IAtomicTest)o;
ai.method();// fine
(cast(ITest)i).method();  // fine
i.method(); // Error: shared method app.IAtomicTest.method is not
callable using a non-shared object
}

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #12 from Basile B.  ---
Before closing, would it be possible to gag the error if the LHS evaluates to
false ?

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #11 from Rainer Schuetze  ---
Short circuiting is only performed for "static if", which also works for your
test case.

The string comparison used to be converted to a runtime call, so it could not
be evaluated further (but with soe special support in CTFE). It is now a
template that can be const folded and reports the error.

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #10 from Basile B.  ---
(In reply to Rainer Schuetze from comment #9)
> > Sorry, did you miss my previous answer ? Use the code from the first 
> > message.
> > The regression is obvious.
> 
> I noticed and it is consistent with what I tried to say before: the reduced
> test case 

Damn, the reduced test case is wrong. Don't comment it

> fails because it checks "test()" for length 6, but then tries to
> access "test()"[$-7].
> 
> I think the problem actually existed before (as in my variation), but is now
> also visible in array comparisons a bit earlier.

Okay let's fix the test case:

```
int test()
{
if (test.stringof.length > 6 &&
test.stringof[$-7..$] == "1234567") {}
return 0;
}

enum a = test();
```

this compiles with 2.077.1, not with 2.078-beta.1.
the "&&" RHS is clearly here to prevent the bound error and the LHS should only
be evaluated once the RHS evaluates to "true". Unless the semantic for && is
different in CTFE mode, which i don't believe to be desirable, there's a
problem

The regression is that (a && b) behaves like ((a) & (b)) for some reason.

--

[Issue 18030] Segmentation fault with __traits(getProtection) on template function.

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #2 from greenify  ---
@dmdreport123: thanks a lot for creating the GitHub repository and Travis
integration, but the reduced test case is a lot better. This is just to avoid
unnecessary work in the future.

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #9 from Rainer Schuetze  ---
> Sorry, did you miss my previous answer ? Use the code from the first message.
> The regression is obvious.

I noticed and it is consistent with what I tried to say before: the reduced
test case fails because it checks "test()" for length 6, but then tries to
access "test()"[$-7].

I think the problem actually existed before (as in my variation), but is now
also visible in array comparisons a bit earlier.

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #8 from Basile B.  ---
(In reply to Rainer Schuetze from comment #7)
> > Rainer, not sure what you're saying. 
> > Is it invalid code in the test case, or a compiler problem?
> 
> I'm not 100% sure. At runtime the code will always produce a RangeError, but
> the check before it causes it to never be executed. Should it still be a
> compile error?
> 
> Allowing the condition could make writing generic code simpler, but might
> also trigger the "unreachable code" warning later. 
> 
> To change it, dmd.constfold must not produce errors (unconditionally), but
> keep the expressions that *might* cause an error at runtime or CTFE. Array
> indexing and divide by zero are probably affected, too.

Sorry, did you miss my previous answer ? Use the code from the first message.
The regression is obvious.

--

[Issue 18115] [REG2.078-b1] case where && is not shortcut anymore in CTFE

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

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

--- Comment #7 from Rainer Schuetze  ---
> Rainer, not sure what you're saying. 
> Is it invalid code in the test case, or a compiler problem?

I'm not 100% sure. At runtime the code will always produce a RangeError, but
the check before it causes it to never be executed. Should it still be a
compile error?

Allowing the condition could make writing generic code simpler, but might also
trigger the "unreachable code" warning later. 

To change it, dmd.constfold must not produce errors (unconditionally), but keep
the expressions that *might* cause an error at runtime or CTFE. Array indexing
and divide by zero are probably affected, too.

--

[Issue 18137] nothrow attribute is not written for some member functions to the JSON file

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

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 18137] nothrow attribute is not written for some member functions to the JSON file

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

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

ZombineDev  changed:

   What|Removed |Added

Summary|Member function attributes  |nothrow attribute is not
   |are not written to the JSON |written for some member
   |file|functions to the JSON file

--

[Issue 18137] New: Member function attributes are not written to the JSON file

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

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

  Issue ID: 18137
   Summary: Member function attributes are not written to the JSON
file
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: petar.p.ki...@gmail.com

Created attachment 1672
  --> https://issues.dlang.org/attachment.cgi?id=1672=edit
Diff between the json generated by DMD v2.072.2 and DMD v2.077.1

When migrating dlang.org's dpl-docs from DMD v2.072.2 to DMD v2.077.1 in
https://github.com/dlang/dlang.org/pull/1926 I noticed that sometimes some
function attributes are not written to the JSON doc metadata file. I have
attached the diff between the two JSON files as seen on CyberShadow's
DAutoTest. For the most part, the upgrade was a clear improvement (e.g.
core.stdc.string.strchr), but I noticed that some member functions in druntime
were missing their nothrow attribute, for example core.memory.GC.malloc,
core.thread.Thread.start, core.thread.Fiber.this, etc.).

--