Refactor attr::Stability #29014
Refactor attr::Stability #29014
Conversation
Stricter checking + enforcement of invariants at compile time
|
@petrochenkov Unfortunately I am about to disappear for a while on paternity leave. @brson, @huonw or @alexcrichton, can one of you review this PR please? |
|
Sure thing, I'll take over. |
|
Thanks for refactoring this. It's a lot better. This code has really been through the ringer. |
|
Your PR message says this makes checking stricter. I saw that it now disallows unknown meta items in the stability attributes. What else does it do to strengthen the checking? |
The changes can mostly be noticed in tests (old and one new) - unknown meta items, duplicated meta items, |
|
@brson |
|
Thanks, I added just one more question, reproduced here: what happens when there are both unstable and deprecated reasons. Does the unstable reason silently get overwritten? What was the previous behavior? |
Previously unstable reason was overwritten by deprecated reason, now they are both kept, but rustdoc displays the deprecated reason as before. |
|
@bors r+ |
|
📌 Commit 704d598 has been approved by |
Stricter checking of stability attributes + enforcement of their invariants at compile time (+ removed dead file librustc_front/attr.rs) I intended to enforce use of `reason` for unstable items as well (it normally presents for new items), but it turned out too intrusive, many older unstable items don't have `reason`s. r? @aturon I'm studying how stability works and do some refactoring along the way, so it's probably not the last PR.
Stricter checking of stability attributes + enforcement of their invariants at compile time
(+ removed dead file librustc_front/attr.rs)
I intended to enforce use of
reasonfor unstable items as well (it normally presents for new items), but it turned out too intrusive, many older unstable items don't havereasons.r? @aturon
I'm studying how stability works and do some refactoring along the way, so it's probably not the last PR.