jiebi/CodeConvo huggingface dataset:
Code change:
// Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

Related discussion:
text: While attempting to build the current bobbin-sdk under Ubuntu 18.04 using rust 1.34.0-nightly ( 2019-02-26) I get a panic in rustc.
cc
Minimal repro: you need both the , a method call , and a method call on the result of that in order to trigger promotion. It seems like is promoted to make a for the call to
Ok, so promotion is indeed screwing up. The MIR is promoting the argument.
triage: P-high. Looks under control.
Just to confirm, this has not made it out to the nightly, correct? As of today I am still seeing the same error when attempting to build bobbin-hz as part of bobbin-sdk.
No, is still open, I'll bump its priority
Code change:
// Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

Related discussion:
text: ICE when compiling bash parity-ethereum git:(master) cargo build Compiling ethcore-miner v1.12.0 () thread 'rustc' panicked at 'index out of bounds: the len is 2 but the index is 3', 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::continuepanicfmt at 7: rustbeginunwind at 8: core::panicking::panicfmt at 9: core::panicking::panicboundscheck at 10: <rustctarget::abi::TyLayout<'a, Ty::field 11: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::operandfield 12: rustcmir::interpret::operand::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::evalplacetoop 13: rustcmir::interpret::step::<impl rustcmir::interpret::evalcontext::EvalContext<'a, 'mir, 'tcx, M::run 14: rustcmir::consteval::evalbodyusingecx 15: rustcmir::consteval::constevalrawprovider 16: rustc::ty::query::querycompute::constevalraw 17: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::constevalraw<'tcx::compute 18: rustc::depgraph::graph::DepGraph::withtaskimpl 19: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,
Code change:
// Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

Related discussion:
text: 'tcx::getquery 20: rustcmir::consteval::constevalprovider 21: rustc::ty::query::querycompute::consteval 22: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 23: rustc::depgraph::graph::DepGraph::withtaskimpl 24: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 25: rustcmir::consteval::constevalprovider 26: rustc::ty::query::querycompute::consteval 27: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::consteval<'tcx::compute 28: rustc::depgraph::graph::DepGraph::withtaskimpl 29: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx, 'tcx::getquery 30: rustcmir::monomorphize::collector::collectitemsrec 31: rustcmir::monomorphize::collector::collectcratemonoitems::{{closure}} 32: rustc::util::common::time 33: rustcmir::monomorphize::collector::collectcratemonoitems 34: rustc::util::common::time 35: rustcmir::monomorphize::partitioning::collectandpartitionmonoitems 36: rustc::ty::query::querycompute::collectandpartitionmonoitems 37: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::collectandpartitionmonoitems<'tcx::compute 38: rustc::depgraph::graph::DepGraph::withtaskimpl 39: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,
Code change:
// Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

Related discussion:
text: 'tcx::getquery 40: rustccodegenssa::back::symbolexport::exportedsymbolsproviderlocal 41: rustc::ty::query::querycompute::exportedsymbols 42: rustc::ty::query::<impl rustc::ty::query::config::QueryAccessors<'tcxfor rustc::ty::query::queries::exportedsymbols<'tcx::compute 43: rustc::depgraph::graph::DepGraph::withtaskimpl 44: rustc::ty::query::plumbing::<impl rustc::ty::context::TyCtxt<'a, 'gcx,
Code change:
// Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

