-
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
Warn about unknown doc attributes #82662
Conversation
This comment has been minimized.
This comment has been minimized.
18bd10e
to
d089510
Compare
Looks good to me with #82662 (comment) addressed, but I want to double check it's fine to add this in rustc_attr instead of rustdoc. My reasoning is I think this should warn when running |
This comment has been minimized.
This comment has been minimized.
Seems fine. |
d089510
to
f6de130
Compare
@bors r+ |
📌 Commit f6de130 has been approved by |
…laumeGomez Rollup of 7 pull requests Successful merges: - rust-lang#80734 (check that first arg to `panic!()` in const is `&str`) - rust-lang#81932 (Always compile rustdoc with debug logging enabled when `download-rustc` is set) - rust-lang#82018 (Remove the dummy cache in `DocContext`; delete RenderInfo) - rust-lang#82598 (Check stability and feature attributes in rustdoc) - rust-lang#82655 (Highlight identifier span instead of whole pattern span in `unused` lint) - rust-lang#82662 (Warn about unknown doc attributes) - rust-lang#82676 (Change twice used large const table to static) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This is a breaking change, please revert this |
Ah I see, it's done in #82702 |
It wasn't working in the first place, so it's just enforcing something broken by emitting an error instead of doing nothing. The discussion is now in #82702 though. |
I know, that does not matter, this is a breaking change, regardless of whether stuff was broken previously. Stuff was previously broken in a way that did not break compiles. Now tons of projects fail to compile because of their dependencies -- something which they can't easily fix and are forced to just wait for a nightly for. |
I agree that it shouldn't break, but here is a bit of a special case since it was a "runtime" issue that I brought back to compile-time. Tricky problem. I guess that it might be worth it to put it back as hard error in the 2021 edition. Well, to be discussed. At least since #82702, it won't go unnoticed anymore. |
I disagree that this is special, this is like 90% of the future incompat work that rustc does. "Stuff that used to compile but was wrong". Yes, it was wrong, but it was wrong in a way that users of the crate did not have to worry about much. I'm being a bit pointed here, and I hope you don't take it personally, but we all really need to be on the same page when it comes to breaking changes. |
No, I see your point, which is why I'm happy that #82702 was created so quickly afterwards. I mostly wanted it to not go unnoticed, so wether it's a hard error or a warning is both good for me. |
Yeah, I understand, thanks! |
Change error about unknown attributes to a warning Hard errors should go through a future-compatibility phase first, especially since these attributes only have no effect and don't actively cause bugs. Follow-up to rust-lang#82662. Fixes ecosystem breakage like rust-lang/rust-clippy#6832. r? `@GuillaumeGomez`
Fixes #82652.
For the text error, I decided to go for "invalid" instead of "unknown". What do you think?
r? @jyn514