jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0412]: cannot find type `Foo` in this scope --> $DIR/import-alias-issue-121168.rs:11:12 | LL |     let _: Foo<i32> = todo!(); |            ^^^ not found in this scope | help: consider importing one of these items | LL + use crate::nice_crate_name::Foo; | LL + use import_alias_issue_121168_extern::Foo; | error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
Some build environments (e.g. Chromium (), Bazel) may generate crate names based on names of build targets. While this results in globally-unique () crate names, it results in long and quite unwieldy crate names. Both Chromium and Blaze provide a macro to help working with such crate names: The macro usage above expands to something like: Unfortunately, it seems that some diagnostics keep referring to the long and unwieldy name. () see () globally-unique crate names = within a given build tree No response More detailed repro can be found below:
Is this something worth fixing? Is the original crate name worth preferring over the aliased name in some scenarios?
BTW: I also want to note/highlight that I am not able to repro the problem without using . For example (same files):
/cc
Change:
visitor.region_maps.mark_as_terminating_scope(otherwise.id); } <del> ast::ExprIf(_, then, None) => { </del> <ins> ast::ExprIf(expr, then, None) => { visitor.region_maps.mark_as_terminating_scope(expr.id); </ins> visitor.region_maps.mark_as_terminating_scope(then.id); } <del> ast::ExprLoop(body, _) | ast::ExprWhile(_, body) => { </del> <ins> ast::ExprLoop(body, _) => { visitor.region_maps.mark_as_terminating_scope(body.id); } ast::ExprWhile(expr, body) => { visitor.region_maps.mark_as_terminating_scope(expr.id); </ins> visitor.region_maps.mark_as_terminating_scope(body.id); }

Discussion:
I think that and conditions should free any temporaries that occur within them (for conditions it's mandatory, actually, since the condition is evaluated many times). That is, if I write: the temporary returned by should be freed once the condition is evaluated, before entering the body of the . The same holds for . What makes these expressions different from other compound forms is that the conditions are evaluated to scalar booleans, and hence can never create lasting aliases that might need to be preserved. In the case of a while, this is needed because temporaries can never outlive conditional or repeated scopes, and the condition of a while is a repeated scope.
cc
Marking as mentor with myself. This is a fairly small change (if you know what to change :)
I'll work on it :)
0 blocker, P-backcompat-lang.
The fix in was partial, with an is still broken:
Nominated. Seems clear to me that this is a bug we should fix -- the main question is whether to be concerned about backwards compatibility, and -- if so -- what to do about it. I think this is mostly a question for team to decide, but I tagged this issue with T-Lang too in case members want to weight in on whether the behavior is indeed a bug. But it seems clear that having and behave differently is bogus.
Consensus in the compiler team meeting was that we should just fix this and add the resulting PR to the release notes. triage: P-medium
Change:
<ins> #![allow(unused)] const fn f<T>(x: T) { //~ WARN function cannot return without recursing f(x); //~^ ERROR any use of this value will cause an error //~| WARN this was previously accepted by the compiler } const X: () = f(1); fn main() {} </ins>

Discussion:
Given the following code (): The current output is: <details<summaryMassive diagnostic</summary</detailsIdeally, the duplicate lines should be hidden: modify labels: +A-const-fn +D-verbose <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
let prev_ptr = ptr.add(gap.write.wrapping_sub(1)); if same_bucket(&mut *read_ptr, &mut *prev_ptr) { <ins> // Increase `gap.read` now since the drop may panic. gap.read += 1; </ins> /* We have found duplicate, drop it in-place */ ptr::drop_in_place(read_ptr); } else {

Discussion:
is not updated (line 1636) when (line 1623) panics. This lets 's implementation to retain the already dropped element. The bug was introduced in and affects stable Rust versions = 1.52. Here is the that demonstrates the double free without using unsafe Rust code. <!-- 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-stable
Assigning as discussed by and removing . modify labels +P-critical -I-prioritize
Interestingly there was a test for this, but it is wrong. The vec contains the index=5, even though it is the item that panics in its drop implementation. I guess the author of this test thought that returned the new value instead of the old value?
Learning about a double-free I introduced, a year later... :eyes: And honestly, I can clearly remember that when the test was first written, it caught the bug, but I just assumed it was an off-by-one error in the testing code itself, yikes
Change:
// see https://github.com/rust-lang/rust/issues/93688#issuecomment-1032929496.) // So we just "offset" by 0. let layout = base.layout().for_variant(self, variant); <del> // In the future we might want to allow this to permit code like this: // (this is a Rust/MIR pseudocode mix) // ``` // enum Option2 { //   Some(i32, !), //   None, // } // // fn panic() -> ! { panic!() } // // let x: Option2; // x.Some.0 = 42; // x.Some.1 = panic(); // SetDiscriminant(x, Some); // ``` // However, for now we don't generate such MIR, and this check here *has* found real // bugs (see https://github.com/rust-lang/rust/issues/115145), so we will keep rejecting // it. assert!(!layout.abi.is_uninhabited()); </del> <ins> // This variant may in fact be uninhabited. // See <https://github.com/rust-lang/rust/issues/120337>. </ins> // This cannot be `transmute` as variants *can* have a smaller size than the entire enum. base.offset(Size::ZERO, layout, self)

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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
/// Get the previously recorded `to` local def id given the `from` local def id, obtained using /// `generics_def_id_map` field. <del> fn get_remapped_def_id(&self, mut local_def_id: LocalDefId) -> LocalDefId { </del> <ins> fn get_remapped_def_id(&self, local_def_id: LocalDefId) -> LocalDefId { </ins> // `generics_def_id_map` is a stack of mappings. As we go deeper in impl traits nesting we <del> // push new mappings so we need to try first the latest mappings, hence `iter().rev()`. </del> <ins> // push new mappings, so we first need to get the latest (innermost) mappings, hence `iter().rev()`. </ins> // // Consider: //

Discussion:
This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase. I tried this code: - I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase) Instead, this happened: It most recently worked on: 1.63 (from my repo, commit : ) It does not work anymore on version 1.64: (from my repo, commit : ) Including the backtrace by setting does not change anything to the error message. I do not know why this problem occured though. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsOut of the rollup, this was probably caused by ?
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening to track backports.
can this be closed? was backported to stable, right? cc (unsure who to ping)
I have no involvement with this whatsoever.^^ is usually doing backports.
was beta backported to 1.65, which is now released. We won't be having a 1.64.1 release. So this should be considered "fixed", since it is resolved on the current stable release of Rust.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(alloc_jemalloc, alloc_system)] </del> <ins> #![feature(alloc_jemalloc)] </ins> <del> #[cfg(not(any(windows, target_os = "bitrig", target_os = "openbsd", target_os="emscripten")))] </del> <ins> #[cfg(any(target_os = "linux", target_os = "macos"))] </ins> extern crate alloc_jemalloc; <del> #[cfg(any(windows, target_os = "bitrig", target_os = "openbsd", target_os="emscripten"))] extern crate alloc_system; </del> fn main() { println!("{:?}", Box::new(3));

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
<del> //@ known-bug: rust-lang/rust#129216 //@ only-linux trait Mirror { type Assoc; } struct Foo; fn main() { <Foo as Mirror>::Assoc::new(); } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
//! Miscellaneous type-system utilities that are too small to deserve their own modules. <del> use crate::traits::{self, ObligationCause}; </del> <ins> use crate::traits::{self, ObligationCause, ObligationCtxt}; </ins> use rustc_data_structures::fx::FxIndexSet; use rustc_hir as hir; <ins> use rustc_infer::infer::canonical::Canonical; </ins> use rustc_infer::infer::{RegionResolutionError, TyCtxtInferExt}; <ins> use rustc_infer::traits::query::NoSolution; </ins> use rustc_infer::{infer::outlives::env::OutlivesEnvironment, traits::FulfillmentError}; <del> use rustc_middle::ty::{self, Ty, TyCtxt, TypeVisitable}; </del> <ins> use rustc_middle::ty::{self, ParamEnv, Ty, TyCtxt, TypeVisitable}; use rustc_span::DUMMY_SP; </ins> use super::outlives_bounds::InferCtxtExt;

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 occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
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. #[macro_export] macro_rules! make_item ( ($name: ident) => (pub const $name: usize = 42;) ); </ins>

Discussion:
The "src" link at the top goes to the incorrect URL:
Can you please file this against instead? This tracker is just for Rust itself. Thanks!
This is a bug in rustdoc afaict.
Ah! Sorry about that
Might be related to
Change:
self.resolve_type_vars_or_error(&ty) } <ins> pub fn tables_are_tcx_tables(&self) -> bool { let tables: &RefCell<ty::Tables> = &self.tables; let tcx_tables: &RefCell<ty::Tables> = &self.tcx.tables; tables as *const _ == tcx_tables as *const _ } </ins> pub fn type_moves_by_default(&self, ty: Ty<'tcx>, span: Span) -> bool { let ty = self.resolve_type_vars_if_possible(&ty); <del> if ty.needs_infer() { </del> <ins> if ty.needs_infer() || (ty.has_closure_types() && !self.tables_are_tcx_tables()) { </ins> // this can get called from typeck (by euv), and moves_by_default // rightly refuses to work with inference variables, but // moves_by_default has a cache, which we want to use in other

Discussion:
Compiling the following code causes a panic: Compiler output: I compiled with rustc 1.5.0-nightly ( 2015-09-19) binary: rustc commit-hash: commit-date: 2015-09-19 host: x86_64-unknown-linux-gnu release: 1.5.0-nightly
Reduced test case:
This is a 1.3-1.4 regression. I accidentally caused it in .
triage: I-nominated
triage: P-medium
Change:
<ins> // Copyright 2017 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 fn main() { // Test that lambdas behave as unary expressions with block-like expressions -if true { 1 } else { 2 } * 3; || if true { 1 } else { 2 } * 3; // The following is invalid and parses as `if true { 1 } else { 2 }; *3` // if true { 1 } else { 2 } * 3 } </ins>

Discussion:
Currently is parsed as . I think it should be parsed as , to be consistent with handling of other similar "open" binary and prefix expressions (lambdas can be viewed as a form of a prefix expression). Consider these expressions: They are parsed as The last two cases seem to be different from others and wrong. on IRC suggested that this behavior could have been introduced accidentally during transition from lambdas with blocks as bodies to lambdas with arbitrary expressions as bodies. If this is a bug, fixing it can render some previously valid programs invalid, but this seems rater unlikely, as bare lambdas rarely end up in conditionals. It is possible though:
cc
Oh and I didn't mean I had introduced the distinction accidentally but rather that before I made that simplification, the code was block-oriented so the need for it to obey typical expression rules may have been overlooked and I didn't think about it (to consider fixing it).
Change:
<ins> #![feature(decl_macro)] // @has decl_macro/macro.my_macro.html //pre 'pub macro my_macro() {' // @has - //pre '...' // @has - //pre '}' pub macro my_macro() { } // @has decl_macro/macro.my_macro_2.html //pre 'pub macro my_macro_2($($tok:tt)*) {' // @has - //pre '...' // @has - //pre '}' pub macro my_macro_2($($tok:tt)*) { } // @has decl_macro/macro.my_macro_multi.html //pre 'pub macro my_macro_multi {' // @has - //pre '(_) => { ... },' // @has - //pre '($foo:ident . $bar:expr) => { ... },' // @has - //pre '($($foo:literal),+) => { ... }' // @has - //pre '}' pub macro my_macro_multi { (_) => { }, ($foo:ident . $bar:expr) => { }, ($($foo:literal),+) => { } } // @has decl_macro/macro.by_example_single.html //pre 'pub macro by_example_single($foo:expr) {' // @has - //pre '...' // @has - //pre '}' pub macro by_example_single { ($foo:expr) => {} } </ins>

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
new_errors.dedup(); if self.errors != new_errors { <del> error!("old validator: {:?}", self.errors); error!("new validator: {:?}", new_errors); // ICE on nightly if the validators do not emit exactly the same errors. // Users can supress this panic with an unstable compiler flag (hopefully after // filing an issue). let opts = &self.tcx.sess.opts; let trigger_ice = opts.unstable_features.is_nightly_build() && !opts.debugging_opts.suppress_const_validation_back_compat_ice; if trigger_ice { span_bug!( body.span, "{}", VALIDATOR_MISMATCH_ERR, ); } </del> <ins> validator_mismatch( self.tcx, body, std::mem::replace(&mut self.errors, vec![]), new_errors, ); </ins> } }

Discussion:
Offending snippet using : The code shouldn't build, as per the first few errors below, but currently on nightly it also causes the compiler to panic. It does not panic on stable or beta. Version: 1.40.0-nightly (2019-10-12 ) Playground: Quite possibly a duplicate of just buried inside the macro expansion but I'm not familiar enough with Rust compiler internals to make that determination.
cc
I've to the following: A mutable reference is required in all variants of this, so this particular mismatch does not represent a true backwards compatibility hazard: Creating a reference that would allow mutation is forbidden in all contexts. We could simply stop triggering the mismatch ICE when both lists contain the same error. The underlying issue, however, is that is being too conservative once again. As soon as a mutable reference is taken to , we use type-based qualification instead of looking at the qualif which gets cleared when is moved from. Increasing the precision here would require a dataflow analysis. This would get checked first whenever was queried (much like how we currently check first). I believe this will be necessary when we do allow in contexts, otherwise writing code would be quite painful. I could hack together a solution for this particular case that doesn't require another dataflow analysis. Basically, during validation, we could keep track of which s have been moved out of in the current basic block and use that as a conservative approximation of . This would fail if the local was moved from in one basic block and then dropped in a successor of that block. It seems relatively hard to write rust code that gets translated to that MIR, however. For example, the following does not do it, but I think it should be possible.
cc
Checking for moves in the same block fails pretty often. I've implemented the first fix described above, but we probably want to use a analysis in the long term.
triage: P-medium. Assigning to . Removing nomination label.
Change:
<ins> fn main() { const EMPTY_ARRAY = []; //~^ missing type for `const` item } </ins>

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high