jiebi/CodeConvo huggingface dataset:
Change:
` :
This crashes on stable, beta and nightly.
cc
says this regressed between releases 1.40 and 1.41.
triage: P-high to bisect and determine severity. Removing nomination. Added stable-to-stable regression label.
searched nightlies: from nightly-2019-11-01 to nightly-2020-02-25 regressed nightly: nightly-2019-12-08 searched commits: from to regressed commit: source code: Confirmed automated tests with manual run using <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details<details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
modify labels: -E-needs-bisection
Maybe
Reduced:
Fixed by

Discussion:
} fn error_derive_forbidden_on_non_adt(&self, derives: &[Path], item: &Annotatable) { <del> let attr = attr::find_by_name(item.attrs(), sym::derive).expect("`derive` attribute should exist"); let span = attr.span; </del> <ins> let attr = attr::find_by_name(item.attrs(), sym::derive); let span = attr.map_or(item.span(), |attr| attr.span); </ins> let mut err = self .cx .struct_span_err(span, "`derive` may only be applied to structs, enums and unions"); <del> if let ast::AttrStyle::Inner = attr.style { </del> <ins> if let Some(ast::Attribute { style: ast::AttrStyle::Inner, .. }) = attr { </ins> let trait_list = derives.iter().map(|t| pprust::path_to_string(t)).collect::<Vec<_>>(); let suggestion = format!("#[derive({})]", trait_list.join(", ")); err.span_suggestion(

<ins> fn main() {} struct CLI { #[derive(parse())] //~^ ERROR traits in `#[derive(...)]` don't accept arguments //~| ERROR cannot find derive macro `parse` in this scope //~| ERROR cannot find derive macro `parse` in this scope path: (), //~^ ERROR `derive` may only be applied to structs, enums and unions } </ins>

<ins> error: traits in `#[derive(...)]` don't accept arguments --> $DIR/issue-69341-malformed-derive-inert.rs:4:19 | LL |     #[derive(parse())] |                   ^^ help: remove the arguments error: `derive` may only be applied to structs, enums and unions --> $DIR/issue-69341-malformed-derive-inert.rs:8:5 | LL |     path: (), |     ^^^^^^^^ error: cannot find derive macro `parse` in this scope --> $DIR/issue-69341-malformed-derive-inert.rs:4:14 | LL |     #[derive(parse())] |              ^^^^^ error: cannot find derive macro `parse` in this scope --> $DIR/issue-69341-malformed-derive-inert.rs:4:14 | LL |     #[derive(parse())] |              ^^^^^ error: aborting due to 4 previous errors </ins>
Change:
I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by

Discussion:
} fn visit_fn(&mut self, fn_kind: FnKind<'ast>, sp: Span, _: NodeId) { let rib_kind = match fn_kind { <del> FnKind::Fn(FnCtxt::Foreign, ..) => return visit::walk_fn(self, fn_kind, sp), FnKind::Fn(FnCtxt::Free, ..) => FnItemRibKind, </del> <ins> // Bail if there's no body. FnKind::Fn(.., None) => return visit::walk_fn(self, fn_kind, sp), FnKind::Fn(FnCtxt::Free, ..) | FnKind::Fn(FnCtxt::Foreign, ..) => FnItemRibKind, </ins> FnKind::Fn(FnCtxt::Assoc(_), ..) | FnKind::Closure(..) => NormalRibKind, }; let previous_value = replace(&mut self.diagnostic_metadata.current_function, Some(sp));

