Do not treat lifetimes from parent items as influencing child items #139075
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
compiler-errors
approved these changes
Mar 28, 2025
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 28, 2025
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#138976 (Explain one-past-the-end pointer in std library) - rust-lang#139052 (Put pin!() tests in the right file.) - rust-lang#139058 (Fix formatting nit in process.rs) - rust-lang#139063 (Fix TAIT & ATPIT feature gating in the presence of anon consts) - rust-lang#139065 (Miri subtree update) - rust-lang#139069 (`io::Take`: avoid new `BorrowedBuf` creation in some case) - rust-lang#139075 (Do not treat lifetimes from parent items as influencing child items) - rust-lang#139079 (tracking autodiff files via triagebot.toml) Failed merges: - rust-lang#139044 (bootstrap: Avoid cloning `change-id` list) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 29, 2025
Rollup merge of rust-lang#139075 - oli-obk:resolver-item-lifetime, r=compiler-errors Do not treat lifetimes from parent items as influencing child items ```rust struct A; impl Bar<'static> for A { const STATIC: &str = ""; // ^ no future incompat warning } ``` has no future incompat warning, because there is no ambiguity. But ```rust struct C; impl Bar<'_> for C { // ^^ this lifeimte const STATIC: &'static str = { struct B; impl Bar<'static> for B { const STATIC: &str = ""; // causes ^ to emit a future incompat warning } "" }; } ``` had one before this PR, because the impl for `B` (which is just a copy of `A`) thought it was influenced by a lifetime on the impl for `C`. I double checked all other `lifetime_ribs` iterations and all of them do check for `Item` boundaries. This feels very fragile tho, and ~~I think we should do not even be able to see ribs from parent items, but that's a different refactoring that I'd rather not do at the same time as a bugfix~~. EDIT: ah nevermind, this is needed for improving diagnostics like "use of undeclared lifetime" being "can't use generic parameters from outer item" instead. r? `@compiler-errors`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
has no future incompat warning, because there is no ambiguity. But
had one before this PR, because the impl for
B(which is just a copy ofA) thought it was influenced by a lifetime on the impl forC.I double checked all other
lifetime_ribsiterations and all of them do check forItemboundaries. This feels very fragile tho, andI think we should do not even be able to see ribs from parent items, but that's a different refactoring that I'd rather not do at the same time as a bugfix. EDIT: ah nevermind, this is needed for improving diagnostics like "use of undeclared lifetime" being "can't use generic parameters from outer item" instead.r? @compiler-errors