Skip to content
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

Fix ICE in sugg::DerefDelegate with (named) closures #9120

Merged
merged 1 commit into from
Jul 7, 2022

Conversation

anall
Copy link
Contributor

@anall anall commented Jul 4, 2022

rustc comiler internals helpfully tell us how to fix the issue:

  to get the signature of a closure, use `substs.as_closure().sig()` not `fn_sig()`

Fixes ICE in #9041

This also makes this code in sugg::DerefDelegate match a different use typ.fn_sig(…) I found: in mixed_read_write_in_expression -- being strict on the value of typ.kind() will hopefully reduce any future possibility of ICE crashes in this area.


changelog: none

@rust-highfive
Copy link

r? @flip1995

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Jul 4, 2022
@Jarcho
Copy link
Contributor

Jarcho commented Jul 4, 2022

You can use clippy_utils::ty::expr_sig here. It will also handle impl Fn and dyn Fn types. You would need to either write an iterator for it or access all the arguments by index.

@anall
Copy link
Contributor Author

anall commented Jul 4, 2022

I do have that change prototyped out, but I am not sure how confident I feel in making it, as no tests seem to exercise the ExprKind::MethodCall match branch, which I also need to change for your suggested change.

No tests start failing if I comment out that match branch, allowing the catchall to return false

coreyja added a commit to coreyja/battlesnake-rs that referenced this pull request Jul 5, 2022
coreyja added a commit to coreyja/battlesnake-rs that referenced this pull request Jul 5, 2022
…maxReturn (#25)

* I can parse the response from the engine into a wire game state to use

* Throw clap on it

* Get a version working that I like

* Better output, but I think it helped find a bug

* WIP: Just commiting to pull in new types dep

* Move all the imports from game_types to a crate inside my monorepo

* Change the test to check for the win, cause it might be possible but I picked the wrong path

* Use the git version instead of the local one

* Fix wording

* Only need to run clippy on our code

* Use a version of nightly without the bug. I think this PR resolves it though: rust-lang/rust-clippy#9120

* Fix benches

* The decision point is the first time there is a safe move

* Ehh don't love this for docs, but it's what I need right now I think
@anall
Copy link
Contributor Author

anall commented Jul 6, 2022

Unless I am doing something wrong, expr_sig doesn't seem to handle impl Fn:

fn make_arg_no_deref_impl() -> impl Fn(&&u32) -> bool {
    move |x: &&u32| **x == 78
}

fn main() {
    let v = vec![3,2,1,0];

    let _ = v.iter().find(|x: &&u32| (make_arg_no_deref_impl())(x)).is_none();
}

This ends up with kind being Opaque, which clippy_utils::ty::fn_sig does not handle.
This change currently turns this from what is currently ICE into an invalid suggestion.

Attempting to add support for Opaque to fn_sig does make the search-is-some lint give a correct suggestion.

expr_sig also doesn't seem to handle Boxed dyn Fn.

fn make_arg_no_deref_dyn() -> Box<dyn Fn(&&u32) -> bool> {
    Box::new( move |x: &&u32| **x == 78 )
}

…
let _ = v.iter().find(|x: &&u32| (make_arg_no_deref_dyn())(x)).is_none();
…

This ends up in another incorrect suggestion [with ty.kind being Adt].
If I manually deref the box … (*make_arg_no_deref_dyn())(x) … the involved lint does now give a correct suggestion.

I'm not exactly sure how to handle Box

@Jarcho
Copy link
Contributor

Jarcho commented Jul 6, 2022

By impl Fn() I meant as a function argument. Making opaque types work is a bonus.

Box can be handled by recursing on the inner type in ty_sig. It doesn't handle the general problem of types implementing any of the Fn* traits, but there isn't a stable way to do that.

If you can't make some form work it's fine to leave it broken and open an issue for it. A bad suggestion is still an improvement over an ICE.

@anall anall force-pushed the bugfix/ice9041 branch from 857c4d5 to a8d1661 Compare July 6, 2022 18:33
@Jarcho
Copy link
Contributor

Jarcho commented Jul 7, 2022

Does the change for Box work. It doesn't look like there's a test.

@anall
Copy link
Contributor Author

anall commented Jul 7, 2022

Does the change for Box work. It doesn't look like there's a test.

This was an accidental/incomplete push, but the change does seem to work with the correct test.

@Jarcho
Copy link
Contributor

Jarcho commented Jul 7, 2022

Looks good. You can squash the last couple of commits.

rustc comiler internals helpfully tell us how to fix the issue:

  to get the signature of a closure, use `substs.as_closure().sig()` not `fn_sig()`

Fixes ICE in rust-lang#9041
@anall anall force-pushed the bugfix/ice9041 branch from b215dde to 782b484 Compare July 7, 2022 21:10
@anall
Copy link
Contributor Author

anall commented Jul 7, 2022

Squashed

@Jarcho
Copy link
Contributor

Jarcho commented Jul 7, 2022

Thank you.

@bors r+

@bors
Copy link
Contributor

bors commented Jul 7, 2022

📌 Commit 782b484 has been approved by Jarcho

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jul 7, 2022

⌛ Testing commit 782b484 with merge 2058b92...

@bors
Copy link
Contributor

bors commented Jul 7, 2022

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: Jarcho
Pushing 2058b92 to master...

@flip1995
Copy link
Member

flip1995 commented Jul 8, 2022

Thanks for reviewing this @Jarcho!

@anall anall deleted the bugfix/ice9041 branch July 8, 2022 13:30
@anall
Copy link
Contributor Author

anall commented Jul 8, 2022

Looks like I forgot to flag this commit to close #9041 after being merged, and I can't seem to close that issue myself.

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.

5 participants