<ins> fn main() {} trait Foo { fn fn_with_type_named_same_as_local_in_param(b: b); //~^ ERROR cannot find type `b` in this scope } </ins>

<ins> error[E0412]: cannot find type `b` in this scope --> $DIR/issue-69401-trait-fn-no-body-ty-local.rs:4:53 | LL |     fn fn_with_type_named_same_as_local_in_param(b: b); |                                                     ^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </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! cc the PR reviewer, and nominating for compiler team prioritization.
[triagebot] I never answer to pings from issues like this because they are routinely fixed by people working on the affected tools. shouldn't ping the reviewer in general. If there are issues with a tool upgrade, then ping can happen on the tool upgrade attempt PR.

Discussion:
<del> Subproject commit 8fbb23f2549e75b89967f09b9293607bd3bb96a6 </del> <ins> Subproject commit fc5d0cc583cb1cd35d58fdb7f3e0cfa12dccd6c0 </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.
triage: P-medium, removing nomination.

Discussion:
"rustc-workspace-hack", "rustc_version", "serde", <ins> "serde_json", </ins> "shell-escape", "vergen", ]

// Overwrite bootstrap's `rustc` wrapper overwriting our flags. cargo.env("RUSTC_DEBUG_ASSERTIONS", "true"); // Let cargo-miri know where xargo ended up. <del> cargo.env("XARGO", builder.out.join("bin").join("xargo")); </del> <ins> cargo.env("XARGO_CHECK", builder.out.join("bin").join("xargo-check")); </ins> let mut cargo = Command::from(cargo); if !try_run(builder, &mut cargo) {

<del> Subproject commit 3c444bf6a6cff3b9014005f21cc44995b34862ce </del> <ins> Subproject commit 974c8be95ec17cd986251d7700cd432a39576939 </ins>
Change:
<!-- 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. --I tried this code: and compiled it with: I expected to see asan report a bad pointer use and give a backtrace. Instead I just got a raw sigsegv: Running with verbose output shows that AddressSanitizer is intercepting the signal. It looks like is also installing a signal handler, which is overriding the AddressSanitizer one. <!-- 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. --: </p</details
(set handler and prevent override) is a workaround, but I think the Rust runtime shouldn't stomp SIGSEGV in the sanitizer case.
cc

Discussion:
pub unsafe fn new() -> Handler { make_handler() } <ins> fn null() -> Handler { Handler { _data: crate::ptr::null_mut() } } </ins> } impl Drop for Handler {

} static mut MAIN_ALTSTACK: *mut libc::c_void = ptr::null_mut(); <ins> static mut NEED_ALTSTACK: bool = false; </ins> pub unsafe fn init() { let mut action: sigaction = mem::zeroed(); <del> action.sa_flags = SA_SIGINFO | SA_ONSTACK; action.sa_sigaction = signal_handler as sighandler_t; sigaction(SIGSEGV, &action, ptr::null_mut()); sigaction(SIGBUS, &action, ptr::null_mut()); </del> <ins> for &signal in &[SIGSEGV, SIGBUS] { sigaction(signal, ptr::null_mut(), &mut action); // Configure our signal handler if one is not already set. if action.sa_sigaction == SIG_DFL { action.sa_flags = SA_SIGINFO | SA_ONSTACK; action.sa_sigaction = signal_handler as sighandler_t; sigaction(signal, &action, ptr::null_mut()); NEED_ALTSTACK = true; } } </ins> let handler = make_handler(); MAIN_ALTSTACK = handler._data;

} pub unsafe fn make_handler() -> Handler { <ins> if !NEED_ALTSTACK { return Handler::null(); } </ins> let mut stack = mem::zeroed(); sigaltstack(ptr::null(), &mut stack); // Configure alternate signal stack, if one is not already set.

sigaltstack(&stack, ptr::null_mut()); Handler { _data: stack.ss_sp as *mut libc::c_void } } else { <del> Handler { _data: ptr::null_mut() } </del> <ins> Handler::null() </ins> } }

