minor : Deunwrap inline call #15432
minor : Deunwrap inline call #15432
Conversation
rustbot
added
the
S-waiting-on-review
Veykril
added
S-waiting-on-author
|
So while I do not claim to understand why the assist became non-lazy after this PR, I applied the requested changes hoping that these also resolve the said problem. |
| @@ -218,13 +219,12 @@ pub(crate) fn inline_call(acc: &mut Assists, ctx: &AssistContext<'_>) -> Option< | |||
| } | |||
|
|
|||
| let syntax = call_info.node.syntax().clone(); | |||
| let replacement = inline(&ctx.sema, file_id, function, &fn_body, ¶ms, &call_info)?; | |||
There was a problem hiding this comment.
So while I do not claim to understand why the assist became non-lazy after this PR
Assists run in two modes: once to determine if they are available, and once to actually apply the changes, if the user picks one. Both modes use mostly the same code paths, but the |builder| closure actually determines the changes. This means that everything that happens outside that closure is performance-sensitive.
There was a problem hiding this comment.
thanks for the explanation
|
CI probably needs a |
alibektas
force-pushed
the
deunwrap/inline_call
branch
from
94afbe3
to
38491fc
Compare
|
@rustbot review |
rustbot
added
S-waiting-on-review
|
@bors r+ |
minor : Deunwrap inline call #15398 subtask 4. There is still one instance of unwrap, which I found pretty hard to change.
|
☀️ Test successful - checks-actions |
|
👀 Test was successful, but fast-forwarding failed: 422 1 review requesting changes by reviewers with write access. |
|
@bors r+ |
|
💡 This pull request was already approved, no need to approve it again.
|
|
☀️ Test successful - checks-actions |
#15398 subtask 4. There is still one instance of unwrap, which I found pretty hard to change.