-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
in which the unused-parens lint comes to cover function and method args #46980
in which the unused-parens lint comes to cover function and method args #46980
Conversation
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
92e9c0d
to
b7739f3
Compare
Travis failure looks dubious |
@bors r+ |
📌 Commit b7739f3 has been approved by |
⌛ Testing commit b7739f3 with merge f5f2de1248978ff21036e8aa81b21c66b50fd051... |
💔 Test failed - status-travis |
⌛ Testing commit b7739f3 with merge 56e8ea3665d395a697e89b3a4ca23a9a3c14f866... |
💔 Test failed - status-travis |
…nthesized_arguments, r=petrochenkov in which the unused-parens lint comes to cover function and method args Resolves #46137.
💔 Test failed - status-appveyor |
Legit.
|
b7739f3
to
bff573c
Compare
Yes, with regrets, it turns out that the "Eh, this looks right; I don't have to tie up my cores running the tests locally because Travis will catch any needed fixes for me without wasting any reviewer-minutes" PR strategy is less effective when Travis is broken. Force-push bff573c is more likely to be what we want (although my local test build is unrelatedly flaking late in the test process, after the ui/run-pass/compile-fail tests have apparently succeeded). |
bff573c
to
6dee797
Compare
@bors r+ |
📌 Commit 6dee797 has been approved by |
📌 Commit 8a94e4c has been approved by |
@bors r- Something’s wrong with the new cargo @rust-lang/cargo.
|
☔ The latest upstream changes (presumably #47248) made this pull request unmergeable. Please resolve the merge conflicts. |
Blocked on #47280 |
8a94e4c
to
14982db
Compare
no. 47280 has landed; rebased |
@bors r+ |
📌 Commit 14982db has been approved by |
…nthesized_arguments, r=petrochenkov in which the unused-parens lint comes to cover function and method args Resolves #46137.
☀️ Test successful - status-appveyor, status-travis |
In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the unused-parens lint was made to check function and method arguments, which it previously did not (seemingly due to oversight rather than willful design). However, in rust-lang#47775 and discussion thereon, user–developers of Geal/nom and graphql-rust/juniper reported that the lint was seemingly erroneously triggering on certain complex macros in those projects. While this doesn't seem like a bug in the lint in the particular strict sense that the expanded code would, in fact, contain unncecessary parentheses, it also doesn't seem like the sort of thing macro authors should have to think about: the spirit of the unused-parens lint is to prevent needless clutter in code, not to give macro authors extra heartache in the handling of token trees. We propose the expediency of declining to lint unused parentheses in function or method args inside of nested expansions: we believe that this should eliminate the petty, troublesome lint warnings reported in the issue, without forgoing the benefits of the lint in simpler macros. It seemed like too much duplicated code for the `Call` and `MethodCall` match arms to duplicate the nested-macro check in addition to each having their own `for` loop, so this occasioned a slight refactor so that the function and method cases could share code—hopefully the overall intent is at least no less clear to the gentle reader. This is concerning rust-lang#47775.
…ssary_unnecessary_parens, r=nikomatsakis decline to lint technically-unnecessary parens in function or method arguments inside of nested macros In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the unused-parens lint was made to check function and method arguments, which it previously did not (seemingly due to oversight rather than willful design). However, in rust-lang#47775 and discussion thereon, user–developers of Geal/nom and graphql-rust/juniper reported that the lint was seemingly erroneously triggering on certain complex macros in those projects. While this doesn't seem like a bug in the lint in the particular strict sense that the expanded code would, in fact, contain unncecessary parentheses, it also doesn't seem like the sort of thing macro authors should have to think about: the spirit of the unused-parens lint is to prevent needless clutter in code, not to give macro authors extra heartache in the handling of token trees. We propose the expediency of declining to lint unused parentheses in function or method args inside of nested expansions: we believe that this should eliminate the petty, troublesome lint warnings reported in the issue, without forgoing the benefits of the lint in simpler macros. It seemed like too much duplicated code for the `Call` and `MethodCall` match arms to duplicate the nested-macro check in addition to each having their own `for` loop, so this occasioned a slight refactor so that the function and method cases could share code—hopefully the overall intent is at least no less clear to the gentle reader. This is concerning rust-lang#47775.
…ssary_unnecessary_parens, r=nikomatsakis decline to lint technically-unnecessary parens in function or method arguments inside of nested macros In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the unused-parens lint was made to check function and method arguments, which it previously did not (seemingly due to oversight rather than willful design). However, in rust-lang#47775 and discussion thereon, user–developers of Geal/nom and graphql-rust/juniper reported that the lint was seemingly erroneously triggering on certain complex macros in those projects. While this doesn't seem like a bug in the lint in the particular strict sense that the expanded code would, in fact, contain unncecessary parentheses, it also doesn't seem like the sort of thing macro authors should have to think about: the spirit of the unused-parens lint is to prevent needless clutter in code, not to give macro authors extra heartache in the handling of token trees. We propose the expediency of declining to lint unused parentheses in function or method args inside of nested expansions: we believe that this should eliminate the petty, troublesome lint warnings reported in the issue, without forgoing the benefits of the lint in simpler macros. It seemed like too much duplicated code for the `Call` and `MethodCall` match arms to duplicate the nested-macro check in addition to each having their own `for` loop, so this occasioned a slight refactor so that the function and method cases could share code—hopefully the overall intent is at least no less clear to the gentle reader. This is concerning rust-lang#47775.
…ssary_unnecessary_parens, r=nikomatsakis decline to lint technically-unnecessary parens in function or method arguments inside of nested macros In rust-lang#46980 ("in which the unused-parens lint..." (14982db)), the unused-parens lint was made to check function and method arguments, which it previously did not (seemingly due to oversight rather than willful design). However, in rust-lang#47775 and discussion thereon, user–developers of Geal/nom and graphql-rust/juniper reported that the lint was seemingly erroneously triggering on certain complex macros in those projects. While this doesn't seem like a bug in the lint in the particular strict sense that the expanded code would, in fact, contain unncecessary parentheses, it also doesn't seem like the sort of thing macro authors should have to think about: the spirit of the unused-parens lint is to prevent needless clutter in code, not to give macro authors extra heartache in the handling of token trees. We propose the expediency of declining to lint unused parentheses in function or method args inside of nested expansions: we believe that this should eliminate the petty, troublesome lint warnings reported in the issue, without forgoing the benefits of the lint in simpler macros. It seemed like too much duplicated code for the `Call` and `MethodCall` match arms to duplicate the nested-macro check in addition to each having their own `for` loop, so this occasioned a slight refactor so that the function and method cases could share code—hopefully the overall intent is at least no less clear to the gentle reader. This is concerning rust-lang#47775.
Resolves #46137.