Related discussion:
text: 'tcx::getquery 45: rustcmetadata::encoder::encodemetadata 46: rustcmetadata::cstoreimpl::<impl rustc::middle::cstore::CrateStore for rustcmetadata::cstore::CStore::encodemetadata 47: rustc::ty::context::TyCtxt::encodemetadata 48: rustccodegenllvm::base::writemetadata 49: rustc::util::common::time 50: rustccodegenssa::base::codegencrate 51: <rustccodegenllvm::LlvmCodegenBackend as rustccodegenutils::codegenbackend::CodegenBackend::codegencrate 52: rustc::util::common::time 53: rustcdriver::driver::phase4codegen 54: rustcdriver::driver::compileinput::{{closure}} 55: <std::thread::local::LocalKey<T::with 56: rustc::ty::context::TyCtxt::createandenter 57: rustcdriver::driver::compileinput 58: rustcdriver::runcompilerwithpool 59: <scopedtls::ScopedKey<T::set 60: rustcdriver::runcompiler 61: syntax::withglobals 62: rustmaybecatchpanic at 63: <F as alloc::boxed::FnBox<A::callbox 64: std::sys::unix::thread::Thread::new::threadstart at at at 65: startthread 66: _clone query stack during panic: [constevalraw] const-evaluating [consteval] const-evaluating + checking [consteval] const-evaluating + checking [collectandpartitionmonoitems] collectandpartitionmonoitems [exportedsymbols] exportedsymbols 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-21) running on x8664-unknown-linux-gnu note: compiler flags: -C debuginfo=2 -C incremental --crate-type lib note: some of the compiler flags provided by cargo are hidden error: Could not compile . warning: build failed, waiting for other jobs to finish... error: build failed
cc
Is this a regression?
Code change:
// Refers to temporaries which cannot be promoted as // promote_consts decided they weren't simple enough. <ins> // FIXME(oli-obk,eddyb): Remove this flag entirely and // solely process this information via `IsNotConst`. </ins> struct IsNotPromotable; impl Qualif for IsNotPromotable {

Related discussion:
text: Did it work with a previous nightly? I'm currently looking through function (the ICE is during the evaluation of a promoted inside that function), but I can't find any promoteds :confused:
I can't debug this right now, because a debugging compiler fails even earlier:
So apparently still causes the ICE, but only inside the crate. If I try to create an MCVE everything compiles just fine... Very confusing.
triage: P-high. Looks to be in good hands.
Thanks, I can verify that it is fixed in
Code change:
COMPILE_FLAGS=-Copt-level=3 -Clto=fat -Cprofile-generate="$(TMPDIR)" <del> # LLVM doesn't yet support instrumenting binaries that use unwinding on MSVC: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMPILE_FLAGS+= -Cpanic=abort endif </del> all: $(RUSTC) $(COMPILE_FLAGS) test.rs $(call RUN,test) || exit 1

