-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
give some suggestion for returning anonymous enum #100988
Conversation
should we create a crate for some util functions like |
f615844
to
ca90121
Compare
This comment has been minimized.
This comment has been minimized.
ca90121
to
d436357
Compare
d436357
to
bac60db
Compare
"SomeEnum", | ||
Applicability::HasPlaceholders, | ||
) | ||
.note(suggestion_code); |
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.
Instead of the note with the enum, we could instead use a multipart_suggestion
and pass in the span for the space right at the start of the item, so that the output can be
error: anonymous enums are not supported
--> $DIR/issue-100741-return-anonymous-enum.rs:3:17
|
LL | fn foo<'a>() -> i32 | Vec<i32> | &str | &'a String | Foo {
| ^ ^ ^ ^ not supported in types
|
help: consider using enum as return type
|
LL + enum SomeEnum<'lifetime,'a>{
LL + I32(i32)
LL + Vec(Vec<i32>)
LL + StrRef(&'lifetime str)
LL + StringRef(&'a String)
LL + Foo(Foo)
LL + }
LL ~ fn foo<'a>() -> SomeEnum<'_, 'a> {
|
err.span_suggestion( | ||
span, | ||
"consider using enum as return type", | ||
"SomeEnum", |
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.
You need to account for the lifetimes that were mentioned. In the test included, this would end up being '_, 'a
.
|
||
if let Some(_args) = &seg.args { | ||
ty_string.push('<'); | ||
ty_string.push_str("..."); |
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.
Why don't we print the whole type?
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.
it's more complicated, for example Vec<impl Send> | Vec<(i32, i64)>
. We can not make a enum variant name for these type.
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.
As you propose, we can use Variant{N}
as the variant name
let mut ty_string = String::new(); | ||
|
||
if let Some(seg) = path.segments.iter().last() { | ||
name.push_str(seg.ident.name.as_str()); |
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.
It feels like the only thing we need here is the name
and for ty_string
format!("{ty}")
is enough, after folding the anon lifetimes to be named as 'lifetime
, in way similar to what is done here:
rust/compiler/rustc_middle/src/ty/erase_regions.rs
Lines 56 to 69 in c3fce8e
fn fold_region(&mut self, r: ty::Region<'tcx>) -> ty::Region<'tcx> { | |
// because late-bound regions affect subtyping, we can't | |
// erase the bound/free distinction, but we can replace | |
// all free regions with 'erased. | |
// | |
// Note that we *CAN* replace early-bound regions -- the | |
// type system never "sees" those, they get substituted | |
// away. In codegen, they will always be erased to 'erased | |
// whenever a substitution occurs. | |
match *r { | |
ty::ReLateBound(..) => r, | |
_ => self.tcx.lifetimes.re_erased, | |
} | |
} |
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.
emmm, the TyKind
in rustc_ast doesn't implement Display
, if it's nesscery to implement Display
, I will submit a new pull request to do that.
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.
I'm fairly certain there's a way to pprint
TyKind
, but it isn't through Display
directly 🤔
None | ||
} | ||
} | ||
_ => None, |
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 wouldn't work for something like -> [i32; 10] | Vec<i32>
, right?
If you don't want to support every TyKind
, you can at least provide a Variant{N}
name
so that the suggested enum
makes syntactic sense.
let mut tys = vec![]; | ||
let lo = self.token.span; | ||
loop { |
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 issue with this that we shouldn't recover this only for return types, we should be doing this further down, in parse_ty_common
, maybe adding another argument to it to explicitly state what should be coming after it (to support things like let foo: A | B = ...;
).
u.next().is_some() | ||
} | ||
|
||
pub fn to_camel_case(s: &str) -> String { |
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.
fn to_camel_case(s: &str) -> String { |
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.
but it's in crate rustc_lint
. I think it's weird to make rustc_parse
depend rustc_lint
. Should we create a crate rustc_utils
for these functions like to_camel_case
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.
We could move this to a shared dependency of the two, like rustc_errors
.
☔ The latest upstream changes (presumably #107314) made this pull request unmergeable. Please resolve the merge conflicts. |
any updates here? we have to be very careful to not recover on the happy path as to not cause further regressions |
sorry, I am not working on it currently |
☔ The latest upstream changes (presumably #109128) made this pull request unmergeable. Please resolve the merge conflicts. |
Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks |
give some suggestion for returning anonymous enum
fix #100741
r? @estebank