Warn about unknown doc attributes#82662
Conversation
rust-highfive
added
the
S-waiting-on-review
GuillaumeGomez
added
the
T-rustdoc
This comment has been minimized.
This comment has been minimized.
jyn514
added
S-waiting-on-author
GuillaumeGomez
force-pushed
the
doc-attr-check
branch
2 times, most recently
from
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. |
GuillaumeGomez
force-pushed
the
doc-attr-check
branch
from
d089510 to
f6de130
Compare
|
@bors r+ |
|
📌 Commit f6de130 has been approved by |
bors
added
S-waiting-on-bors
…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`
8 participants
Fixes #82652.
For the text error, I decided to go for "invalid" instead of "unknown". What do you think?
r? @jyn514