Bug 20488 – AA.length in multiple modules causes opDispatch failure

Status
RESOLVED
Resolution
FIXED
Severity
regression
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2020-01-08T09:09:08Z
Last change time
2020-02-07T04:15:19Z
Keywords
pull
Assigned to
No Owner
Creator
Andrej Mitrovic

Attachments

IDFilenameSummaryContent-TypeSize
1771test-case.ziptest caseapplication/zip1951

Comments

Comment #0 by andrej.mitrovich — 2020-01-08T09:09:08Z
Created attachment 1771 test case This is the weirdest bug I have ever filed. I couldn't reduce it further, and I reduced it to this stage manually because Dustmite took way too long. It seems that whatever I touch, the bug will fail to reproduce. For example, changing a hashmap into an array in the offending line makes the bug disappear. The attachment has the source files and a simple run.sh script. Tested on MacOS Mojave & DMD v2.089.1
Comment #1 by simen.kjaras — 2020-01-08T13:53:49Z
Further reduced: foo.d: /////////////////////////// struct Foo { bool[int] aa; void fun() { int i = aa.length; } } /////////////////////////// bar.d: /////////////////////////// struct Bar { int[int] aa; void fun() { this.f(aa.length); } void opDispatch (string s, Args...) (Args args) { } } /////////////////////////// Compile with 'dmd foo bar', and you get bar.d(4): Error: no property f for type bar.Bar If the two AA types are identical it compiles. Adding 'int j = (int[int]).init.length;' to S1.fun() does make it compile, but only if it's before the 'int i = ...' line (wat).
Comment #2 by moonlightsentinel — 2020-01-08T16:51:43Z
Comment #3 by default_357-line — 2020-01-09T07:39:12Z
Further reduction: struct Bar { void opDispatch(string s, Args...) (Args args) { } void fun() { (bool[int]).init.length; this.f((int[int]).init.length); } } Looking into it.
Comment #4 by dlang-bot — 2020-01-09T08:05:12Z
@FeepingCreature created dlang/dmd pull request #10718 "Fix issue 20488: opDispatch: copy call expression before checking for semantically valid parameters" fixing this issue: - opDispatch: copy call expression before checking for semantically valid parameters. This may avoid accidentally resolving future occurrences to the wrong type, not sure. Fixes issue 20488. https://github.com/dlang/dmd/pull/10718
Comment #5 by dlang-bot — 2020-01-13T03:52:30Z
dlang/dmd pull request #10718 "Fix issue 20488: opDispatch: copy call expression before checking for semantically valid parameters" was merged into stable: - 78e214e75b464a2703115890ba6d3c60384c668b by Mathis Beer: opDispatch: only validate parameters if we've already seen indication of a semantic failure. This avoids double evaluation of parameter semantic in some situations. Fixes issue 20488. https://github.com/dlang/dmd/pull/10718
Comment #6 by dlang-bot — 2020-02-07T04:15:19Z
dlang/dmd pull request #10753 "Merge remote-tracking branch 'upstream/stable' into merge_stable" was merged into master: - 65237abf9323434f5072a3f8b95a0824655522a8 by Mathis Beer: opDispatch: only validate parameters if we've already seen indication of a semantic failure. This avoids double evaluation of parameter semantic in some situations. Fixes issue 20488. https://github.com/dlang/dmd/pull/10753