jiebi/CodeConvo huggingface dataset:
Change:
This is while debug printing all mir statements of libcore.
modify labels: +A-mir +C-bug +requires-nightly
This also reproduces on .
The incorrectly assumes at several places that the allocation kind is always what the type should contain. It for example assumes that an value always points to a function, and always points to raw bytes. It also ignores relocations at several places.
Triage: I think this ICE is fixed by , no longer occurs with the latest nightly. Marking as E-needs-test.

Discussion:
<ins> // check-pass // compile-flags: --emit=mir,link // Regression test for #66930, this ICE requires `--emit=mir` flag. static UTF8_CHAR_WIDTH: [u8; 0] = []; pub fn utf8_char_width(b: u8) -> usize { UTF8_CHAR_WIDTH[b as usize] as usize } fn main() {} </ins>
Change:
modify labels: +A-mir +C-bug +requires-nightly
cc
I wonder if this is caused by MIR inlining or by other passes like copy propagation. The conflict with would seem to suggest inlining (of a method call). Anyway, we can improve this for now by treating anything not in the outermost as not an argument user variable (even when backed by an argument MIR local).
Minimal repro, with ():

Discussion:
let var_ty = self.monomorphized_place_ty(place.as_ref()); let var_kind = if self.mir.local_kind(place.local) == mir::LocalKind::Arg && place.projection.is_empty() <ins> && var.source_info.scope == mir::OUTERMOST_SOURCE_SCOPE </ins> { <del> // FIXME(eddyb, #67586) take `var.source_info.scope` into // account to avoid using `ArgumentVariable` more than once // per argument local. </del> let arg_index = place.local.index() - 1; // FIXME(eddyb) shouldn't `ArgumentVariable` indices be

<ins> // run-pass // compile-flags: -Z mir-opt-level=2 -C opt-level=0 -C debuginfo=2 #[inline(never)] pub fn foo(bar: usize) -> usize { std::convert::identity(bar) } fn main() { foo(0); } </ins>
Change:
root: gb2260-0.1.1: v. root: imperative - 3 (1 gh, 2 ) detected crates which regressed due to this <detailscommitted-0.1.11: v. imperative-1.0.1: v. epage/committed: v. </detailscc (likely MIR borrowck related, though not the transition itself as that happened last cycle)
Probably a result of the soundness fixes in
This is a change in promotion. cc
Minimized:
Maybe ?
or . No, it's neither of these.
It's , likely .

Discussion:
//! A copy of the `Qualif` trait in `qualify_consts.rs` that is suitable for the new validator. <del> use rustc::hir::def_id::DefId; </del> use rustc::mir::*; use rustc::ty::{self, Ty}; use syntax_pos::DUMMY_SP;

/// of the type. fn in_any_value_of_ty(_cx: &ConstCx<'_, 'tcx>, _ty: Ty<'tcx>) -> bool; <del> fn in_static(cx: &ConstCx<'_, 'tcx>, def_id: DefId) -> bool { // `mir_const_qualif` does return the qualifs in the final value of a `static`, so we could // use value-based qualification here, but we shouldn't do this without a good reason. Self::in_any_value_of_ty(cx, cx.tcx.type_of(def_id)) } </del> fn in_projection_structurally( cx: &ConstCx<'_, 'tcx>, per_local: &impl Fn(Local) -> bool,

} Operand::Constant(ref constant) => { <del> if let Some(static_) = constant.check_static_ptr(cx.tcx) { Self::in_static(cx, static_) </del> <ins> if constant.check_static_ptr(cx.tcx).is_some() { // `mir_const_qualif` does return the qualifs in the final value of a `static`, // so we could use value-based qualification here, but we shouldn't do this // without a good reason. // // Note: this uses `constant.literal.ty` which is a reference or pointer to the // type of the actual `static` item. Self::in_any_value_of_ty(cx, constant.literal.ty) </ins> } else if let ty::ConstKind::Unevaluated(def_id, _) = constant.literal.val { // Don't peek inside trait associated constants. if cx.tcx.trait_of_item(def_id).is_some() {

<ins> // regression test for #67609. // check-pass static NONE: Option<String> = None; static NONE_REF_REF: &&Option<String> = { let x = &&NONE; x }; fn main() { println!("{:?}", NONE_REF_REF); } </ins>
Change:
root: window - 2 (0 gh, 2 ) detected crates which regressed due to this <detailsbarg-0.2.0: v. window-0.3.0: v. </detailscc
:( is being used . The regression is caused by
Minimal repro: the MIR is The deallocates the array that the call gets a raw pointer to. That's where the dangling pointer error comes from. I guess we used to promote this array but due to the deref (since statics are now ) don't do this anymore
triage: P-high. (Has PR, yay.)

Discussion:
if self.is_mutable_static(def_id) { self.mk_mut_ptr(static_ty) <del> } else if self.is_foreign_item(def_id) { self.mk_imm_ptr(static_ty) </del> } else { self.mk_imm_ref(self.lifetimes.re_erased, static_ty) }

<ins> extern "C" { static X: i32; } static Y: i32 = 42; static mut BAR: *const &'static i32 = [&Y].as_ptr(); static mut FOO: *const &'static i32 = [unsafe { &X }].as_ptr(); fn main() {} // END RUST SOURCE // START rustc.FOO.PromoteTemps.before.mir // bb0: { // ... //     _5 = const Scalar(AllocId(1).0x0) : &i32; //     _4 = &(*_5); //     _3 = [move _4]; //     _2 = &_3; //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     StorageDead(_5); //     StorageDead(_3); //     return; // } // END rustc.FOO.PromoteTemps.before.mir // START rustc.BAR.PromoteTemps.before.mir // bb0: { // ... //     _5 = const Scalar(AllocId(0).0x0) : &i32; //     _4 = &(*_5); //     _3 = [move _4]; //     _2 = &_3; //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     StorageDead(_5); //     StorageDead(_3); //     return; // } // END rustc.BAR.PromoteTemps.before.mir // START rustc.BAR.PromoteTemps.after.mir // bb0: { // ... //     _2 = &(promoted[0]: [&'static i32; 1]); //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     return; // } // END rustc.BAR.PromoteTemps.after.mir // START rustc.FOO.PromoteTemps.after.mir // bb0: { // ... //     _2 = &(promoted[0]: [&'static i32; 1]); //     _1 = move _2 as &[&'static i32] (Pointer(Unsize)); //     _0 = const core::slice::<impl [&'static i32]>::as_ptr(move _1) -> [return: bb2, unwind: bb1]; // } // ... // bb2: { //     return; // } // END rustc.FOO.PromoteTemps.after.mir </ins>
Change:
with the introduction of , the mandatories the use of downloaded . but all platforms doesn't have binary distribution, mainly tiers-3 platforms like OpenBSD. For rustc or cargo dependencies, it is possible to use (with and key in section) to point to alternate binaries. this way, doesn't download them and use local supplied binaries. For it is currently not possible: if is able to deal with it, will complains that isn't a valid key: What would be the right way to use a local binary in order to copte with , and not force the use of downloaded binary ? Would adding a key in section of would be accepted (I could provide a patch of it, if yes) ? or should another method used ? Cc
Yes, that was on oversight on my part. I would be happy to review a patch adding it to You should also be able to comment out the line in as a (possibly) temporary fix, this is my plan for beta and stable branches FWIW.

Discussion:
# specified, use this rustc binary instead as the stage0 snapshot compiler. #rustc = "/path/to/bin/rustc" <ins> # Instead of download the src/stage0.txt version of rustfmt specified, # use this rustfmt binary instead as the stage0 snapshot rustfmt. #rustfmt = "/path/to/bin/rustfmt" </ins> # Flag to specify whether any documentation is built. If false, rustdoc and # friends will still be compiled but they will not be used to generate any # documentation.

target: Vec<String>, cargo: Option<String>, rustc: Option<String>, <ins> rustfmt: Option<String>, /* allow bootstrap.py to use rustfmt key */ </ins> docs: Option<bool>, compiler_docs: Option<bool>, submodules: Option<bool>,
Change:
file:  rustc @
cc
Heh, the first victim of const prop acting as if it were creating constants. Previous discussion on zulip: https://rust-

Discussion:
self.check_binary_op(*op, left, right, source_info, place_layout, overflow_check)?; } <del> // Work around: avoid ICE in miri. FIXME(wesleywiser) // The Miri engine ICEs when taking a reference to an uninitialized unsized // local. There's nothing it can do here: taking a reference needs an allocation // which needs to know the size. Normally that's okay as during execution // (e.g. for CTFE) it can never happen. But here in const_prop // unknown data is uninitialized, so if e.g. a function argument is unsized // and has a reference taken, we get an ICE. </del> <ins> // Do not try creating references (#67862) </ins> Rvalue::Ref(_, _, place_ref) => { <del> trace!("checking Ref({:?})", place_ref); </del> <ins> trace!("skipping Ref({:?})", place_ref); </ins> <del> if let Some(local) = place_ref.as_local() { let alive = if let LocalValue::Live(_) = self.ecx.frame().locals[local].value { true } else { false }; if !alive { trace!("skipping Ref({:?}) to uninitialized local", place); return None; } } </del> <ins> return None; </ins> } _ => {}

fn main() { <del> *(&(4, 5).1); </del> <ins> *(&(4, 5).1); // This does not currently propagate (#67862) </ins> } // END RUST SOURCE

//     ... //     _4 = const main::promoted[0]; //     _2 = &((*_4).1: i32); <del> //     _1 = const 5i32; </del> <ins> //     _1 = (*_2); </ins> //     ... // } // END rustc.main.ConstProp.after.mir

<ins> // compile-flags: -Z mir-opt-level=2 // run-pass struct Baz<T: ?Sized> { a: T } fn main() { let d : Baz<[i32; 4]> = Baz { a: [1,2,3,4] }; assert_eq!([1, 2, 3, 4], d.a); } </ins>

<ins> // compile-flags: -Z mir-opt-level=3 // run-pass struct X { x: isize } fn f1(a: &mut X, b: &mut isize, c: isize) -> isize { let r = a.x + *b + c; a.x = 0; *b = 10; return r; } fn f2<F>(a: isize, f: F) -> isize where F: FnOnce(isize) { f(1); return a; } pub fn main() { let mut a = X {x: 1}; let mut b = 2; let c = 3; assert_eq!(f1(&mut a, &mut b, c), 6); assert_eq!(a.x, 0); assert_eq!(f2(a.x, |_| a.x = 50), 0); } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // run-pass use std::cell::Cell; #[derive(Debug)] struct B<'a> { a: [Cell<Option<&'a B<'a>>>; 2] } impl<'a> B<'a> { fn new() -> B<'a> { B { a: [Cell::new(None), Cell::new(None)] } } } fn f() { let b2 = B::new(); b2.a[0].set(Some(&b2)); } fn main() { f(); } </ins>

<ins> // compile-flags: -Z mir-opt-level=2 // run-pass fn e220() -> (i64, i64) { #[inline(never)] fn get_displacement() -> [i64; 2] { [139776, 963904] } let res = get_displacement(); match (&res[0], &res[1]) { (arg0, arg1) => (*arg0, *arg1), } } fn main() { assert_eq!(e220(), (139776, 963904)); } </ins>
Change:
This generates documentation with a stable rustdoc today without any warnings. Interestingly, rustdoc does seem to check that the feature gate is in the crate (i.e., must exist), and will error if a feature gate has been removed (e.g., custom_attribute on nightly).
cc
I'd guess this is related to somehow. I'm not entirely sure what rustdoc relies on which would mandate the locking in of the permission to use unstable features, but perhaps would know?
Normally, for such things rustdoc relies on rustc internals to do the work. Maybe an option is badly set?
triage: looks like this should be T-rustdoc's call as to what priority to assign here. Leaving unprioritized and nominated, at least for a week.
I made the priority medium: it's not a huge bug but the quicker it's fixed, the better it'll be for everyone.
should fix this.
Thanks! I've also gone ahead and nominated it for beta backport as it's probably good to close the stability hole sooner rather than later; it's a trivial patch.

Discussion:
cg: codegen_options, externs, target_triple: target, <del> // Ensure that rustdoc works even if rustc is feature-staged unstable_features: UnstableFeatures::Allow, </del> <ins> unstable_features: UnstableFeatures::from_environment(), </ins> actually_rustdoc: true, debugging_opts: debugging_options, error_format,
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage P-medium removing nomination.

Discussion:
<del> Subproject commit fed7a31cd93bbd3c8a9f38871838b59b5dce2a35 </del> <ins> Subproject commit 7c0489c5ff4f5c594e65a3b22efd9ce373deab9b </ins>
Change:
Hiya, on , compilation fails when defining an array whose length is from a constant from a trait from an associated type. The code compiles fine on . The error message: It seems similar to , but in this case, isn't being used. It may also be a duplicate of It also compiles fine on playpen nightly: .
Ouput from searched nightlies: from nightly-2019-12-29 to nightly-2019-12-31 regressed nightly: nightly-2019-12-31 searched commits: from to regressed commit:
cc
triage P-high, removing nomination.
A user reports that this is blocking the Rust Playground from updating its nightly. (See ) Nominating for discussion at today's meeting.
Sorry everyone, I totally forgot about this. A fix PR is up now.

Discussion:
let def_id = cx.tcx.hir().local_def_id(count.hir_id); let substs = InternalSubsts::identity_for_item(cx.tcx, def_id); let span = cx.tcx.def_span(def_id); <del> let count = match cx.tcx.const_eval_resolve(cx.param_env, def_id, substs, None, Some(span)) { Ok(cv) => cv.eval_usize(cx.tcx, cx.param_env), Err(ErrorHandled::Reported) => 0, Err(ErrorHandled::TooGeneric) => { let span = cx.tcx.def_span(def_id); cx.tcx .sess .span_err(span, "array lengths can't depend on generic parameters"); 0 } }; </del> <ins> let count = match cx.tcx.const_eval_resolve( ty::ParamEnv::reveal_all(), def_id, substs, None, Some(span), ) { Ok(cv) => cv.eval_usize(cx.tcx, ty::ParamEnv::reveal_all()), Err(ErrorHandled::Reported) => 0, Err(ErrorHandled::TooGeneric) => { let span = cx.tcx.def_span(def_id); cx.tcx.sess.span_err(span, "array lengths can't depend on generic parameters"); 0 } }; </ins> ExprKind::Repeat { value: v.to_ref(), count } }

<ins> // check-pass trait TraitA { const VALUE: usize; } struct A; impl TraitA for A { const VALUE: usize = 1; } trait TraitB { type MyA: TraitA; const VALUE: usize = Self::MyA::VALUE; } struct B; impl TraitB for B { type MyA = A; } fn main() { let _ = [0; A::VALUE]; let _ = [0; B::VALUE]; // Indirectly refers to `A::VALUE` } </ins>
Change:
() Gives the error: This compiles fine with const_generics not enabled, and is a regression cc
(discovered by
cc Simplified:
Isn't this expected fallout?
This is an expected consequence of
Seems like is what's supposed to eventually fix this?
triage: P-medium (nightly-only regression on feature that is known to have bugs)
I think we've discussed this before, but what do you think of special-casing literals, to unblock at least some common usecases like this?
I can't reproduce on master, this may have gotten fixed? (Note that the playground is severely outdated, a fix is underway for that though)
pointed out that most likely fixed this.

Discussion:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn takes_closure_of_array_3<F>(f: F) where F: Fn([i32; 3]) { f([1, 2, 3]); } fn takes_closure_of_array_3_apit(f: impl Fn([i32; 3])) { f([1, 2, 3]); } fn returns_closure_of_array_3() -> impl Fn([i32; 3]) { |_| {} } fn main() {} </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/integer-literal-generic-arg-in-where-clause.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>
Change:
The below code (in ) has three doc tests: first succeeds as expected. second test fails as expected: the constant would be and there is an attempt to subtract with overflow. third test should succeed as it has the exact same code as the second test but is marked as . However the test fails with the message “Test compiled successfully, but it's marked .” rust /// let works = cf::S::<u32::default(); /// (); /// rust /// let shouldfail = cf::S::<u64::default(); /// (); /// compilefail /// let shouldfail = cf::S::<u64::default(); /// (); ///
This is a consequence of how works. (and ) does the equivalent of (or the same as ), which does not perform all steps of compilation (like codegen and linking). One of the issues tracking this problem is . I'm not sure why rustdoc does not perform the full compilation steps for and .

Discussion:
A link name was given with an empty name. Erroneous code example: <del> ```ignore (cannot-test-this-because-rustdoc-stops-compile-fail-before-codegen) </del> <ins> ```compile_fail,E0454 </ins> #[link(name = "")] extern {} // error: `#[link(name = "")]` given with empty name ```

An unknown "kind" was specified for a link attribute. Erroneous code example: <del> ```ignore (cannot-test-this-because-rustdoc-stops-compile-fail-before-codegen) </del> <ins> ```compile_fail,E0458 </ins> #[link(kind = "wonderful_unicorn")] extern {} // error: unknown kind: `wonderful_unicorn` ```

A link was used without a name parameter. Erroneous code example: <del> ```ignore (cannot-test-this-because-rustdoc-stops-compile-fail-before-codegen) </del> <ins> ```compile_fail,E0459 </ins> #[link(kind = "dylib")] extern {} // error: `#[link(...)]` specified without `name = "foo"` ```

for debugging_option_str in &options.debugging_options_strs { compiler.arg("-Z").arg(&debugging_option_str); } <del> if no_run { </del> <ins> if no_run && !compile_fail { </ins> compiler.arg("--emit=metadata"); } compiler.arg("--target").arg(target.to_string());
Change:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This lint was generated by : as we can see is just ignored, so the fix is pretty easy, just all the refs in the type of .
claim

Discussion:
if let Some(ty::BindByValue(hir::Mutability::Not)) = cx.tables.extract_binding_mode(cx.tcx.sess, p.hir_id, p.span) { <del> let pat_ty = cx.tables.pat_ty(p); </del> <ins> let pat_ty = cx.tables.pat_ty(p).peel_refs(); </ins> if let ty::Adt(edef, _) = pat_ty.kind { if edef.is_enum() && edef.variants.iter().any(|variant| {

<ins> // Test for issue #67776: binding named the same as enum variant // should report a warning even when matching against a reference type // check-pass #![allow(unused_variables)] #![allow(non_snake_case)] enum Foo { Bar, Baz, } fn fn1(e: Foo) { match e { Bar => {}, //~^ WARNING named the same as one of the variants of the type `Foo` Baz => {}, //~^ WARNING named the same as one of the variants of the type `Foo` } } fn fn2(e: &Foo) { match e { Bar => {}, //~^ WARNING named the same as one of the variants of the type `Foo` Baz => {}, //~^ WARNING named the same as one of the variants of the type `Foo` } } fn fn3(e: &mut &&mut Foo) { match e { Bar => {}, //~^ WARNING named the same as one of the variants of the type `Foo` Baz => {}, //~^ WARNING named the same as one of the variants of the type `Foo` } } fn main() {} </ins>

<ins> warning[E0170]: pattern binding `Bar` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:17:9 | LL |         Bar => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Bar` warning[E0170]: pattern binding `Baz` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:19:9 | LL |         Baz => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Baz` warning[E0170]: pattern binding `Bar` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:26:9 | LL |         Bar => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Bar` warning[E0170]: pattern binding `Baz` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:28:9 | LL |         Baz => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Baz` warning[E0170]: pattern binding `Bar` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:35:9 | LL |         Bar => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Bar` warning[E0170]: pattern binding `Baz` is named the same as one of the variants of the type `Foo` --> $DIR/issue-67776-match-same-name-enum-variant-refs.rs:37:9 | LL |         Baz => {}, |         ^^^ help: to match on the variant, qualify the path: `Foo::Baz` </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and nominating for compiler team prioritization.
Reopening until the submodule is updated
triage: P-medium. looks like its on way to being fixed, anyway.

Discussion:
<del> Subproject commit 34d8ec896db94ac7443541514653166ad5d38d3c </del> <ins> Subproject commit 4da2b2149ca1c6a3331260dfcbb2175c51f2842d </ins>