On Saturday, 6 June 2020 at 00:25:15 UTC, H. S. Teoh wrote:
> On Fri, Jun 05, 2020 at 04:53:28PM -0700, H. S. Teoh via Digitalmars-d wrote:
>> On Fri, Jun 05, 2020 at 11:57:39PM +0200, ag0aep6g via Digitalmars-d wrote: [...]
>> > 2) "bool can be both true and false" https://issues.dlang.org/show_bug.cgi?id=20148
>> > 
>> > This one is just silly.
>> [...]
>> 
>> Nah, it's not silly, it's just that DMD's backend produces code that exhibits quantum uncertainty:
> [...]
>
> For even more quantum fun:
>
> ----------
> bool schrodingersCat() @safe {
> 	import std.random;
> 	union Box { bool b; int state; }
> 	Box u;
> 	u.state = uniform(2, int.max);
> 	return u.b;
> }
> void main() @safe {
> 	import std.stdio;
> 	bool b = schrodingersCat();
> 	if (b) writeln("alive");
> 	if (!b) writeln("dead");
> }
> ----------
>
> With LDC, this code will output either "alive" or "dead" with a roughly 50% probability of each.  So it's a classical observer.
>
> With DMD, however, this code will perceive the quantum superimposition directly and output both "alive" and "dead" every time.
>
> :-D
>
> //
>
> OK, I'll stop now. :-P
>
>
> T

The linked defect, and the issue you posted, don't really make sense to me. They both have UB; reading from an uninitialized variable (= void), or writing to one member of a union and reading from the other. Invoke Undefined Behaviour and you get... Undefined Behaviour.

On 06.06.20 05:40, Meta wrote:
> 
> The linked defect, and the issue you posted, don't really make sense to me. They both have UB; reading from an uninitialized variable (= void), or writing to one member of a union and reading from the other. Invoke Undefined Behaviour and you get... Undefined Behaviour.

Right. It's in @safe code.

On Friday, 5 June 2020 at 23:53:28 UTC, H. S. Teoh wrote:
> Nah, it's not silly, it's just that DMD's backend produces code that exhibits quantum uncertainty:

I actually encountered something goofy like this a few weeks ago when working on my 3DS homebrew, compiling with LDC. I started failing an assert in a game entity's frame logic function that checks two numbers for equality that I knew totally should have been going through. Right before the assert, I added code that looked like this, just to check my sanity:

if (a != b) {
  printf("%d %d %d\n", a, b, a == b);
  foreach (i; 0..10) {
    printf("%d %d %d\n", a, b, a == b);
  }
}

The result was, I kid you not, something like this:

1234 1234 0
1234 1234 1
1234 1234 1
1234 1234 1
1234 1234 1
1234 1234 1
1234 1234 1
1234 1234 1
1234 1234 1
1234 1234 1
1234 1234 1

I was probably hitting UB somewhere... I slap all my entity instances together in an array where the element size is the size of the biggest entity type, using a union to accomplish that. After shifting some code around, it went away, and I haven't seen it since. Spooky...!

On Saturday, 6 June 2020 at 02:41:51 UTC, Walter Bright wrote:
> On 6/5/2020 5:01 PM, mw wrote:
>> Actually I'm wondering if we can have a web poll widget somewhere, so people can vote on the priority of bugs / features / DIPs?
>> 
>> Better be on the front page of https://forum.dlang.org ?
>
> You can already vote on Bugzilla issues.
>
> But what matters is finding someone with the time, interest, and expertise to address each problem.

So being here for a while, I've only had to figure out for myself this, that the D contributors are not enough to handle the incoming bug reports so only the most critical bug are first considered making the others fall behind.

So I'll say there's a need for more pull requests.

But are pull requests getting through considering you have absolute control over most decisions and... honestly not familiar with most other user programming domains... like network, utilities, helpers, and other issues you may not encounter yourself writing compiler code...also stuff Andre had been join more of previously~ ?

Whatever be the case, we're always short of hands. Unfortunately some of us have zero usefulness beyound regular application code... rarely encountering 99% of issues here.

On Friday, 5 June 2020 at 20:35:57 UTC, Walter Bright wrote:
> If you've got problems using D that should be fixed:
>
> 1. File bugzilla issue for them. Issues not in bugzilla don't get fixed.
>
> 2. When talking about the issue, provide a link to the bugzilla issue so we know what you're talking about and know what the current status is.
>
> 3. If you have a laundry list of issues that are important to you, keep a list of bugzilla issue links to them. Then, when you are asked about what problems you're having, cut&paste that list.
>
> Bring them up now and then.
>
> It's that simple!

I have one that I really can't fix myself.

The dwarf tag DW_TAG_inheritance which corresponds to the codeview's LF_BCLASS is missing.
This inhibits debugging to executable build by dmd. On linux.

On Friday, 5 June 2020 at 21:57:39 UTC, ag0aep6g wrote:
> On 05.06.20 22:35, Walter Bright wrote:
>> 1. File bugzilla issue for them. Issues not in bugzilla don't get fixed.
> [...]
>> Bring them up now and then.
>
> How frequent is "now and then"? Like, once a month? Once a year?
>
> Ideally, you would be prioritizing issues based on severity and impact. If you only fix the issues that people nag you about, you risk leaving serious bugs unattended.
>
> Anyway, here are some personal favorites:
>
>
> 1) The DIP 1000 implementation has a glaring accepts-invalid bug with `pure` functions.
> https://issues.dlang.org/show_bug.cgi?id=20150
>
> In my opinion, this one is a blocker for DIP 1000. And unfortunately, it probably made DIP 1000 look better than it is.
>
>
> 2) "bool can be both true and false"
> https://issues.dlang.org/show_bug.cgi?id=20148
>
> This one is just silly.