target_os = "openbsd" )))] mod imp { <del> use crate::ptr; </del> pub unsafe fn init() {} pub unsafe fn cleanup() {} pub unsafe fn make_handler() -> super::Handler { <del> super::Handler { _data: ptr::null_mut() } </del> <ins> super::Handler::null() </ins> } pub unsafe fn drop_handler(_handler: &mut super::Handler) {}

<ins> // needs-sanitizer-support // only-x86_64 // // compile-flags: -Z sanitizer=address -O // // run-fail // error-pattern: AddressSanitizer: SEGV use std::ffi::c_void; extern "C" { fn free(ptr: *mut c_void); } fn main() { unsafe { free(1 as *mut c_void); } } </ins>
Change:
Rust's runtime installs a signal handler to distinguish stack overflows from other faults. This requires using an alternate signal stack (), which we create with the default size . That's usually quite small, 8KB or so depending on the target, but it's still plenty for what the handler is doing. There's currently no guard page like we have on normal stacks. That alternate stack is shared by all signals for a thread, so if a user installs any other signal handler, and they opt in with the flag , they'll be limited to the same tiny stack. If their handler happens to be more involved and overflows that stack, it may silently clobber other memory. If we had a guard page on the signal stack, that would cause a process abort instead. This was reported to the Security Response WG with a reproducer in . However, after discussion we decided to treat this as a normal issue for a few reasons: Setting a custom signal handler requires code. Signal handlers already run in a quite constrained environment, e.g. . It's unusual to use for signals other than , and if you choose so, you also bear responsibility to make sure that stack suffices. Nevertheless, as a defensive measure, it's still a reasonable idea to map a guard page when Rust is creating its signal stack, so an unexpected overflow will abort rather than silently corrupting memory. For full protection, that would also depend on the guard page not being skipped, but not all targets have stack probes yet (). Thanks to for reporting this in accordance with our , even though we have decided not to treat this as a security issue at this time. cc
cc This is another reason we perhaps shouldn't be registering the signal handler... cc

Discussion:
use libc::{mmap, munmap}; use libc::{sigaction, sighandler_t, SA_ONSTACK, SA_SIGINFO, SIGBUS, SIG_DFL}; use libc::{sigaltstack, SIGSTKSZ, SS_DISABLE}; <del> use libc::{MAP_ANON, MAP_PRIVATE, PROT_READ, PROT_WRITE, SIGSEGV}; </del> <ins> use libc::{MAP_ANON, MAP_PRIVATE, PROT_NONE, PROT_READ, PROT_WRITE, SIGSEGV}; use crate::sys::unix::os::page_size; </ins> use crate::sys_common::thread_info; #[cfg(any(target_os = "linux", target_os = "android"))]

} unsafe fn get_stackp() -> *mut libc::c_void { <del> let stackp = mmap(ptr::null_mut(), SIGSTKSZ, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0); </del> <ins> let stackp = mmap( ptr::null_mut(), SIGSTKSZ + page_size(), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANON, -1, 0, ); </ins> if stackp == MAP_FAILED { panic!("failed to allocate an alternative stack"); } <del> stackp </del> <ins> let guard_result = libc::mprotect(stackp, page_size(), PROT_NONE); if guard_result != 0 { panic!("failed to set up alternative stack guard page"); } stackp.add(page_size()) </ins> } #[cfg(any(

ss_size: SIGSTKSZ, }; sigaltstack(&stack, ptr::null_mut()); <del> munmap(handler._data, SIGSTKSZ); </del> <ins> // We know from `get_stackp` that the alternate stack we installed is part of a mapping // that started one page earlier, so walk back a page and unmap from there. munmap(handler._data.sub(page_size()), SIGSTKSZ + page_size()); </ins> } } }
Change:
I'm using clang/llvm to build (instead of gcc). make sure sanitizers are built: use llvm ar and ranlib fails to build: `
For the record, I am at I believe this is a recent regression, probably introduced in the last 1-2 days.
I'm wondering if this was caused by /
Nope, reverting that did not fix the build failure..
cc
AFAICS includes a fix (glibc 2.31 changed ABI: ).

