jiebi/CodeConvo huggingface dataset:
Change:
use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; use rustc_middle::mir::interpret::{AllocId, ErrorHandled, GlobalAlloc, Scalar}; use rustc_middle::mir::mono::{InstantiationMode, MonoItem}; <ins> use rustc_middle::mir::traversal; </ins> use rustc_middle::mir::visit::Visitor as MirVisitor; use rustc_middle::mir::{self, Location, MentionedItem}; use rustc_middle::query::TyCtxtAt;

Discussion:
tracking issue: Inspired by comment in For things like it'd be nice to not have to even give LLVM the code for the else branch to have to emit. Ought to save time and binary size. Tentatively marked mir-opt, since we presumably still need to make the MIR for it, in order to borrow-check and such the unreachable code. But might need to be codegen-time instead to pick up on monomorphized inline constants. Hopefully should be doable relatively easily when the const is an inline const, since that forces const folding already, and thus there should just be a in the MIR.
Well, turns out this already works for simple constants in MIR! However, the place I actually needed it was more like , which doesn't work with today. So maybe come back to this once that's fixed.
This should be done by which AFAIK is run unconditionally. I wonder if its match needs to be expanded? Is there mcve?
The problem is that this can't be done on generic constants, as we don't mir-optimize post-monomorphization. We could start doing some benchmarks to see how bad running all mir opts (or at least a select few) would be if we duplicated, substituted and optimized MIR bodies for concrete generic parameters.
I would say qualifies as an MCVE as the monomorphized gives the following llvm ir
Maybe it should also be evaluated together with polymorphization or constevaluatablechecked since those can cut down on the duplication before applying further optimizations.
Bonus points if this can avoid monomorphizing functions called in the dead code too. Demo extracted from : (cc ) Would be great to not codegen all the downstream stuff that's only called in the else block of a .
FYI this should work with
Totally wild (and probably bad) idea: could we avoid borrow-checking unreachable code? After all, the purpose of borrow-checking is to prevent memory unsafety at runtime, but unreachable code cannot be memory unsafe, because it never executes!
We already do! As a , (But this isn't really the right issue to discuss possible extensions to that.)
This seems closely related to and
recent PR seems related here? If the condition becomes a constant during codegen, we should be entirely skipping it now and not even generate LLVM IR.

However, if that dead code calls functions, those still get codegen'd as usual -- the collector that determines which function to codegen doesn't know about dead branches. We'd have to embed a (simple) monomorphization-time reachability analysis in the collector to fix that.
Change:
Kind::Bench => describe!(check::Crate, check::CrateLibrustc), Kind::Doc => describe!(doc::UnstableBook, doc::UnstableBookGen, doc::TheBook, doc::Standalone, doc::Std, doc::Test, doc::Rustc, doc::ErrorIndex, doc::Nomicon, <del> doc::Reference, doc::Rustdoc, doc::CargoBook), </del> <ins> doc::Reference, doc::Rustdoc, doc::RustByExample, doc::CargoBook), </ins> Kind::Dist => describe!(dist::Docs, dist::Mingw, dist::Rustc, dist::DebuggerScripts, dist::Std, dist::Analysis, dist::Src, dist::PlainSourceTarball, dist::Cargo, dist::Rls, dist::Rustfmt, dist::Extended, dist::HashSign,

Discussion:
This is an issue for moving Rust By Example, which is currently at , to . I will be working on the first step shortly. [x] Convert RBE to a submodule under [x] Add RBE to the bookshelf (thanks [x] Update book release process on forge After it is converted and RBE reaches stable: [ ] Update the main English website link a 301
Step one done! Now waiting for this to reach stable.
The forge documentation can be updated now.
This has all been done!
Change:
let found = self.resolve_vars_with_obligations(found); if let hir::FnRetTy::Return(ty) = fn_decl.output { let ty = AstConv::ast_ty_to_ty(self, ty); <ins> let ty = self.tcx.erase_late_bound_regions(Binder::bind(ty)); </ins> let ty = self.normalize_associated_types_in(expr.span, ty); if self.can_coerce(found, ty) { err.multipart_suggestion(

Discussion:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Caused by :
Change:
warning: opaque type `impl Trait<Assoc = impl Send>` does not satisfy its associated type bounds <del> --> $DIR/nested-return-type2.rs:25:24 </del> <ins> --> $DIR/nested-return-type2.rs:28:24 </ins> | LL |     type Assoc: Duh; |                 --- this associated type bound is unsatisfied for `impl Send`

Discussion:
[ ] Previous Stable [ ] Current Stable [ ] Current Beta [ ] Current Nightly No response
searched toolchains through Regression in
I wonder if this is cc ?
very likely :thinking: will revert if we don't figure out how to fix this in the near future
<details<summarycompiler logs</summary</detailsedit: my bad I'm experiencing
WG-prioritization assigning priority (). label -I-prioritize +P-medium
bisection tested with , seems to point to commit searched nightlies: from nightly-2023-01-15 to nightly-2023-02-09 regressed nightly: nightly-2023-01-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsit's a rollup of:
I already bisected this one (see second comment :D) any should we revert now? it's still ICEing
yeah, wanted to revert this since looking at this a few days ago :sweat_smile: but for that I want to update the comment for why we're avoiding opaque types which is effort, so I've put it off for a while. Should get to it over the next few days
Change:
<ins> // aux-build: issue-83510.rs extern crate issue_83510; issue_83510::dance_like_you_want_to_ice!(); //~^ ERROR: cannot find type `Foo` in this scope //~| ERROR: expected trait, found struct `Box` //~| ERROR: cannot find trait `Baz` in this scope //~| ERROR: inherent associated types are unstable fn main() {} </ins>

Discussion:
<!-- 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. --With a procmacro, an ICE occurs when generating an block (whether for a trait or not) that has an associated type that looks like this: The type needs to be a valid (in scope) type that takes a generic parameter, with a trait/lifetime bound. Both the generic parameter and the trait/lifetime bound don't actually need to be in scope - just syntactically valid. I only found this after a typo ( instead of ); this code shouldn't compile without the ICE anyway - the trait/lifetime bound is on a concrete type. As a result, I cannot foresee a situation where valid code that should compile would fail to compile as a result of this ICE. <!-- 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. --Occurs on latest stable, beta and nightly versions. : I have also tested this on a host running , and the ICE also occurs on that machine as well. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning and removing .
Change:
<ins> const QUERY = 'P'; const EXPECTED = { 'others': [ { 'path': 'search_short_types', 'name': 'P' }, { 'path': 'search_short_types', 'name': 'Ap' }, ], }; </ins>

Discussion:
I was trying to find in rustdoc, but that doesn't show up anywhere if I just search for : It does show up if I search for () so there's a workaround, but I think it'd be nice if when I type an exact name, things with that exact name show up at the top, or something.
It's supposed to, so some adjustments need to be done on the "search engine". I'll take a look.
Change:
<ins> // @has 'glob_shadowing/index.html' // @count - '//div[@class="item-left module-item"]' 6 // @!has - '//div[@class="item-right docblock-short"]' 'sub1::describe' // @has - '//div[@class="item-right docblock-short"]' 'sub2::describe' // @!has - '//div[@class="item-right docblock-short"]' 'sub1::describe2' // @!has - '//div[@class="item-right docblock-short"]' 'sub1::prelude' // @has - '//div[@class="item-right docblock-short"]' 'mod::prelude' // @has - '//div[@class="item-right docblock-short"]' 'sub1::Foo (struct)' // @has - '//div[@class="item-right docblock-short"]' 'mod::Foo (function)' // @has - '//div[@class="item-right docblock-short"]' 'sub4::inner::X' // @has 'glob_shadowing/fn.describe.html' // @has - '//div[@class="docblock"]' 'sub2::describe' mod sub1 { // this should be shadowed by sub2::describe /// sub1::describe pub fn describe() -> &'static str { "sub1::describe" } // this should be shadowed by mod::prelude /// sub1::prelude pub mod prelude { } // this should *not* be shadowed, because sub1::Foo and mod::Foo are in different namespaces /// sub1::Foo (struct) pub struct Foo; // this should be shadowed, // because both sub1::describe2 and sub3::describe2 are from glob reexport /// sub1::describe2 pub fn describe2() -> &'static str { "sub1::describe2" } } mod sub2 { /// sub2::describe pub fn describe() -> &'static str { "sub2::describe" } } mod sub3 { // this should be shadowed // because both sub1::describe2 and sub3::describe2 are from glob reexport /// sub3::describe2 pub fn describe2() -> &'static str { "sub3::describe2" } } mod sub4 { // this should be shadowed by sub4::inner::X /// sub4::X pub const X: usize = 0; pub mod inner { pub use super::*; /// sub4::inner::X pub const X: usize = 1; } } /// mod::Foo (function) pub fn Foo() {} #[doc(inline)] pub use sub2::describe; #[doc(inline)] pub use sub1::*; #[doc(inline)] pub use sub3::*; #[doc(inline)] pub use sub4::inner::*; /// mod::prelude pub mod prelude {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
use rustc_data_structures::fx::FxHashMap; use rustc_data_structures::sharded::{self, Sharded}; <del> use rustc_data_structures::sync::OnceLock; </del> <ins> use rustc_data_structures::sync::{Lock, OnceLock}; use rustc_hir::def_id::LOCAL_CRATE; </ins> use rustc_index::{Idx, IndexVec}; <ins> use rustc_span::def_id::DefId; use rustc_span::def_id::DefIndex; </ins> use std::fmt::Debug; use std::hash::Hash; use std::marker::PhantomData;

Discussion:
Per-crate cache maps keyed on may be more efficient and/or allow us to use for queries keyed on instead of . We can use specialization (e.g. for splitting into and ), I think. cc
Sounds like a good idea if the lookup array ends up being densely populated enough. In general, we should provide a way to implement customized in-memory caching for specific queries.
Change:
<del> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` trait A { type Assoc: ?Sized; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { let x: Foo<()>; } </del>

Discussion:
<!-- 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. -- <!-- 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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
<ins> fn generate_setter() { String::with_capacity( //~^ ERROR this function takes 1 argument but 3 arguments were supplied generate_setter, r#" pub(crate) struct Person<T: Clone> {} "#, r#""#, ); } fn main() {} </ins>

Discussion:
<!-- 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. --code is from clippy: :warning: you need rustc build with debug assertions :warning: <!-- 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
Run into this while fuzzing, here is a minimized test case: Note that you need rustc with debug assertions enabled. Reproduced in nightly 2022-02-25.
Another test case:
OP and seem to be fixed on latest master (). now outputs "Span must not be empty and have no suggestion" <details<summarybacktrace</summary</details
I can confirm that both of my examples have been fixed on latest master () so this issue can be closed.
Change:
let trait_ref = self.tcx.mk_trait_ref(trait_def_id, trait_substs); if self.tcx.is_trait_alias(trait_def_id) { <del> // For trait aliases, assume all supertraits are relevant. let bounds = iter::once(ty::Binder::dummy(trait_ref)); self.elaborate_bounds(bounds, |this, new_trait_ref, item| { let new_trait_ref = this.erase_late_bound_regions(new_trait_ref); </del> <ins> // For trait aliases, recursively assume all explicitly named traits are relevant for expansion in traits::expand_trait_aliases( self.tcx, iter::once((ty::Binder::dummy(trait_ref), self.span)), ) { let bound_trait_ref = expansion.trait_ref(); for item in self.impl_or_trait_item(bound_trait_ref.def_id()) { if !self.has_applicable_self(&item) { self.record_static_candidate(CandidateSource::Trait( bound_trait_ref.def_id(), )); } else { let new_trait_ref = self.erase_late_bound_regions(bound_trait_ref); </ins> <del> let (xform_self_ty, xform_ret_ty) = this.xform_self_ty(&item, new_trait_ref.self_ty(), new_trait_ref.substs); this.push_candidate( Candidate { xform_self_ty, xform_ret_ty, item, import_ids: import_ids.clone(), kind: TraitCandidate(new_trait_ref), }, false, ); }); </del> <ins> let (xform_self_ty, xform_ret_ty) = self.xform_self_ty( &item, new_trait_ref.self_ty(), new_trait_ref.substs, ); self.push_candidate( Candidate { xform_self_ty, xform_ret_ty, item, import_ids: import_ids.clone(), kind: TraitCandidate(new_trait_ref), }, false, ); } } } </ins> } else { debug_assert!(self.tcx.is_trait(trait_def_id)); if self.tcx.trait_is_auto(trait_def_id) {

Discussion:
In-scope trait aliases bring into scope (methods of) the aliased trait and all of its supertraits. I can understand the rationale for bringing (methods of) the aliased trait into scope (namely to , but also bringing into scope (methods of) that trait's supertraits is both inconsistent (compared with bringing the aliased trait itself into scope) and surprising: . (For the avoidance of doubt, only the methods are brought into scope—not the trait itself: thus, in the above example with the alias uncommented, one cannot use an unqualified ). cc label A-resolve A-traits C-bug F-traitalias <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
From cursory inspection, the following (originally from , cc looks suspect:
claim
Change:
<ins> use std::ops::Add; trait Trait<T> { fn get(self) -> T; } struct Holder<T>(T); impl<T> Trait<T> for Holder<T> { fn get(self) -> T { self.0 } } enum Either<L, R> { Left(L), Right(R), } impl<L, R> Either<L, R> { fn converge<T>(self) -> T where L: Trait<T>, R: Trait<T> { match self { Either::Left(val) => val.get(), Either::Right(val) => val.get(), } } } fn add_generic<A: Add<B>, B>(lhs: A, rhs: B) -> Either< impl Trait<<A as Add<B>>::Output>, impl Trait<<A as Add<B>>::Output> > { if true { Either::Left(Holder(lhs + rhs)) } else { Either::Right(Holder(lhs + rhs)) } } fn add_one( value: u32, ) -> Either<impl Trait<<u32 as Add<u32>>::Output>, impl Trait<<u32 as Add<u32>>::Output>> { //~^ ERROR: the trait bound `impl Trait<<u32 as std::ops::Add>::Output>: Trait<u32>` //~| ERROR: the trait bound `impl Trait<<u32 as std::ops::Add>::Output>: Trait<u32>` add_generic(value, 1u32) } pub fn main() { add_one(3).converge(); } </ins>

Discussion:
Using a generic function to "converge" two into when T is an associated type for another trait causes the following error: Example code (): This may or may not be related to the compiler seemingly failing to assert that , an error that can be triggered by using the alternate signature for at line 40 of the example. I tested this with the linked playground on the latest stable (1.32.0), as well as a recent nightly: Compiling with doesn't seem to yield a very useful stack but here it is:
Another example by that causes only the second "call dest mismatch" ICE:
P-medium. Removing nomination label. (But maybe we should have a WG-impl-trait to provide a structured effort for working through the bugs with impl trait?)
This has been fixed in 1.38.0 as, while I can reproduce the ICE in 1.37.0, I am not observing it in neither of: stable (1.38.0), beta nor nightly. modify labels: E-needstest

The following code works on beta: But when used in a trait like so: rustc reports the following error:
Possibly related to rustc expecting possibly a type in this scenario? As you can declare trait methods with no parameter name
Possibly related to rustc expecting possibly a type in this scenario? Exactly. When becomes an error, we'll be able to accept arbitrary patterns in parameters of trait methods, but for now only very limited subset is allowed.
The example in the issue now compiles. If we don't have existing tests for this, we ought to add one.
Change:
<del> Subproject commit 8214ccf861d538671b0a1436dbf4538dc4a64d09 </del> <ins> Subproject commit f76ea3ca16ed22dde8ef929db74a4b4df6f2f899 </ins>

Discussion:
LLVM 7.0 has been branched as of 2018-08-01, with the final tag probably a couple weeks away. The first release candidate will be tagged in a couple of days. is the llvm-dev announcement, and is a view of the commits on the branch. Once the final release has been tagged, Rust should be updated to LLVM 7.0.
Great! I've started our branches: I'm hoping that this'll be pretty smooth since we upgraded most of the way through the cycle! I'm testing locally now and will send a PR once green.
Change:
// FIXME: We should investigate the perf implications of not uniquifying // `ReErased`. We may be able to short-circuit registering region // obligations if we encounter a `ReErased` on one side, for example. <del> ty::ReStatic | ty::ReErased => match self.canonicalize_mode { </del> <ins> ty::ReStatic | ty::ReErased | ty::ReError(_) => match self.canonicalize_mode { </ins> CanonicalizeMode::Input => CanonicalVarKind::Region(ty::UniverseIndex::ROOT), CanonicalizeMode::Response { .. } => return r, },

Discussion:
<!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors', 'error: internal compiler error: did not expect successful goal when collecting ambiguity errors' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [specializationgraphof] building specialization graph of trait [coherenttrait] coherence checking all impls of trait [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
regression in
Change:
ok = count('ok') failed = count('failed') ignored = count('ignored') <del> print "summary of %d test runs: %d passed; %d failed; %d ignored" %  (len(logfiles), ok, failed, ignored) </del> <ins> measured = count('bench') print "summary of %d test runs: %d passed; %d failed; %d ignored; %d measured" %  (len(logfiles), ok, failed, ignored, measured) </ins> print "" if failed > 0: print "failed tests:"

Discussion:
The final summary at the end says we ran 28 tests when we ran thousands.
Interesting, is the code for buildbot in src/test?
This code is part of the build system. is the place to start looking. The code for recording the number of tests is probably in .
Thanks brson, You were right, the code is in extra::test. Do I execute the tests through:
I'll pick this up, unless it's still in-progress or has been fixed already.
Go for it, I'd love to see what you come up with!
Change:
if tcx.sess.opts.unstable_opts.graphviz_dark_mode { render_opts.push(dot::RenderOption::DarkTheme); } <del> dot::render_opts(&graphviz, &mut buf, &render_opts)?; </del> <ins> with_no_trimmed_paths!(dot::render_opts(&graphviz, &mut buf, &render_opts)?); </ins> file.write_all(&buf)?;

Discussion:
<!-- 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. --<!-- 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
Are you able to fill out the requested details of the crash?
updated
Can you provide the dependencies in use? From what I can tell they aren't supported on Linux, but I'm unsure if I'm looking at the correct crate
tokio 0.1.21
Reduced this a little to It looks like somewhere down the line, a constant is being pretty printed into the .dot with path trimming, which later causes an ICE since no error is actually being emitted