Undefined behaviour. This said, there is a real code generation error in dmd (not in gdc and ldc) as H.S.Teoh noticed which manifests only in non optimized code. It's in the parameter passing of bool values to a function. It should use the zero extending mov instruction instead. The bug happens only with 8 bit sized types (bool, byte, ubyte and char). With short it uses correctly the movzx instruction.

>
>
> 3) DMD's codegen for the BT (bit test) instruction is all kinds of wrong.
> https://issues.dlang.org/show_bug.cgi?id=18750
>
> A testimony for the questionable quality of DMD's backend.
>
>
> 4) "import doesn't verify module declaration"
> https://issues.dlang.org/show_bug.cgi?id=15086
>
> This accepts-invalid (and arguably wrong-code) issue had some lively discussion years ago. There was a PR, the issue was closed as invalid, it was reopened. And finally it was forgotten.
>
>
> 5) std.stdio tries converting between different UTF variants, but fails horribly.
> https://issues.dlang.org/show_bug.cgi?id=18789 and
> https://issues.dlang.org/show_bug.cgi?id=18801
>
> I tried fixing this one but got stuck when I couldn't reproduce the failures on Windows that the auto-tester shows.

On Friday, 5 June 2020 at 20:35:57 UTC, Walter Bright wrote:
> If you've got problems using D that should be fixed:
>
> 1. File bugzilla issue for them. Issues not in bugzilla don't get fixed.
>
> 2. When talking about the issue, provide a link to the bugzilla issue so we know what you're talking about and know what the current status is.
>
> 3. If you have a laundry list of issues that are important to you, keep a list of bugzilla issue links to them. Then, when you are asked about what problems you're having, cut&paste that list.

All good and right to do of course.  But one thing that could really help is if there was also some kind of higher-level (and well-maintained) priority roadmap for issues.  In other words, it needs to be easy at any given time to:

  * find the high priority issues that are being actively worked on
    (and who is working on them)

  * find the high priority issues that need a contributor

  * see which issues are being targeted for which release

The idea here is that this should make it easy at any time for community members to:

  * get a good overview of what is being actively worked on

  * quickly identify which issues might be most helpful to work on

  * see the priority given to issues they care about (and request
    inclusion if it looks like something is not on the roadmap
    when it should be)

Right now I don't feel that I can get a good at-a-glance overview of what the priorities and roadmaps are for the D community.  And indeed quite often I've found that stuff is happening that was agreed by a relatively small number of people in discussions that are not obviously visible to me (e.g. it wasn't agreed in an issue, or if there _is_ an issue it just states what's to be done without making clear _why_).  Sometimes it seems like some of this is just deriving from Slack discussion between a relatively small group of people.

Obviously it's fine that core developers will have internal discussion that results in decisions and action items, but it would be helpful if the results of that discussion were shared in a more structured fashion that makes it easier to keep track of both what is happening and why it's happening.

On Friday, 5 June 2020 at 23:53:28 UTC, H. S. Teoh wrote:
> On Fri, Jun 05, 2020 at 11:57:39PM +0200, ag0aep6g via Digitalmars-d wrote: [...]
>> 2) "bool can be both true and false" https://issues.dlang.org/show_bug.cgi?id=20148
>> 
>> This one is just silly.
> [...]
>
> Nah, it's not silly, it's just that DMD's backend produces code that exhibits quantum uncertainty:
>
> -----------------
> bool schrodingersCat() @safe {
> 	union Box { bool b; int spin; }
> 	Box u;
> 	u.spin = 2;
> 	return u.b;
> }
> void main() @safe {
> 	import std.stdio;
> 	bool b = schrodingersCat();
> 	if (b) writeln("alive");
> 	if (!b) writeln("dead");
> }
> -----------------
>
> Output:
> -----------------
> alive

TEST AL,AL gives "not zero"

> dead

XOR AL,1 gives "not zero"

xor al,1 is faster than
NOT AL  => stupid Intel prefered to not change flags
TEST AL,AL


> -----------------
>
> :-D
>
> Unfortunately, LDC's backend seems a lot more classical, as the above code produces this output with absolute certainty:

optimizing LDC is so smart that it compiled main down to

writeln("dead");

non optimizing it inserts a (b&1) before testing which explains while the optimizer completely remove the test.


GDC does a cmp,0 for the first test and then a xor 1+test unoptimized but when optimizing it only does first condition with a TEST AL,AL but then prints always the second string.

>
> Output:
> -----------------
> dead
> -----------------
>
> Truly, DMD's backend is in the bright future of strange and wonderful quantum effects, whereas LDC is clearly still stuck in the antiquated classical past. ;-)
>
Sorry, but undefined behaviour is undefined behaviour. The dmd code generator is not at fault here.

On Saturday, 6 June 2020 at 10:09:07 UTC, Patrick Schluter wrote:

> Sorry, but undefined behaviour is undefined behaviour. The dmd code generator is not at fault here.

Indeed, the code generator is not at fault. But, in the bug report, the code is annotated @safe. Yet it compiles :)

On 06.06.20 04:41, Walter Bright wrote:
> You can already vote on Bugzilla issues.

No you can't. The feature was disabled or removed at some point.