-
-
Notifications
You must be signed in to change notification settings - Fork 610
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Issue 19181: always error when an UFCS or opDispatch call has syntactically invalid arguments #8584
Conversation
|
Thanks for your pull request and interest in making D better, @FeepingCreature! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please see CONTRIBUTING.md for more information. If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment. Bugzilla references
Testing this PR locallyIf you don't have a local development environment setup, you can use Digger to test this PR: dub fetch digger
dub run digger -- build "master + dmd#8584" |
|
Holy hell, that's the fastest approval I have ever gotten on Github, let alone DMD. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to have a test.
|
Doesn't this need a test case to prevent a regression. |
Sorry, I had to change my mind. |
Yes, I changed my mind and requested changes. |
|
The original behavior is not strictly speaking wrong, it's just highly misleading. opDispatch does fail to match since the call fails to compile - it just fails to compile due to a call-site error. That said, I'm not sure how you test for a specific error message. edit: The test failure is in master unchanged. God damnit. Why do we even have tests. |
See examples in the |
126b2df to
0534fee
Compare
|
Thanks. Test added. |
test/fail_compilation/fail19181.d
Outdated
| fail_compilation/fail19181.d(13): Error: undefined identifier LanguageError | ||
| --- | ||
| */ | ||
| struct S { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please follow the standard D style, curly braces on their own lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
0534fee to
56ea52d
Compare
test/fail_compilation/fail19181.d
Outdated
| /* | ||
| TEST_OUTPUT: | ||
| --- | ||
| fail_compilation/fail19181.d(15): Error: undefined identifier LanguageError |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the tests suite will probably fail because LanguageError needs to be surrounded with tick marks. We'll find out soon enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the other tests have that too, I've just gone ahead and added it. Can't hurt.
56ea52d to
52ee235
Compare
|
Back to approved, still less than 20 minutes 😃. |
|
Still the fastest, I believe! |
|
Again, that is not an error in my change. |
Are you sure? Run the test suite locally with |
Yes I am, given that it happens on edit: I AM AN IDIOT who doesn't understand how fail tests work. Thanks! This is definitely at least a change from my code. edit: Hah! The test was wrong. edit: Specifically, the body of the typeof was semantically invalid, which due to the change errored before the |
…valid arguments, always error.
52ee235 to
4ea3485
Compare
| @@ -75,7 +75,7 @@ template isComponentStorage(CS, C) | |||
| { | |||
| CS cs = CS.init; | |||
| ulong eid; | |||
| cs.add(eid, c); | |||
| cs.add(eid, C.init); | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this change necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fun reason: Previously, DMD would try to semantically evaluate cs.add before figuring out what if anything c is, hit the !in instantiation error, and bail with the TEST_OUTPUT message. WIth this PR's change, it verifies the arguments to cs.add() first and immediately notices that there is no such variable as c, causing the typeof to fail and, as is typeof's wont, silently return false. Since I can only presume that the fact that c doesn't exist is not actually the point of this test, since there's no comment and it's unrelated to the error message, I just went ahead and made it semantically valid.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, of course. I was reading the corrected code and tried to figure out what was wrong with it 😃.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a bit weird and inconsistent that typeof errors out if only the error that happens in typeof is in a different template.
But that's neither what this bug nor the testcase's bug is about, so ... 🤷♂️
FYI: for the lazy people like me: |
…ror-on-invalid-arguments-in-ufcs-opDispatch Fix Issue 19181: always error when an UFCS or opDispatch call has syntactically invalid arguments merged-on-behalf-of: Sebastian Wilzbach <sebi.wilzbach@gmail.com>
|
This introduced a regression: https://issues.dlang.org/show_bug.cgi?id=20488 |
|
(Regression fixed.) |
Repro:
Before:
test.d(9): Error: no property foo for type S
After:
test.d(9): Error: undefined identifier LanguageError