Related discussion:
text: LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?
Code change:
let mut impl_items = Buffer::empty_from(w); let mut default_impl_items = Buffer::empty_from(w); <ins> let impl_ = i.inner_impl(); </ins> <del> for trait_item in &i.inner_impl().items { doc_impl_item( &mut default_impl_items, &mut impl_items, cx, trait_item, if trait_.is_some() { &i.impl_item } else { parent }, link, render_mode, false, trait_, rendering_params, ); </del> <ins> if !impl_.is_negative_trait_impl() { for trait_item in &impl_.items { doc_impl_item( &mut default_impl_items, &mut impl_items, cx, trait_item, if trait_.is_some() { &i.impl_item } else { parent }, link, render_mode, false, trait_, rendering_params, ); } </ins> } fn render_default_items(

Related discussion:
text: <p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.
Code change:
assert_eq!(cnum, LOCAL_CRATE); let mut visible_parent_map: DefIdMap<DefId> = DefIdMap(); <ins> // Issue 46112: We want the map to prefer the shortest // paths when reporting the path to an item. Therefore we // build up the map via a breadth-first search (BFS), // which naturally yields minimal-length paths. // // Note that it needs to be a BFS over the whole forest of // crates, not just each individual crate; otherwise you // only get paths that are locally minimal with respect to // whatever crate we happened to encounter first in this // traversal, but not globally minimal across all crates. let bfs_queue = &mut VecDeque::new(); </ins> for &cnum in tcx.crates().iter() { // Ignore crates without a corresponding local `extern crate` item. if tcx.missing_extern_crate_item(cnum) { continue } <del> let bfs_queue = &mut VecDeque::new(); </del> <ins> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); } // (restrict scope of mutable-borrow of `visible_parent_map`) { </ins> let visible_parent_map = &mut visible_parent_map; let mut add_child = |bfs_queue: &mut VecDeque<_>, child: &def::Export,

Related discussion:
text: On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.
Code change:
assert_eq!(cnum, LOCAL_CRATE); let mut visible_parent_map: DefIdMap<DefId> = DefIdMap(); <ins> // Issue 46112: We want the map to prefer the shortest // paths when reporting the path to an item. Therefore we // build up the map via a breadth-first search (BFS), // which naturally yields minimal-length paths. // // Note that it needs to be a BFS over the whole forest of // crates, not just each individual crate; otherwise you // only get paths that are locally minimal with respect to // whatever crate we happened to encounter first in this // traversal, but not globally minimal across all crates. let bfs_queue = &mut VecDeque::new(); </ins> for &cnum in tcx.crates().iter() { // Ignore crates without a corresponding local `extern crate` item. if tcx.missing_extern_crate_item(cnum) { continue } <del> let bfs_queue = &mut VecDeque::new(); </del> <ins> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); } // (restrict scope of mutable-borrow of `visible_parent_map`) { </ins> let visible_parent_map = &mut visible_parent_map; let mut add_child = |bfs_queue: &mut VecDeque<_>, child: &def::Export,

Related discussion:
text: In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .
Code change:
<ins> // This test ensures that negative impls don't have items listed inside them. #![feature(negative_impls)] #![crate_name = "foo"] pub struct Thing; //@ has 'foo/struct.Thing.html' // We check the full path to ensure there is no `<details>` element. //@ has - '//div[@id="trait-implementations-list"]/section[@id="impl-Iterator-for-Thing"]/h3'  // 'impl !Iterator for Thing' impl !Iterator for Thing {} // This struct will allow us to compare both paths. pub struct Witness; //@ has 'foo/struct.Witness.html' //@ has - '//div[@id="trait-implementations-list"]/details//section[@id="impl-Iterator-for-Witness"]/h3'  // 'impl Iterator for Witness' impl Iterator for Witness { type Item = u8; fn next(&mut self) -> Option<Self::Item> { None } } </ins>

Related discussion:
text: <p align="center"<img width="400" src=""</pI would prefer if only the negative impl signature were rendered here (and any doc comment on the negative impl). Not even a collapsed-by-default accordion to show the trait's contents. The reader can click the trait's name to see what is in it if they need. Having associated items of a negative impl rendered is inconvenient because something like <kbdCTRL+F</kbdfor "fn position" will land the reader deep in the middle of the big impl showing them APIs that their type does not have. Example of this occurring in standard library documentation:  Mentioning tracking issue.
Code change:
<ins> // Confusing diagnostic when using variable as a type: // // Previous warnings indicate Foo is not used, when in fact it is // used improperly as a variable or constant. New warning points // out user may be trying to use variable as a type. Test demonstrates // cases for both local variable and const. fn main() { let Baz: &str = ""; println!("{}", Baz::Bar); //~ ERROR: failed to resolve: use of undeclared type `Baz` } #[allow(non_upper_case_globals)] pub const Foo: &str = ""; mod submod { use super::Foo; fn function() { println!("{}", Foo::Bar); //~ ERROR: failed to resolve: use of undeclared type `Foo` } } </ins>

Related discussion:
text: The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim
Code change:
<ins> fn main() {} trait T { fn qux() -> Option<usize> { let _ = if true { }); //~^ ERROR expected one of `async`, `const`, `extern`, `fn`, `type`, `unsafe`, or `}`, found `;` //~^^ ERROR expected one of `.`, `;`, `?`, `else`, or an operator, found `}` //~^^^ ERROR 6:11: 6:12: expected identifier, found `;` //~^^^^ ERROR missing `fn`, `type`, or `const` for trait-item declaration Some(4) } </ins>

Related discussion:
text: I got an internal compiler error while compiling some code with a syntax error. The error is in the final line of the match statement in the function parse. () Errors:
triage: P-high. (Unnominating since there doesn't seem to be much else to discuss)
Assigning myself to look into and fix.
:
this ICE only happens for already broken code, I don't believe this is P-high.
Code change:
// Make this module private for now since external users should not call these directly. mod rustc_smir; <ins> #[macro_use] extern crate scoped_tls; </ins>

Related discussion:
text: is left set to a dangling pointer if unwinds. This is unsound because a later call to will use that dangling pointer. There is a similar issue with and unwinding. since you're on the Stable MIR cc list: cc
if you can add it as a dependency, using would probably be better than rolling your own version.
Yea, that makes sense. I think we should look into using it for the module, too, which is how we get a within the compiler itself