Discussion:
<del> Subproject commit 027e428197f3702599cfbb632883768175f49173 </del> <ins> Subproject commit 9f9da27fbdb0ba7d887f8d2521e082f12b009417 </ins>
Change:
I tried this code (using ): I expected to see this happen: The thread should've panicked with 'Index out of bounds: the len is 0 but the index is 0' Instead, this happened: Thread crashes with SIGILL (illegal instruction) This bug works in stable, beta and nightly. It also does the same in . Here is my (I figured that it might be useful given the nature of the bug). The bug doesn't appear if run from main, nor if run directly (without passing from the Display impl). : <details<summaryBacktrace</summary<prunning 1 test thread panicked while processing panic. aborting. error: test failed, to rerun pass '--lib' Caused by: process didn't exit successfully: (signal: 4, SIGILL: illegal instruction) </p</details
This seems to be due to the . Using instead works fine.
I can reproduce. This seems to happen if LOCALSTDERR is initialized (e.g., with setpanic) which leads us to this . Note that the RefCell there is borrowed so that we can write to it, but then when we go to panic we try to temporarily . This borrows the RefCell mutably, again, leading to a panic. Since this happens within an existing panic, we abort the process. Smaller example:

Discussion:
{ let result = local_s .try_with(|s| { <del> if let Ok(mut borrowed) = s.try_borrow_mut() { if let Some(w) = borrowed.as_mut() { return w.write_fmt(args); } </del> <ins> // Note that we completely remove a local sink to write to in case // our printing recursively panics/prints, so the recursive // panic/print goes to the global sink instead of our local sink. let prev = s.borrow_mut().take(); if let Some(mut w) = prev { let result = w.write_fmt(args); *s.borrow_mut() = Some(w); return result; </ins> } global_s().write_fmt(args) })

<ins> // run-pass // ignore-emscripten no subprocess support #![feature(set_stdio)] use std::fmt; use std::fmt::{Display, Formatter}; use std::io::set_panic; pub struct A; impl Display for A { fn fmt(&self, _f: &mut Formatter<'_>) -> fmt::Result { panic!(); } } fn main() { set_panic(Some(Box::new(Vec::new()))); assert!(std::panic::catch_unwind(|| { eprintln!("{}", A); }) .is_err()); } </ins>

<ins> // compile-flags:--test // run-pass // ignore-emscripten no subprocess support use std::fmt; use std::fmt::{Display, Formatter}; pub struct A(Vec<u32>); impl Display for A { fn fmt(&self, _f: &mut Formatter<'_>) -> fmt::Result { self.0[0]; Ok(()) } } #[test] fn main() { let result = std::panic::catch_unwind(|| { let a = A(vec![]); eprintln!("{}", a); }); assert!(result.is_err()); } </ins>
Change:
This code leaks the at : The leak was introduced in . cc
We could avoid the leak and the by doing or if we're concerned about performance here, we could maybe do something with .
Thanks for the report, I will measure the perf effects of the different alternatives. I'd like to know how you found this -- code inspection? Some kind of tool?
I found it while running and noticing that I kept running out of memory. I turned on and this popped out.
Another alternative could be to call to swap in a dummy diagnostic, instead of cloning the existing one.
Below is an example compiler input that triggers the leak:
Simpler example that triggers the leak: just a single closing brace

Discussion:
let handler = self.0.handler; <del> // We need to use `ptr::read` because `DiagnosticBuilder` implements `Drop`. let diagnostic; unsafe { diagnostic = std::ptr::read(&self.0.diagnostic); std::mem::forget(self); }; </del> <ins> // We must use `Level::Cancelled` for `dummy` to avoid an ICE about an // unused diagnostic. let dummy = Diagnostic::new(Level::Cancelled, ""); let diagnostic = std::mem::replace(&mut self.0.diagnostic, dummy); </ins> // Logging here is useful to help track down where in logs an error was // actually emitted. debug!("buffer: diagnostic={:?}", diagnostic);
Change:
ran cargo-bisect-rustc on this. It reports: searched nightlies: from nightly-2019-11-18 to nightly-2019-12-02 regressed nightly: nightly-2019-12-02 searched commits: from to regressed commit:
i.e. this was injected by (rollup) PR its not immediately obvious to me which associated PR from that rollup is to blame. Maybe ?
The ICE no longer occurs with latest nightly, I guess fixed it. Marked as E-needs-test.

Discussion:
<ins> #![feature(const_generics)] #![allow(incomplete_features)] trait Bar<O> {} impl<O> Bar<O> for [u8; O] {} //~^ ERROR expected value, found type parameter `O` struct Foo<const O: usize> {} impl<const O: usize> Foo<O> where [u8; O]: Bar<[(); O]>, { fn foo() {} } fn main() { Foo::foo(); } </ins>

<ins> error[E0423]: expected value, found type parameter `O` --> $DIR/issue-69654.rs:5:25 | LL | impl<O> Bar<O> for [u8; O] {} |                         ^ help: a tuple variant with a similar name exists: `Ok` | ::: $SRC_DIR/libcore/result.rs:LL:COL | LL |     Ok(#[stable(feature = "rust1", since = "1.0.0")] T), |     --------------------------------------------------- similarly named tuple variant `Ok` defined here error: aborting due to previous error For more information about this error, try `rustc --explain E0423`. </ins>
Change:
The following works (as does ): However, and run into a type inference bug: The definitions of and are similar_, but is only parameterized by (the type of the contained ) while also has an parameter (the type of the yielded element). It seems the type of the element is unable to be inferred from , where is an .
is a working hack to avoid this issue, but we should fix the underlying cause.
I have also hit this problem, but in my case, I end up needing to use four dummy type parameters and still needed to provide a hint when called. This is not tenable as a usable API. I'm going to nominate this. I'm not sure what for, I'm thinking well-covered as this limits how complex you can feasibly make your types (not very, it turns out).

Discussion:
/// assert_eq!(it.next().get(), &5); /// assert!(it.next().is_none()); /// ~~~ <del> fn skip(self, n: uint) -> SkipIterator<Self>; </del> <ins> fn skip(self, n: uint) -> SkipIterator<A, Self>; </ins> /// Creates an iterator which yields the first `n` elements of this /// iterator, and then it will always return None.

/// assert_eq!(it.next().get(), &3); /// assert!(it.next().is_none()); /// ~~~ <del> fn take(self, n: uint) -> TakeIterator<Self>; </del> <ins> fn take(self, n: uint) -> TakeIterator<A, Self>; </ins> /// Creates a new iterator which behaves in a similar fashion to foldl. /// There is a state which is passed between each iteration and can be

} #[inline(always)] <del> fn skip(self, n: uint) -> SkipIterator<T> { </del> <ins> fn skip(self, n: uint) -> SkipIterator<A, T> { </ins> SkipIterator{iter: self, n: n} } #[inline(always)] <del> fn take(self, n: uint) -> TakeIterator<T> { </del> <ins> fn take(self, n: uint) -> TakeIterator<A, T> { </ins> TakeIterator{iter: self, n: n} }

} } <del> /// An iterator which skips over `n` elements of `iter` pub struct SkipIterator<T> { </del> <ins> /// An iterator which skips over `n` elements of `iter`. // FIXME #6967: Dummy A parameter to get around type inference bug pub struct SkipIterator<A, T> { </ins> priv iter: T, priv n: uint } <del> impl<A, T: Iterator<A>> Iterator<A> for SkipIterator<T> { </del> <ins> impl<A, T: Iterator<A>> Iterator<A> for SkipIterator<A, T> { </ins> #[inline] fn next(&mut self) -> Option<A> { let mut next = self.iter.next();

} /// An iterator which only iterates over the first `n` iterations of `iter`. <del> pub struct TakeIterator<T> { </del> <ins> // FIXME #6967: Dummy A parameter to get around type inference bug pub struct TakeIterator<A, T> { </ins> priv iter: T, priv n: uint } <del> impl<A, T: Iterator<A>> Iterator<A> for TakeIterator<T> { </del> <ins> impl<A, T: Iterator<A>> Iterator<A> for TakeIterator<A, T> { </ins> #[inline] fn next(&mut self) -> Option<A> { let next = self.iter.next();

let ys = [13, 15, 16, 17, 19, 20, 30]; let mut it = xs.iter().skip(5); let mut i = 0; <del> for it.advance |&x: &uint| { </del> <ins> for it.advance |&x| { </ins> assert_eq!(x, ys[i]); i += 1; }

let ys = [0u, 1, 2, 3, 5]; let mut it = xs.iter().take(5); let mut i = 0; <del> for it.advance |&x: &uint| { </del> <ins> for it.advance |&x| { </ins> assert_eq!(x, ys[i]); i += 1; }
Change:
I tried code very similar to this: and it produces some type of type checking error when uncommenting the line beginning with . : Backtrace:
The error is likely due to the fact that the trait bounds on don't include for , though the compiler/type checker crashing is still likely a bug.
That code was introduced in , cc Submitted as a quick fix.
I can't get it to work in the same crate, just with two crates, where the first one depends on the other: modify labels: -E-needs-mcve
Thanks I included a test in the PR.

Discussion:
(&self_ty.kind, parent_pred) { if let ty::Adt(def, _) = p.skip_binder().trait_ref.self_ty().kind { <del> let id = self.tcx.hir().as_local_hir_id(def.did).unwrap(); let node = self.tcx.hir().get(id); </del> <ins> let node = self .tcx .hir() .as_local_hir_id(def.did) .map(|id| self.tcx.hir().get(id)); </ins> match node { <del> hir::Node::Item(hir::Item { kind, .. }) => { </del> <ins> Some(hir::Node::Item(hir::Item { kind, .. })) => { </ins> if let Some(g) = kind.generics() { let key = match &g.where_clause.predicates[..] { [.., pred] => {

<ins> #[derive(Clone)] pub struct Struct<A>(A); impl<A> Struct<A> { pub fn new() -> Self { todo!() } } </ins>

<ins> // aux-build:issue-69725.rs extern crate issue_69725; use issue_69725::Struct; fn crash<A>() { let _ = Struct::<A>::new().clone(); //~^ ERROR: no method named `clone` found } fn main() {} </ins>

<ins> error[E0599]: no method named `clone` found for struct `issue_69725::Struct<A>` in the current scope --> $DIR/issue-69725.rs:7:32 | LL |     let _ = Struct::<A>::new().clone(); |                                ^^^^^ method not found in `issue_69725::Struct<A>` | ::: $DIR/auxiliary/issue-69725.rs:2:1 | LL | pub struct Struct<A>(A); | ------------------------ doesn't satisfy `issue_69725::Struct<A>: std::clone::Clone` | = note: the method `clone` exists but the following trait bounds were not satisfied: `A: std::clone::Clone` which is required by `issue_69725::Struct<A>: std::clone::Clone` error: aborting due to previous error For more information about this error, try `rustc --explain E0599`. </ins>
Change:
has to but the PR made it only into Rust 1.42.0. Thus the version number should be adjusted. cc
We would be happy to accept a PR for this. I suppose it's a trivial enough fix that I would even be willing to backport it (so we avoid 1.42 indicating incorrectly), but only if we get it in quickly enough. cc re:backport, since you're doing release
I won't do it but it should be easy enough.
I just made a PR for updating this; this is my first contribution to the project (please let me know if I did the process right). Hope that helps!
I just noticed this and saw a PR already existed, amazing! to a backport.

Discussion:
/// } /// ``` #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_deprecated(since = "1.41.0", reason = "use the Display impl or to_string()")] </del> <ins> #[rustc_deprecated(since = "1.42.0", reason = "use the Display impl or to_string()")] </ins> fn description(&self) -> &str { "description() is deprecated; use Display" }