-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Specialize infinite-type "insert some indirection" suggestion for Option #91416
Specialize infinite-type "insert some indirection" suggestion for Option #91416
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding getting the right span, the correct thing to do would be to somehow get the appropriate hir::Ty
node so that you can get the appropriate span. The hacky second option is to use the snippet and string manipulation to try and find the span edges manually. This final option is to do what you've done here. The last two will have trouble when it comes to macros modifying the user written token stream.
Can you add a FIXME
comment above the special casing of the option to mention something along the lines of "figure out a way to get the correct span and be resilient to type renaming of both Option and Box"? r=me after that.
LL | struct Foo { foo: Option<Box<Option<Foo>>> } | ||
| ~~~~~~~~~~~~~~~~~~~~~~~~ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test case shows a place where the approach breaks down slightly :)
ty::Adt(def, args) if Some(def.did) == tcx.get_diagnostic_item(sym::Option) => { | ||
vec![( | ||
span, | ||
format!("Option<Box<{}>>", args.iter().next().unwrap().expect_ty()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem I see with this is that it will cause trouble with any situation where Option
has been either shadowed or been locally renamed. Of course, we could make the same argument about Box
in the original...
a9cbe20
to
50aab97
Compare
This comment has been minimized.
This comment has been minimized.
50aab97
to
c322167
Compare
Added |
c322167
to
bbda904
Compare
So I reformulated this to work with the HirId of the struct field, instead of it's spanless TyS. This gives us the right span information to turn an Added a few other test cases as well. @estebank, do you mind taking a look at this sometime? Thanks! |
☔ The latest upstream changes (presumably #92070) made this pull request unmergeable. Please resolve the merge conflicts. |
bbda904
to
c9ca08e
Compare
☔ The latest upstream changes (presumably #90146) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for the delay. r=me after rebasing.
compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
Outdated
Show resolved
Hide resolved
compiler/rustc_trait_selection/src/traits/error_reporting/mod.rs
Outdated
Show resolved
Hide resolved
c9ca08e
to
5f9b774
Compare
ready for an r+ i think! @rustbot ready |
5f9b774
to
c74f7a3
Compare
rebased and re-tested @bors r=estebank rollup |
📌 Commit c74f7a3 has been approved by |
Rollup of 5 pull requests Successful merges: - rust-lang#91416 (Specialize infinite-type "insert some indirection" suggestion for Option) - rust-lang#95384 (Update target_has_atomic documentation for stabilization) - rust-lang#95517 (small rustc_borrowck cleanup) - rust-lang#95520 (Fix typos in core::ptr docs) - rust-lang#95523 (remove unused field from `infcx`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Suggest
Option<Box<_>>
instead ofBox<Option<_>>
for infinitely-recursive members of a struct.Not sure if I can get the span of the generic subty of the Option so I can make this a
+++
-style suggestion. The current output is a tiny bit less fancy looking than the original suggestion.Should I limit the specialization to just
Option<Box<TheOuterStruct>>
? Because right now it applies to allOption
members in the struct that are returned byRepresentability::SelfRecursive
.Fixes #91402
r? @estebank
(since you wrote the original suggestion and are definitely most familiar with it!)