jiebi/CodeConvo huggingface dataset:
Code change:
use rustc_ast::{self as ast, NodeId, CRATE_NODE_ID}; use rustc_ast::{AngleBracketedArg, Crate, Expr, ExprKind, GenericArg, GenericArgs, LitKind, Path}; use rustc_ast_lowering::{LifetimeRes, ResolverAstLowering}; <del> use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexMap}; </del> <ins> use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexMap, FxIndexSet}; </ins> use rustc_data_structures::intern::Interned; use rustc_data_structures::sync::Lrc; use rustc_errors::{Applicability, DiagnosticBuilder, ErrorGuaranteed};

Related discussion:
text: The resolver gathers a list of possibly unused trait imports in . This list is passed to resolver outputs, into the query. This query takes a and returns whether the import is possibly unused. This is used by the post-typeck unused import check in . This query iterates over all the statements in the crate, checks whether they may be unused trait imports, and warns if they are indeed unused. As there are typically very few unused trait imports compared to the number of items in a crate, it would make sense to directly iterate on . Steps: make an both in and , this will ensure a deterministic iteration order; rename query and give it the signature , and adapt the call site; we do not want to access directly, as this would prevent the query system from detecting that the set has not changed; in , inline and replace the loop over by a loop over ; the filter over there can be removed too (or replaced by a debug-assertion): the set may only point to use statements. Extra: investigate why we check for , and the consequences of removing that check; investigate the impact on perf of converting the to a simple when producing from . I am available on Zulip for any question. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
are you still working on this?
Hello yes sorry for the super slow pace. I am still working on it (mostly reading the rustc dev guide so far). Is that alright or is it important to get this done quickly?
no worries, I am a beginner looking for tasks, hence the qn.
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^ one type is more general than the other | = note: expected type `std::ops::FnOnce<(&'x str,)>` found type `std::ops::FnOnce<(&str,)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: Reproduction branch: When applying the change from the last commit I get a panic in my code during the call to . <details<summaryBacktrace</summary</details
Cannot reproduce on my linux. Can you provide a small ? Is that possible? Maybe without all the externals :/
I can reproduce a very similar problem (appears to involve the same origin and failing assertion of ) compiling rust-lang/regex with and compiler flags: For me, setting to 2 or greater is required to present this failure. <details<summarybacktrace</summary<code<preRUSTBACKTRACE=1 cargo build Compiling regex v1.1.2 (/home/kent/rust/regex) thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32', stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwindbacktrace at 1: std::syscommon::backtrace::print at 2: std::panicking::defaulthook::{{closure}} at at 3: std::panicking::defaulthook at 4: rustc::util::common::panichook 5: std::panicking::rustpanicwithhook at 6: std::panicking::beginpanic 7: syntax::sourcemap::SourceMap::bytepostofilecharpos 8: syntax::sourcemap::SourceMap::lookupcharpos 9: <rustccodegenssa::mir::FunctionCx<'a, 'tcx, Bx::scopemetadataforloc 10: <rustccodegenssa::mir::FunctionCx<'a, 'tcx,
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^ one type is more general than the other | = note: expected type `std::ops::FnOnce<(&'x str,)>` found type `std::ops::FnOnce<(&str,)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: Bx::debugloc 11: rustccodegenssa::mir::codegenmir 12: rustccodegenssa::base::codegeninstance 13: rustccodegenssa::monoitem::MonoItemExt::define 14: rustccodegenllvm::base::compilecodegenunit::modulecodegen 15: rustc::depgraph::graph::DepGraph::withtask 16: rustccodegenllvm::base::compilecodegenunit 17: rustccodegenssa::base::codegencrate 18: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 19: rustc::util::common::time 20: rustcdriver::driver::phase4codegen 21: rustcdriver::driver::compileinput::{{closure}} 22: <std::thread::local::LocalKey<T::with 23: rustc::ty::context::TyCtxt::createandenter 24: rustcdriver::driver::compileinput 25: rustcdriver::runcompilerwithpool 26: <scopedtls::ScopedKey<T::set 27: rustcdriver::runcompiler 28: syntax::withglobals 29: rustmaybecatchpanic at 30: <F as alloc::boxed::FnBox<A::callbox 31: std::sys::unix::thread::Thread::new::threadstart at at at 32: <unknown33: clone query stack during panic: end of query stack error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: rustc 1.34.0-nightly ( 2019-02-26) running on x86_64-unknown-linux-gnu note: compiler flags: -Z mir-opt-level=2 -C debuginfo=2 -C incremental --crate-type lib </pre</code</details
With the help of , I've found a tiny test that reproduces this crash on Linux and Mac:
Got another one: <details</detailsHappens when compiling regex tests with and calling on every span found in the mir of the functions needing codegen.
According to glaicer, the ICE from this example has been gone.
can you confirm that your example does not crash on nightly anymore?
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^ one type is more general than the other | = note: expected type `std::ops::FnOnce<(&'x str,)>` found type `std::ops::FnOnce<(&str,)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: Has been fixed in
is likely the part of the rollup fixing it.
Shouldn't a testcase be instead of closing this?
A similar crash that still happens:
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-30906.rs:15:5 | LL |     test(Compose(f, |_| {})); |     ^^^^ one type is more general than the other | = note: expected type `std::ops::FnOnce<(&'x str,)>` found type `std::ops::FnOnce<(&str,)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with
Code change:
} types::ItemEnum::Method(_) <ins> | types::ItemEnum::Module(_) </ins> | types::ItemEnum::AssocConst { .. } | types::ItemEnum::AssocType { .. } | types::ItemEnum::PrimitiveType(_) => true, <del> types::ItemEnum::Module(_) | types::ItemEnum::ExternCrate { .. } </del> <ins> types::ItemEnum::ExternCrate { .. } </ins> | types::ItemEnum::Import(_) | types::ItemEnum::StructField(_) | types::ItemEnum::Variant(_)

Related discussion:
text: Found via and seems like a different issue than with rustdoc JSON is built labels +A-rustdoc-json +T-rustdoc +I-ICE +requires-nightly +E-needs-mcve
MCVE: ` modify labels: -E-needs-mcve
Code change:
create_default_session_globals_then(|| { let comment = "n let a: *i32;n *a = 5;n"; let stripped = beautify_doc_string(Symbol::intern(comment), CommentKind::Block); <del> assert_eq!(stripped.as_str(), " let a: *i32;n *a = 5;"); </del> <ins> assert_eq!(stripped.as_str(), "let a: *i32;n*a = 5;"); </ins> }) }

Related discussion:
text: Hi, I've just published a new version of my crate and the generated documentation is including a lot of bullet points that have never been included before. When I generate the docs locally on the 1.8.1 source code using the latest stable version of rust I see the same formatting for the 1.8.0 that generated, so I think this is a bug that's slipped into the nightly version of Stable local docs: ! ! My guess is that it's because I'm using block comments, the unwanted bullet points seem to match up with empty lines in the documentation comment which consist of just a . Thanks
Seems potentially related to , but the latest builds were from a nightly that should have that fixed in; cc you probably have some idea on where the issue is.
This is highly surprising indeed. Can you run with the last nightly locally and tell us if it reproduces the bug please? If so, I'll try to check what's wrong in rustdoc.
I have ran cargo doc on the latest nightly locally (nightly-x86_64-unknown-linux-gnu rustc 1.60.0-nightly ( 2022-01-20)) and it has reproduced the bug - I see the same generated docs as from the build.
It'll be fixed by
Thanks, is there any way I can get to rebuild the docs for the affected versions or will I have to submit a new version of my library to get a fixed build?
Sure. But that for that, please open an issue on repository directly.
Code change:
LL |         for _ in &self.h { |                  + <del> error: aborting due to 2 previous errors </del> <ins> error[E0507]: cannot move out of a shared reference --> $DIR/for-i-in-vec.rs:21:19 | LL |     for loader in *LOADERS { |                   ^^^^^^^^ move occurs because value has type `Vec<&u8>`, which does not implement the `Copy` trait | help: consider iterating over a slice of the `Vec<&u8>`'s content | LL |     for loader in &*LOADERS { |                   + error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0507`.

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Haven't minimized the code yet, but the exact code is up here: It's a kind of search algorithm. I think the problematic code is the function in . Will report back if I figure out anything more. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsI just switched to the stable toolchain, and the compilar gave me two errors: Apparently these were not caught by the nightly compiler.
This is probably a duplicate of You're using the nightly compiler though, so working as intended
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
LL |         for _ in &self.h { |                  + <del> error: aborting due to 2 previous errors </del> <ins> error[E0507]: cannot move out of a shared reference --> $DIR/for-i-in-vec.rs:21:19 | LL |     for loader in *LOADERS { |                   ^^^^^^^^ move occurs because value has type `Vec<&u8>`, which does not implement the `Copy` trait | help: consider iterating over a slice of the `Vec<&u8>`'s content | LL |     for loader in &*LOADERS { |                   + error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0507`.

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Compiles with replaced for <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I got the same issue on the latest nightly and on , without using rustc-private The commented out block was used originally and triggers the ICE as well.
searched nightlies: from nightly-2021-07-29 to nightly-2021-08-02 regressed nightly: nightly-2021-07-31 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-pc-windows-msvc Reproduce with: </detailsI think this might have been introduced by , in particular this piece of code:
If that's indeed caused by then we should let its author know:
Just checked and thankfully .
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Code change:
<del> Subproject commit 61605ebde25f920b18cc2f7e1b92838cd7b6fa67 </del> <ins> Subproject commit 05fdec916a3a9755c6ea603bab79cdb2f7c062bf </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Code change:
<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // Test that we cannot create objects from unsized types. trait Foo for Sized? {} impl Foo for str {} fn test<Sized? T: Foo>(t: &T) { let u: &Foo = t; //~^ ERROR `core::kinds::Sized` is not implemented for the type `T` let v: &Foo = t as &Foo; //~^ ERROR `core::kinds::Sized` is not implemented for the type `T` } fn main() { let _: &[&Foo] = &["hi"]; //~^ ERROR `core::kinds::Sized` is not implemented for the type `str` let _: &Foo = "hi" as &Foo; //~^ ERROR `core::kinds::Sized` is not implemented for the type `str` } </ins>

Related discussion:
text: cc
cc too, presumably a consequence of the trait reform/new vtable lookup code
Hmm, yes. Probably we can fix this by just...allowing it to skolemize an open existential type. I just didn't expect this to ever happen.
actually, while debugging this I remembered that it is not possible to make an object out of an unsized type. We need to add a check for this I guess!
Explanation from PR: In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the self value and the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is self a thin or fat pointer?), which of course it doesn't.
Code change:
// was not actually bumped past it. When the `LazyAttrTokenStream` gets converted // into an `AttrTokenStream`, we will create the proper token. if self.token_cursor.break_last_token { <del> assert_eq!( trailing, TrailingToken::None, "Cannot set `break_last_token` and have trailing token" ); </del> <ins> assert!(!captured_trailing, "Cannot set break_last_token and have trailing token"); </ins> end_pos += 1; }

Related discussion:
text: Found with The attribute applies to The was initially lexed as part of a token This seems to be exactly the case described by the : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you have any suggestion for this case? The code path is going like this: Parser eat the first one of '' at here and set : fall pass at here: So this assertion is failed: The result is: and is true. Seems the assertion missed this scenario, do we need to add a TrailingToken::Gt ?
The assertion I wrote is overly conservative - it really just needs to check that we don't simultaneously break a token and 'really' capture a trailing token. Specifically, we only need to panic if we actually incremented in the match block. I think the simplest fix would be to add a variable, which gets set to in the parts of the block that increment . The assertion can then be changed to breaklasttoken
Code change:
<ins> // check-pass // compile-flags: -Zsave-analysis trait Trait { type Assoc; } trait GenericTrait<T> {} struct Wrapper<B> { b: B } fn func() { // Processing associated path in impl block definition inside a function // body does not ICE impl<B: Trait> GenericTrait<B::Assoc> for Wrapper<B> {} } fn main() {} </ins>

Related discussion:
text: While compiling rayon:
cc
triage: P-high, assigning to . Removing nomination label.
The fact that this bug was unknown until now strikes me as a sign that we have never attempted to run on the rustc test suite (i.e. compiletest). is this true? Would it be worthwhile to attempt that experiment?
I'm not sure if this is the correct approach, but I just executed the with the following patch applied: and the test suite did crash/ended up all green. It might be a good idea to always run the tests along with save-analysis passed. Should that be optionally enabled? Should we run it, e.g. in the container?
Code change:
<ins> error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:5:70 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                                                                      ^^ undeclared lifetime | help: consider introducing lifetime `'a` here | LL |     fn const_chunks_exact<'a, const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |                           +++ help: consider introducing lifetime `'a` here | LL | trait ConstChunksExactTrait<'a, T> { |                             +++ error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-unexpected-inference-var-122549.rs:11:34 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         -        ^^ undeclared lifetime |                         | |                         help: consider introducing lifetime `'a` here: `'a,` error[E0046]: not all trait items implemented, missing: `const_chunks_exact` --> $DIR/ice-unexpected-inference-var-122549.rs:9:1 | LL |     fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; |     ------------------------------------------------------------------------------- `const_chunks_exact` from trait ... LL | impl<T> ConstChunksExactTrait<T> for [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `const_chunks_exact` in implementation error[E0392]: lifetime parameter `'rem` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:25 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                         ^^^^ unused lifetime parameter | = help: consider removing `'rem`, referring to it in a field, or using a marker such as `PhantomData` error[E0392]: type parameter `T` is never used --> $DIR/ice-unexpected-inference-var-122549.rs:11:31 | LL | struct ConstChunksExact<'rem, T: 'a, const N: usize> {} |                               ^ unused type parameter | = help: consider removing `T`, referring to it in a field, or using a marker such as `PhantomData` error[E0207]: the const parameter `N` is not constrained by the impl trait, self type, or predicates --> $DIR/ice-unexpected-inference-var-122549.rs:15:13 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |             ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types --> $DIR/ice-unexpected-inference-var-122549.rs:15:66 | LL | impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { |                                                                  ^^ expected `usize`, found `()` error: aborting due to 7 previous errors Some errors have detailed explanations: E0046, E0207, E0261, E0308, E0392. For more information about an error, try `rustc --explain E0046`. </ins>

Related discussion:
text: </p</details<!-- query stack: 5 | impl<TConstChunksExactTrait<Tfor [T] {} [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
Code change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub struct Foo; macro_rules! reexport { () => { use Foo as Bar; } } reexport!(); fn main() { use Bar; fn f(_: Bar) {} } </ins>

Related discussion:
text: Test case: Compiles successfully on , causes an ICE on . Diff contains only , CC Found while trying to minimize , but filed separately since the error message is different and this one has a small test case.
Do you have a backtrace?
Yes of course. Sorry I forgot to include it: rust error: internal compiler error: attempted .defid() on invalid def: Err note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'Box<Any',