jiebi/CodeConvo huggingface dataset:
Change:
It was notified on before
Note that this worked in 1.42, so this is a stable-to-stable regression.
This basically . We re-stabilized some of the avx512 features that were used by BLAKE3, but it seems that we missed rav1e.
Any chance you could prepare a fix? I think this is worth a stable point release.
Summarizing some discussions in the lang team meeting, regarding CPU feature naming: there are inconsistencies in feature naming between LLVM, GCC, GAS, and the Linux kernel, but we have a mild technical reason to defer to LLVM (doing otherwise requires renaming the feature). So let's defer to LLVM naming of CPU features, which doesn't tend to use underscores.
In I stabilized all remaining x86 features for feature detection. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Why wasn't this caught by the crater runs for 1.43? It builds stuff from github, no?
:bell: This is now entering its final comment period, as per the . :bell:
Hmm yeah there were compiling the asm files: <details</details
I looks like the assembler is too old and doesn't recognize the AVX-512 instructions
cc We missed a regression on crater because it had an old version of nasm, which caused the crate to fail to compile. It seems that nasm 2.14 is required for the AVX512 instruction used.
Hmm yeah that might be it. It Ubuntu 18.04 LTS which uses nasm 2.13. An update to 20.04 LTS will bring nasm 2.14 and probably fix the issue short term but not long term once rav1e starts requiring newer nasm versions.
(removing stable-nominated tag, as we nominate PR's for backport, not issues)

Discussion:
<del> Subproject commit b00ecbeb268ee97cef9fa9b2375e6f6cf0864db2 </del> <ins> Subproject commit d10eefc62284c40c5a95a2eed19fc1f414a5364d </ins>
Change:
Playground: UPDATE: MCVE is here: Code: Crashes compiler with
Would be nice to figure out if this is a regression or not and if it is when has this regressed. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
It has been present since at least 2019-08-01 according to bisect-rustc
Simplified code to remove dependencies This compiles for 1.20.0 and not for 1.30.0 (setting edition to 2015) I'll try and pinpoint at least the version where it causes the ICE
From what I can tell the first time this ICE would happen is in 1.24.0
Assigning
Even simpler:
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .
Wait, the original code and still triggers the ICE... glacier was tracking with but it seems the others encounter another roadblock. Dropping .
No longer ICEs since , likely from

Discussion:
<ins> // Regression test for #71546. // ignore-compare-mode-nll // NLL stderr is different from the original one. pub fn serialize_as_csv<V>(value: &V) -> Result<String, &str> where V: 'static, for<'a> &'a V: IntoIterator, for<'a> <&'a V as IntoIterator>::Item: ToString + 'static, { let csv_str: String = value //~ ERROR: the associated type `<&'a V as IntoIterator>::Item` may not live long enough .into_iter() .map(|elem| elem.to_string()) .collect::<String>(); Ok(csv_str) } fn main() {} </ins>

<ins> error[E0310]: the associated type `<&'a V as IntoIterator>::Item` may not live long enough --> $DIR/issue-71546.rs:12:27 | LL |       let csv_str: String = value |  ___________________________^ LL | |         .into_iter() LL | |         .map(|elem| elem.to_string()) | |_____________________________________^ | = help: consider adding an explicit lifetime bound `<&'a V as IntoIterator>::Item: 'static`... = note: ...so that the type `<&'a V as IntoIterator>::Item` will meet its required lifetime bounds... note: ...that is required by this bound --> $DIR/issue-71546.rs:10:55 | LL |     for<'a> <&'a V as IntoIterator>::Item: ToString + 'static, |                                                       ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0310`. </ins>
Change:
I tried this code: I expected the code to compile successfully(like it did in previous nightly versions) Instead, the code failed to compile with this error: Tried this on rustc 1.44.0-nightly (2020-04-24 ) The way I work around this bug is to write the function like this:
Interestingly none of these additional bounds fix the issue:
searched nightlies: from nightly-2020-04-03 to nightly-2020-04-10 regressed nightly: nightly-2020-04-08 searched commits: from to regressed commit: modify labels:-E-needs-bisection
this has now been fixed

Discussion:
<ins> // check-pass #![feature(adt_const_params)] #![allow(incomplete_features)] pub trait GetType<const N: &'static str> { type Ty; fn get(&self) -> &Self::Ty; } pub fn get_val<T>(value: &T) -> &T::Ty where T: GetType<"hello">, { value.get() } fn main() {} </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! And nominating for compiler team prioritization.
probably needs to be addressed as well.

Discussion:
<del> Subproject commit b7c802b5e33f5a402de3780bc5a8b05e7ebad409 </del> <ins> Subproject commit 28197b622611ba3a6367648974ccf59127c287bb </ins>
Change:
I tried this code: Tried to build the  crate. I expected to see this happen: Successful build. Instead, this happened: Compiler panic. : rustc 1.45.0-nightly ( 2020-04-26) binary: rustc commit-hash: commit-date: 2020-04-26 host: x86_64-apple-darwin release: 1.45.0-nightly LLVM version: 9.0 Backtrace:
finds the resgression in searched nightlies: from nightly-2020-04-26 to nightly-2020-04-27 regressed nightly: nightly-2020-04-27 searched commits: from to regressed commit:
We've seen this on . It seems to apply only to when targeting Mac OS or iOS. The same nightly on Linux does not cause an ICE.
Presumably due to cc It looks iOS-specific because wraps an iOS-specific API. Would be good to find an MCVE.
Assigning as and removing .
ping cleanup Let’s try to find an MVCE and find out if this ICE only appears on MacOS.
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Huh, curious. I guess we didn't catch it there because crater doesn't run on ios, but also the error is one I would not have expected to come from that PR. That PR should have only caused new cycle errors, nothing else.
I think I hit the same error on OSX in the crate; check .
Yeah, that's also the crate causing it
I'm seeing the same error, also caused by the dispatch crate on macOS (not iOS):
Minimal repro:

Discussion:
// We can still be zero-sized in this branch, in which case we have to // return `None`. <del> if size.bytes() == 0 { // We may be reading from a static. // In order to ensure that `static FOO: Type = FOO;` causes a cycle error // instead of magically pulling *any* ZST value from the ether, we need to // actually access the referenced allocation. The caller is likely // to short-circuit on `None`, so we trigger the access here to // make sure it happens. self.get_raw(ptr.alloc_id)?; None } else { Some(ptr) } </del> <ins> if size.bytes() == 0 { None } else { Some(ptr) } </ins> } }) }

{ Some(ptr) => ptr, None => { <ins> if let Scalar::Ptr(ptr) = mplace.ptr { // We may be reading from a static. // In order to ensure that `static FOO: Type = FOO;` causes a cycle error // instead of magically pulling *any* ZST value from the ether, we need to // actually access the referenced allocation. self.memory.get_raw(ptr.alloc_id)?; } </ins> return Ok(Some(ImmTy { // zero-sized type imm: Scalar::zst().into(),

<ins> // check-pass // This is a regression test for ICEs from // https://github.com/rust-lang/rust/issues/71612 // and // https://github.com/rust-lang/rust/issues/71709 #[derive(Copy, Clone)] pub struct Glfw; static mut GLFW: Option<Glfw> = None; pub fn new() -> Glfw { unsafe { if let Some(glfw) = GLFW { return glfw; } else { todo!() } }; } extern "C" { static _dispatch_queue_attr_concurrent: [u8; 0]; } static DISPATCH_QUEUE_CONCURRENT: &'static [u8; 0] = unsafe { &_dispatch_queue_attr_concurrent }; fn main() { *DISPATCH_QUEUE_CONCURRENT; new(); } </ins>
Change:
'warning', 'note', and 'error' are colorized; I think it'd be nice to also colorize the underlining of the affected code, as clang does. clang makes it green, I believe.
+1 for doing whatever clang does re error reporting.

Discussion:
} } <del> fn print_diagnostic(topic: &str, lvl: level, msg: &str) { let t = term::Terminal::new(io::stderr()); </del> <ins> fn print_maybe_colored(msg: &str, color: u8) { </ins> let stderr = io::stderr(); <del> if !topic.is_empty() { stderr.write_str(fmt!("%s ", topic)); } </del> <ins> let t = term::Terminal::new(stderr); </ins> match t { Ok(term) => { if stderr.get_type() == io::Screen { <del> term.fg(diagnosticcolor(lvl)); stderr.write_str(fmt!("%s: ", diagnosticstr(lvl))); </del> <ins> term.fg(color); stderr.write_str(msg); </ins> term.reset(); <del> stderr.write_str(fmt!("%sn", msg)); </del> } else { <del> stderr.write_str(fmt!("%s: %sn", diagnosticstr(lvl), msg)); </del> <ins> stderr.write_str(msg); </ins> } }, <del> _ => stderr.write_str(fmt!("%s: %sn", diagnosticstr(lvl), msg)) </del> <ins> _ => stderr.write_str(msg) </ins> } } <ins> fn print_diagnostic(topic: &str, lvl: level, msg: &str) { let stderr = io::stderr(); if !topic.is_empty() { stderr.write_str(fmt!("%s ", topic)); } print_maybe_colored(fmt!("%s: ", diagnosticstr(lvl)), diagnosticcolor(lvl)); stderr.write_str(fmt!("%sn", msg)); } </ins> pub fn collect(messages: @mut ~[~str]) -> @fn(Option<(@codemap::CodeMap, span)>, &str, level) { let f: @fn(Option<(@codemap::CodeMap, span)>, &str, level) =

_ => " "         // -squigly-line as well (instead of a };                   // space). This way the squigly-line will }                        // usually appear in the correct position. <del> s += "^"; </del> <ins> io::stderr().write_str(s); let mut s = ~"^"; </ins> let hi = cm.lookup_char_pos(sp.hi); if hi.col != lo.col { // the ^ already takes up one space let num_squiglies = hi.col.to_uint()-lo.col.to_uint()-1u; for num_squiglies.times() { s += "~"; } } <del> io::stderr().write_str(s + "n"); </del> <ins> print_maybe_colored(s + "n", term::color_bright_green); </ins> } }
Change:
Spawned off of Specifically this comment: quoted here: Also, this has been discussed before, hasn't it?
prioritize
(in ) is also statically unknown here, so yes this needs , that is indeed the entire point. ;)
Assigning as and removing . Assigning to myself as a followup of .
Here's a small optimization: pick some default alignment, maybe 16, then allocate bytes. If then because they are both powers of two, so the offset required to align to bytes is for , which is at most . If then the allocation will already be properly aligned, no offset required.

Discussion:
indirect_dest: PlaceRef<'tcx, V>, ) { debug!("OperandRef::store_unsized: operand={:?}, indirect_dest={:?}", self, indirect_dest); <del> let flags = MemFlags::empty(); </del> // `indirect_dest` must have `*mut T` type. We extract `T` out of it. let unsized_ty = indirect_dest .layout

bug!("store_unsized called with a sized value") }; <del> // FIXME: choose an appropriate alignment, or use dynamic align somehow let max_align = Align::from_bits(128).unwrap(); let min_align = Align::from_bits(8).unwrap(); // Allocate an appropriate region on the stack, and copy the value into it let (llsize, _) = glue::size_and_align_of_dst(bx, unsized_ty, Some(llextra)); let lldst = bx.byte_array_alloca(llsize, max_align); bx.memcpy(lldst, max_align, llptr, min_align, llsize, flags); </del> <ins> // Allocate an appropriate region on the stack, and copy the value into it. Since alloca // doesn't support dynamic alignment, we allocate an extra align - 1 bytes, and align the // pointer manually. let (size, align) = glue::size_and_align_of_dst(bx, unsized_ty, Some(llextra)); let one = bx.const_usize(1); let align_minus_1 = bx.sub(align, one); let size_extra = bx.add(size, align_minus_1); let min_align = Align::ONE; let alloca = bx.byte_array_alloca(size_extra, min_align); let address = bx.ptrtoint(alloca, bx.type_isize()); let neg_address = bx.neg(address); let offset = bx.and(neg_address, align_minus_1); let dst = bx.inbounds_gep(bx.type_i8(), alloca, &[offset]); bx.memcpy(dst, min_align, llptr, min_align, size, MemFlags::empty()); </ins> // Store the allocated region and the extra to the indirect place. <del> let indirect_operand = OperandValue::Pair(lldst, llextra); </del> <ins> let indirect_operand = OperandValue::Pair(dst, llextra); </ins> indirect_operand.store(bx, indirect_dest); } }

<ins> // Test that unsized locals uphold alignment requirements. // Regression test for #71416. // run-pass #![feature(unsized_locals)] #![allow(incomplete_features)] use std::any::Any; #[repr(align(256))] #[allow(dead_code)] struct A { v: u8 } impl A { fn f(&self) -> *const A { assert_eq!(self as *const A as usize % 256, 0); self } } fn mk() -> Box<dyn Any> { Box::new(A { v: 4 }) } fn main() { let x = *mk(); let dwncst = x.downcast_ref::<A>().unwrap(); let addr = dwncst.f(); assert_eq!(addr as usize % 256, 0); } </ins>
Change:
For example: https://crater- https://crater- cc
This is a regression from produced an ambiguity error even if the binding is syntactically unambiguous (e.g. like in the example above) for some future-compatibility reasons (), but it can be easily tweaked to not produce it because backward-compatibility is more important.
Fixed in

Discussion:
ident: Ident, has_sub: bool, ) -> Option<Res> { <ins> // An immutable (no `mut`) by-value (no `ref`) binding pattern without // a sub pattern (no `@ $pat`) is syntactically ambiguous as it could // also be interpreted as a path to e.g. a constant, variant, etc. let is_syntactic_ambiguity = !has_sub && bm == BindingMode::ByValue(Mutability::Not); </ins> let ls_binding = self.resolve_ident_in_lexical_scope(ident, ValueNS, None, pat.span)?; let (res, binding) = match ls_binding { <del> LexicalScopeBinding::Item(binding) if binding.is_ambiguity() => { </del> <ins> LexicalScopeBinding::Item(binding) if is_syntactic_ambiguity && binding.is_ambiguity() => { </ins> // For ambiguous bindings we don't know all their definitions and cannot check // whether they can be shadowed by fresh bindings or not, so force an error. <ins> // issues/33118#issuecomment-233962221 (see below) still applies here, // but we have to ignore it for backward compatibility. </ins> self.r.record_use(ident, ValueNS, binding, false); return None; }

LexicalScopeBinding::Res(res) => (res, None), }; <del> // An immutable (no `mut`) by-value (no `ref`) binding pattern without // a sub pattern (no `@ $pat`) is syntactically ambiguous as it could // also be interpreted as a path to e.g. a constant, variant, etc. let is_syntactic_ambiguity = !has_sub && bm == BindingMode::ByValue(Mutability::Not); </del> match res { Res::SelfCtor(_) // See #70549. | Res::Def(

let v = f; //~ ERROR `f` is ambiguous match v { f => {} //~ ERROR `f` is ambiguous <ins> mut f => {} // OK, unambiguously a fresh binding due to `mut` </ins> } }
Change:
I'm seeing an internal compiler error on the following input (found by ):
Possibly related to , though the panic happens at a different place.
Report from cargo-bisect-rustc: searched nightlies: from nightly-2020-03-01 to nightly-2020-05-02 regressed nightly: nightly-2020-03-28 searched commits: from to regressed commit:
It is caused by a different underlying cause to .
The underlying issue is a bad interaction in the following code with the call to (called by ) which expects there not to be any unresolved lifetimes. This happens because the code is actually parsed and evaluated as ( and ).

Discussion:
} Err(()) => { // error types are considered "builtin" <del> if !lhs_ty.references_error() { </del> <ins> if !lhs_ty.references_error() && !rhs_ty.references_error() { </ins> let source_map = self.tcx.sess.source_map(); match is_assign { IsAssign::Yes => {

<ins> fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ { *x //~^ ERROR the trait bound `u32: std::future::Future` is not satisfied } fn main() { let _ = test_ref & u; //~ ERROR cannot find value `u` in this scope } </ins>

<ins> error[E0425]: cannot find value `u` in this scope --> $DIR/issues-71798.rs:6:24 | LL |     let _ = test_ref & u; |                        ^ not found in this scope error[E0277]: the trait bound `u32: std::future::Future` is not satisfied --> $DIR/issues-71798.rs:1:25 | LL | fn test_ref(x: &u32) -> impl std::future::Future<Output = u32> + '_ { |                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::future::Future` is not implemented for `u32` LL |     *x |     -- this returned value is of type `u32` | = note: the return type of a function must have a statically known size error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0425. For more information about an error, try `rustc --explain E0277`. </ins>
Change:
These are configured something like
I am not sure why this happens off hand, but when bootstrapping the non-build-triple compilers artifacts are copied from e.g. to .

Discussion:
// crates they depend on. let rel_rpaths = get_rpaths_relative_to_output(os, output, libs); <ins> // Make backup absolute paths to the libraries. Binaries can // be moved as long as the crates they link against don't move. let abs_rpaths = get_absolute_rpaths(libs); </ins> // And a final backup rpath to the global library location. let fallback_rpaths = ~[get_install_prefix_rpath(target_triple)];

} log_rpaths("relative", rel_rpaths); <ins> log_rpaths("absolute", abs_rpaths); </ins> log_rpaths("fallback", fallback_rpaths); let mut rpaths = rel_rpaths; <ins> rpaths.push_all(abs_rpaths); </ins> rpaths.push_all(fallback_rpaths); // Remove duplicates

} } <ins> fn get_absolute_rpaths(libs: &[Path]) -> ~[Path] { vec::map(libs, |a| get_absolute_rpath(a) ) } pub fn get_absolute_rpath(lib: &Path) -> Path { os::make_absolute(lib).dir_path() } </ins> #[cfg(stage0)] pub fn get_install_prefix_rpath(target_triple: &str) -> Path { let install_prefix = env!("CFG_PREFIX");

