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

Cargo fix --edition leads to "error: overflow while checking ... requires drop" #90147

Closed
Renmusxd opened this issue Oct 21, 2021 · 9 comments
Closed
Labels
A-closures Area: Closures (`|…| { … }`) A-edition-2021 Area: The 2021 edition C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Renmusxd
Copy link

Renmusxd commented Oct 21, 2021

Problem

Running cargo fix --edition on the crate qip=0.15.3 leads to an error:

$ cargo fix --edition
    Checking qip v0.15.3 (.../git/RustQIP)
   Migrating src/lib.rs from 2018 edition to 2021
error: overflow while checking whether `feynman_state::state::FeynmanState<P>` requires drop

error: could not compile `qip` due to previous error
warning: build failed, waiting for other jobs to finish...
error: overflow while checking whether `FeynmanState<P>` requires drop

error: build failed

Building and running cargo check on either edition works fine however.

I will try to make a simplified minimal example soon but needed to run and figured I'd report this then come back to it.

Thanks for all the work on the new version!

Steps

  1. Download crate from github
  2. Run cargo fix --edition

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.56.0 (4ed5d137b 2021-10-04)
release: 1.56.0
commit-hash: 4ed5d137baff5eccf1bae5a7b2ae4b57efad4a7d
commit-date: 2021-10-04
@ehuss ehuss transferred this issue from rust-lang/cargo Oct 21, 2021
@ehuss
Copy link
Contributor

ehuss commented Oct 21, 2021

Thanks for the report! I have transferred this to the rust-lang/rust repository since this is a rustc error.

This is similar to #90142, though I'm surprised to not see an ICE message. This may also be related to #90024, though I'm not sure.

Whatever you can do to construct a simplified repro would be appreciated.

cc @rust-lang/wg-rfc-2229

@ehuss ehuss added A-edition-2021 Area: The 2021 edition C-bug Category: This is a bug. A-closures Area: Closures (`|…| { … }`) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed A-edition-2021 Area: The 2021 edition labels Oct 21, 2021
@Renmusxd
Copy link
Author

Creating a new main.rs file with feynman_state::state::FeynmanState<P> and all its dependencies does not reproduce the error. I will need to clone the whole file structure and trim things off one at a time. This may take a little while - sorry.

@Renmusxd
Copy link
Author

Here's a working example in a single file, turns out it wouldn't reproduce the bug in a main.rs file but does reproduce in a lib.rs:

https://github.com/Renmusxd/RustQIP_ICE

@lqd
Copy link
Member

lqd commented Oct 21, 2021

I had the very similar

#![warn(rust_2021_incompatible_closure_captures)]

struct Complex<T>(T);
pub struct FeynmanState<P> {
    _substate: Vec<Vec<Complex<P>>>,
}
impl<P> FeynmanState<P> {
    pub fn calculate_amplitude(&self) -> () {
        todo!()
    }
    pub fn into_state(self) {
        || self.calculate_amplitude();
    }
}

fn main() {
}

It's probably from

&format!("overflow while checking whether `{}` requires drop", self.query_ty),

@camelid
Copy link
Member

camelid commented Oct 22, 2021

Note that it doesn't ICE, and thus there are no backtrace, but it's probably from

@lqd If you pass -Z treat-err-as-bug it should give you a backtrace :)

@lqd
Copy link
Member

lqd commented Oct 22, 2021

@camelid I know, this was keeping the reproduction the same as the OP: via cargo fix. To turn this into a rustc failure, or UI test, you'd need to also warn on rust_2021_incompatible_closure_captures or use some of the flags it passes rustc.

@camelid
Copy link
Member

camelid commented Oct 22, 2021

@lqd Ah, I see 👍

@JakobDegen
Copy link
Contributor

This is indeed a duplicate of #90024

@ehuss
Copy link
Contributor

ehuss commented Oct 29, 2021

Closing as this now appears to be fixed by #90218.

@ehuss ehuss closed this as completed Oct 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-closures Area: Closures (`|…| { … }`) A-edition-2021 Area: The 2021 edition C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants