Skip to content

Conversation

@Giga-Bowser
Copy link
Contributor

@Giga-Bowser Giga-Bowser commented Oct 13, 2024

I pretty much just copied over the code and tests for wrapping/unwrapping return types in Result and then did a bunch of find and replace changes.

I handled unwrapping statements returning None by just replacing None with the unit type, but I'm open to suggestions for more intuitive behavior here.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 13, 2024
Copy link
Member

@Veykril Veykril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, there shouldn't be a need to fully duplicate the two modules. I'd expect us to be able to re-use a lot of code here and abstract it over Option/Result

@Giga-Bowser
Copy link
Contributor Author

That's a good point, I'll start working on that tonight.

@Giga-Bowser
Copy link
Contributor Author

Let me know if there's anything else you want to see changed. I'm not really sure what the precedent is for when to group assists, so I decided to leave them separate, but I'm open to suggestions for that as well.

Copy link
Member

@Veykril Veykril left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally good to me, just raising 2 perf things that would be good to fix

}
}

fn wrap_return_type(acc: &mut Assists, ctx: &AssistContext<'_>, kind: WrapperKind) -> Option<()> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way this is setup we do this work twice now (always), might be better to only have one entry point, do the filtering logic once and then add both assists at once. We also probably want to group the two assist under one assist group (label being something "Wrap return type in ...").

unwrap_return_type(acc, ctx, UnwrapperKind::Result)
}

fn unwrap_return_type(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In similar fashion we can combine the entry points here to one and then check for either types after resolve_type to figure out which one is applicable

@Giga-Bowser
Copy link
Contributor Author

Sounds good, I'll get that wrapped up today.


let kind = UnwrapperKind::ALL
.iter()
.find(|k| matches!(k.core_type(&famous_defs), Some(core_type) if ret_enum == core_type))?;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this seems a bit too dense I could easily rewrite this as an if that checks against each UnwrapperKind individually, just let me know.

@Veykril
Copy link
Member

Veykril commented Oct 21, 2024

Thanks!
@bors r+

@bors
Copy link
Contributor

bors commented Oct 21, 2024

📌 Commit 2c82386 has been approved by Veykril

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Oct 21, 2024

⌛ Testing commit 2c82386 with merge 546da8a...

@bors
Copy link
Contributor

bors commented Oct 21, 2024

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 546da8a to master...

@bors bors merged commit 546da8a into rust-lang:master Oct 21, 2024
10 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants