Closed matthiaskrgr closed 5 years ago
I think this is a rustc
problem, since clippy appears in the backtrace only by calling rustc_driver::run_compiler()
everything else is rustc
related.
There was a similar issue that was moved from rustc to clippy https://github.com/rust-lang/rust/issues/49114#issuecomment-376600564
Yes it seems to be the same error again as in #2580.
Hmm, maybe this is the same as #2831 ? // cc @phansch who said would look at 2831
Woops, #2831 fell under my radar. Both seem type inference related.
This is a different issue than #2831, but it seems to work on the playground now: https://play.rust-lang.org/?gist=c285598e88463061408310dddd738b41&version=nightly&mode=debug&edition=2018
So, this doesn't crash anymore it seems. In order to close the issue, it would be good to add a regression test to our run-pass suite.
If someone want's to pick this up as their first issue, I'm happy to write some more instructions if needed.
@phansch it's still crashing for me :/
@matthiaskrgr huh, weird. In the playground it's not crashing for me:
I will try it out locally later today
My guess is it crashes on a lint that is not enabled by default and thus seems to work on playground.
Now I can make it crash locally, just not in the playground. It also crashes if I have allowed all Clippy lints, so I think the cause is somewhere in the glue between Clippy and Rust. Maybe an incorrect configuration somewhere?
I managed to reduce the code a bit further:
use std::collections::HashSet;
fn is_sync<T>(_: T) where T: Sync {}
fn main() {
is_sync(HashSet::<usize>::new());
}
It's probably also worth investigating why it doesn't crash on play.rust-lang.org. I will start with that tomorrow.
(This was at 3971c424)
One more thing I want to check:
I've put the code into a new cargo project, ran cargo clippy
(b1d0343 2018-10-19) and it passed.
cargo new i3144
tee i3144/src/main.rs << END
use std::collections::HashSet;
fn is_sync<T>(_: T) where T: Sync {}
fn main() {
is_sync(HashSet::<usize>::new());
}
END
cd i3144
cargo clippy
Mh yeah, I am getting that too. It crashes when directly running clippy-driver on it, but does not when running cargo clippy
on it ... :confused:
So the playground is probably using cargo clippy
and therefore it doesn't crash.
I experimented with src/driver.rs
and found that commenting out the register_late_pass
line doesn't crash it anymore:
I was now able to to isolate the cause by commenting out the various late lint passes. Although it doesn't show up in the backtrace, it seems to be caused somewhere in the needless_pass_by_value
lint.
Some more progress. The ICE is triggered from this invocation of implements_trait
:
The full and exact error message is:
failed to lift:
QueryResponse {
var_values: CanonicalVarValues { var_values: [] },
region_constraints: [
Binder(OutlivesPredicate(ReLateBound(DebruijnIndex(1), BrAnon(0)), ReErased)),
Binder(OutlivesPredicate(ReLateBound(DebruijnIndex(1), BrAnon(1)), ReErased)),
Binder(OutlivesPredicate(ReErased, ReLateBound(DebruijnIndex(1), BrAnon(0)))),
Binder(OutlivesPredicate(ReErased, ReLateBound(DebruijnIndex(1), BrAnon(1))))
],
certainty: Proven,
value: NormalizationResult { normalized_ty: std::collections::hash_map::RandomState }
}
canonicalized from:
QueryResponse {
var_values: CanonicalVarValues { var_values: [] },
region_constraints: [
Binder(OutlivesPredicate('_#0r, ReErased)),
Binder(OutlivesPredicate('_#1r, ReErased)),
Binder(OutlivesPredicate(ReErased, '_#0r)),
Binder(OutlivesPredicate(ReErased, '_#1r))
],
certainty: Proven,
value: NormalizationResult { normalized_ty: std::collections::hash_map::RandomState }
}
which is emitted here: https://github.com/rust-lang/rust/blob/710ddc151baf9750e074229b8bdc794d63246eb8/src/librustc/infer/canonical/canonicalizer.rs#L481-L486
File https://github.com/rust-lang/rust/blob/master/src/test/run-pass/sync-send-iterators-in-libcollections.rs
reduced:
backtrace:
clippy 63a46b1e1a9a4cc3d78e1cf7a628421051c21167 Found via https://github.com/rust-lang-nursery/rust-clippy/issues/3142