-
Notifications
You must be signed in to change notification settings - Fork 13.6k
add test to reproduce #137687 and fix it by converting #[crate_name]
to a new-style attribute parser
#137729
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
base: master
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
04bafec
to
3898182
Compare
This comment has been minimized.
This comment has been minimized.
3898182
to
81fc9d1
Compare
4e90cee
to
21838d5
Compare
21838d5
to
d1ee9c4
Compare
name: Symbol, | ||
name_span: Span, |
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.
This could theoretically use Spanned
but it doesn't necessarily lead to more readable code (and I don't remember if it's compatible with translatable diagnostics).
name: Symbol, | |
name_span: Span, | |
name: Symbol, | |
name_span: Span, |
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.
hmm, I'm not sure that makes it that much better but if you really want it I'm fine with it. Other attrs sometimes have more than 1 span related and then it's nice to distinguish them by name but here it's possible
pub(crate) struct CratenameParser; | ||
|
||
impl SingleAttributeParser for CratenameParser { | ||
const PATH: &'static [Symbol] = &[sym::crate_name]; |
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.
FYI: You generally no longer need to explicitly state 'static
in the ty of assoc consts.
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.
fair enough, d'ya mind if I remove that for all attr parsers in another PR? they'll all have this
|
||
fn on_duplicate(cx: &AcceptContext<'_>, first_span: Span) { | ||
// FIXME(jdonszelmann): better duplicate reporting (WIP) | ||
cx.emit_err(UnusedMultiple { |
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.
Duplicates are warnings on master, right? So this is a breaking change?
@fmease and I decided to delay this PR for a bit until more diagnostic infra for attrs lands (hopefully next week) to make the duplicate error a warning to be consistent with current master. |
r=fmease,bjorn3 once that PR lands and you can downgrade the error to a lint warning again. @bors delegate+ |
✌️ @jdonszelmann, you can now approve this pull request! If @fmease told you to " |
☔ The latest upstream changes (presumably #138416) made this pull request unmergeable. Please resolve the merge conflicts. |
Hi @jdonszelmann and @fmease, #137687 has reached beta so it would be great if we could resolve that via a beta-backport of this PR. Do you think it's possible to resolve the review feedback and merge this PR in the next week or so? I can probably pitch in to help if necessary 🙂 |
Hi there. We wanted to delay this until attribute diagnostics. Something that should not be a lot of work but I have not worked as much on recently as I maybe should. I can't to this tomorrow, but likely next week. The pr has been reviewed but there was a bit of an issue around incremental, which I now know how to solve but just haven't yet. Is that a reasonable timeframe? I am pretty busy with organising rust week atm, but knowing the solution I guess the only important thing is that it gets quick reviews? Let me know how that sounds |
Just to clarify, will this PR then depend on the attribute diagnostics work? (Is that #138164?) Generally, for backports, we try to keep the backport as small as possible so if this PR can be made to work independently of that PR (possibly even with a degraded diagnostics experience), that would be highly preferred. |
No. We decided to delay this because it's relatively low prio and any nice and permanent solution for this depends on that. I'll make a temp fix that at least doesn't ice separately then, that sounds better for now. I don't mind doing it, I know the problem now and then I also know how to fix it permanently later. You'll hear from me |
Note that #137687 actually has two separate problems/subissues:
This PR only appears to address the first problem. The second problem would probably need to have a separate fix. |
ok this is weird, I've copied just the tests over to master to fix it in a temporary way, but can no longer reporoduce the issue. Something else must have solved it in the meantime. Let me see what. |
(I know I've said this in the other PR too, but just in case) Just a heads up: I split #137687 into two issues:
|
d1ee9c4
to
1f5c49f
Compare
@fmease finally got around to this one. The 2nd commit introduces lints for early-parsed attributes which was something that was unsupported earlier simply because no attribute needed it until now. The warning/error is unfortunately emitted twice now which is hard to fix in this PR. We simply call a very long chain of functions twice, and expect the first time to emit errors and the 2nd not. It's hard to distinguish these cases, and in some cases when we try to get metadata from rustc we only actually trigger the chain once so it's hard to even define in which call to emit errors. I left a todo for it. |
should merge after #145243 which is a PR that does some generic diagnostics work that impacts this PR a lot. |
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 have some nits and questions but generally 👍, thanks!
--> $DIR/malformed-attrs.rs:71:1 | ||
| | ||
LL | #[crate_name] | ||
| ^^^^^^^^^^^^^ help: must be of the form: `#[crate_name = "name"]` |
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.
(will be must be of the form: `#![crate_name = "name"]`
(extra !
) after #145238 (future conflict))
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 it's after this one #145243 but ye
@@ -0,0 +1 @@ | |||
print_crate_name_request_malformed_crate_name |
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, interesting ^^. This'll lead to some interesting output in the terminal where stdout & stderr are typically merged.
Ideally we shouldn't emit this (wrong) crate name … but it's probably unavoidable rn since the new attr parsing APIs don't return a Result<_, _>
?
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.
hmm, yea if the attr can't be parsed it's as if the crate name wasn't set at all. Hard to change since that's usually the behavior we want, i.e. give an error, ignore it, and continue
}; | ||
let mut parsed = p.parse_attribute_list( | ||
attrs, | ||
target_span, | ||
target_node_id, | ||
OmitDoc::Skip, | ||
std::convert::identity, | ||
|_lint| { | ||
panic!("can't emit lints here for now (nothing uses this atm)"); | ||
|AttributeLint { id, span, kind }| { |
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 I lack a bigger picture of the new attr parsing APIs) Is it desirable that parse_limited{,_should_emit}
default to lint buffering by default? Shouldn't the caller decide that (via a callback)?
For example, what happens if someone calls one of these functions in a later compiler stage when all buffered lints "have been emitted already"? Can that even happen or are buffered lints only emitted when the session is destroyed (I don't know much about this logic of buffer_lint
)?
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.
that can't really happen
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.
in later compiler stages you don't have ast::Attribute's anymore to parse since they're all parsed during lowering. This is just for the few cases where we want to parse earlier. The only way this could go wrong in is during rustc_ast_lowering where you do still have ast attributes but have already emitted all lints. However, this is also the place where we do all existing attr parsing already in the right way. It's hard to mess that up there.
1f5c49f
to
a584056
Compare
@rustbot review |
a584056
to
86f64ca
Compare
r? @fmease
Closes #137687