#[cfg(unix, test)] mod test { use core::prelude::*; <ins> use core::os; </ins> // FIXME(#2119): the outer attribute should be #[cfg(unix, test)], then // these redundant #[cfg(test)] blocks can be removed #[cfg(test)] #[cfg(test)] <del> use back::rpath::{get_install_prefix_rpath}; </del> <ins> use back::rpath::{get_absolute_rpath, get_install_prefix_rpath}; </ins> use back::rpath::{get_relative_to, get_rpath_relative_to_output}; use back::rpath::{minimize_rpaths, rpaths_to_flags}; use driver::session;

&Path("lib/libstd.so")); assert_eq!(res.to_str(), ~"@executable_path/../lib"); } <ins> #[test] fn test_get_absolute_rpath() { let res = get_absolute_rpath(&Path("lib/libstd.so")); debug!("test_get_absolute_rpath: %s vs. %s", res.to_str(), os::make_absolute(&Path("lib")).to_str()); assert_eq!(res, os::make_absolute(&Path("lib"))); } </ins> }
Change:
We've run into an issue where we have a type that implements both and . Passing an index value of causes rustc to choose instead of , even if a mutable reference is required. If we first call and use that as the index, is chosen, as expected. Example repro by (see ): I expected to see this happen: should invoke on since expects a mutable reference. Instead, this happened: invoked and complained that isn't implemented even though it is: <!-- 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. --This is reproducible on stable Rust 1.41.0 and 1.43.0 and . cc:
I have a hacky solution to this in . Looking this code up in godbolt I can reproduce it all the way to 1.0, earlier versions giving a type error ( vs ), then an ICE in the 1.2x (that I was causing during my experiments to fix this: ) and finally the current error. The problem is caused (somehow) in slightly differing from , but haven't figured how to fix that underlying difference.
In case this helps to find the root problem, gives a similar error: " is not implemented" even though it really is.
It seems closely related but sadly doesn't change the behavior on that ticket. I'll take a look at it though.

Discussion:
match expr.kind { hir::ExprKind::Index(ref base_expr, ref index_expr) => { <del> let index_expr_ty = self.node_ty(index_expr.hir_id); </del> <ins> // We need to get the final type in case dereferences were needed for the trait // to apply (#72002). let index_expr_ty = self.tables.borrow().expr_ty_adjusted(index_expr); </ins> self.convert_place_op_to_mutable( PlaceOp::Index, expr,

<ins> // check-pass struct Indexable; impl Indexable { fn boo(&mut self) {} } impl std::ops::Index<&str> for Indexable { type Output = Indexable; fn index(&self, field: &str) -> &Indexable { self } } impl std::ops::IndexMut<&str> for Indexable { fn index_mut(&mut self, field: &str) -> &mut Indexable { self } } fn main() { let mut v = Indexable; let field = "hello".to_string(); v[field.as_str()].boo(); v[&field].boo(); // < This should work } </ins>