-
Notifications
You must be signed in to change notification settings - Fork 13.6k
WIP inherited deprecation fixes #26040 #26061
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
Conversation
cc @brson if you have an opinion |
Patch looks ok to me. I'm curious what impacts this had on the deprecatedness of std. Did anything new get deprecated? |
Oh, there's a weird case in this patch: since it applies the parent deprecation tag, it could potentially apply the deprecation tag from one feature to a different feature, which is pretty bogus. It could possibly also apply a deprecated tag to something without an explicit stability level at all, which is illegal. It's not likely to happen in sane code, but it could. You might add more conditions that the parent has the same stability level and feature. |
Yeah I wasn't sure how "no stability" was supposed to interact here. I'm not sure what you mean about one feature getting the deprecation of another. It seems like if I deprecate a whole module, anything in there should inherit that, regardless of what features its under? Would you be able to provide some test cases/examples of what you're imagining? |
The concern about accidentally deprecating multiple features isn't as important as I was thinking, since features can be partially deprecated, and deprecations can happen during any version. Here's one example where inheritance crosses features and could cause incorrect deprecation.
With deprecation inheritance, if There's a current rule that says that anything marked deprecated, must also be explicitly marked unstable or stable. This is to prevent unstable+deprecated things accidentally making their way into stable releases by becoming stable+deprecated. With stable not inheriting though the only error I can think of making would be accidentally tagging something that has inherited deprecation with stable. Imagine:
Then mod
Now part of feature 'bar' is unstable. Then five years later somebody says, 'bar' is finally stable. So they convert all the unstable bars to stable bars, without thinking about it too hard:
Now they've created a stable function that is immediately deprecated. That's the only problematic counter-example i can think of offhand. |
Since deprecations and stable are marked with a On Mon, Jun 8, 2015 at 10:41 AM, Brian Anderson [email protected]
|
@gankro, yes, assuming the person who switches the function from |
Oh, |
updated to validate stability against deprecation version. |
@bors r+ |
📌 Commit 2962b26 has been approved by |
Uncertain if this is the desired effect/strategy/testing. r? @aturon
Uncertain if this is the desired effect/strategy/testing.
r? @aturon