jiebi/CodeConvo huggingface dataset:
Change:
Probably somewhat related to This ICE's on stable, beta and nightly: Playground: Backtrace:
The ICE doesn't appear on the latest nightly (), marked as E-needstest

Discussion:
<ins> // ignore-emscripten no asm! support #![feature(asm)] fn main() { unsafe { asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} //~^ ERROR: invalid value for constraint in inline assembly } } </ins>

<ins> error[E0669]: invalid value for constraint in inline assembly --> $DIR/issue-51431.rs:7:32 | LL |         asm! {"mov $0,$1"::"0"("bx"),"1"(0x00)} |                                ^^^^ error: aborting due to previous error </ins>

<ins> trait A { const C: usize; fn f() -> ([u8; A::C], [u8; A::C]); //~^ ERROR: type annotations needed: cannot resolve //~| ERROR: type annotations needed: cannot resolve } fn main() {} </ins>

<ins> error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:21 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                     ^^^^ error[E0283]: type annotations needed: cannot resolve `_: A` --> $DIR/issue-63496.rs:4:33 | LL |     const C: usize; |     --------------- required by `A::C` LL | LL |     fn f() -> ([u8; A::C], [u8; A::C]); |                                 ^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0283`. </ins>

<ins> trait T<'x> { type V; } impl<'g> T<'g> for u32 { type V = u16; } fn main() { (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); //~^ ERROR: type mismatch in closure arguments //~| ERROR: type mismatch resolving } </ins>

<ins> error[E0631]: type mismatch in closure arguments --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^-----^ |     | | |     | found signature of `fn(_) -> _` |     expected signature of `for<'x> fn(<u32 as T<'x>>::V) -> _` | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error[E0271]: type mismatch resolving `for<'x> <[closure@$DIR/issue-41366.rs:10:7: 10:12] as std::ops::FnOnce<(<u32 as T<'x>>::V,)>>::Output == ()` --> $DIR/issue-41366.rs:10:5 | LL |     (&|_|()) as &dyn for<'x> Fn(<u32 as T<'x>>::V); |     ^^^^^^^^ expected bound lifetime parameter 'x, found concrete lifetime | = note: required for the cast to the object type `dyn for<'x> std::ops::Fn(<u32 as T<'x>>::V)` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>

<ins> fn main() { [(); &(&'static: loop { |x| {}; }) as *const _ as usize] //~^ ERROR: invalid label name `'static` //~| ERROR: type annotations needed } </ins>

<ins> error: invalid label name `'static` --> $DIR/issue-52437.rs:2:13 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |             ^^^^^^^ error[E0282]: type annotations needed --> $DIR/issue-52437.rs:2:30 | LL |     [(); &(&'static: loop { |x| {}; }) as *const _ as usize] |                              ^ consider giving this closure parameter a type error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0282`. </ins>
Change:
I was pointed at on IRC earlier, but couldn't use it with because that just gives a . Had had a "See also" link to , I would have found it without complaining that I couldn't use . And for similar reasons, should See Also to for those who do want to copy a file based on paths and not readers and writers.
I opened a PR for this:

Discussion:
/// On success, the total number of bytes copied is returned and it is equal to /// the length of the `to` file as reported by `metadata`. /// <ins> /// If you’re wanting to copy the contents of one file to another and you’re /// working with [`File`]s, see the [`io::copy`] function. /// /// [`io::copy`]: ../io/fn.copy.html /// [`File`]: ./struct.File.html /// </ins> /// # Platform-specific behavior /// /// This function currently corresponds to the `open` function in Unix

/// On success, the total number of bytes that were copied from /// `reader` to `writer` is returned. /// <ins> /// If you’re wanting to copy the contents of one file to another and you’re /// working with filesystem paths, see the [`fs::copy`] function. /// /// [`fs::copy`]: ../fs/fn.copy.html /// </ins> /// # Errors /// /// This function will return an error immediately if any call to `read` or
Change:
This is the code you are supposed to use according to the lint. It fails to compile, with It compiles fine if you use just one of the two attributes. Swapping attribute order makes it complain about the last non-derive attribute. This seems broken? cc
Confirmed, this behavior is broken. Possibly related to .
As a workaround specific to serde_derive, we allow multiple elements within one attribute.
yeah, that's what I ended up doing
This should be fixed in

Discussion:
InvocationKind::Derive { ref path, .. } => path.span, } } <ins> pub fn attr_id(&self) -> Option<ast::AttrId> { match self.kind { InvocationKind::Attr { attr: Some(ref attr), .. } => Some(attr.id), _ => None, } } </ins> } pub struct MacroExpander<'a, 'b:'a> {

let scope = if self.monotonic { invoc.expansion_data.mark } else { orig_expansion_data.mark }; <ins> let attr_id_before = invoc.attr_id(); </ins> let ext = match self.cx.resolver.resolve_invoc(&mut invoc, scope, force) { Ok(ext) => Some(ext), Err(Determinacy::Determined) => None, Err(Determinacy::Undetermined) => { <ins> // Sometimes attributes which we thought were invocations // end up being custom attributes for custom derives. If // that's the case our `invoc` will have changed out from // under us. If this is the case we're making progress so we // want to flag it as such, and we test this by looking if // the `attr_id()` method has been changing over time. if invoc.attr_id() != attr_id_before { progress = true; } </ins> undetermined_invocations.push(invoc); continue }

<ins> // Copyright 2018 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. // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::*; #[proc_macro_derive(A, attributes(b))] pub fn foo(_x: TokenStream) -> TokenStream { TokenStream::new() } </ins>

<ins> // Copyright 2018 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. // aux-build:derive-two-attrs.rs #![feature(use_extern_macros)] extern crate derive_two_attrs as foo; use foo::A; #[derive(A)] #[b] #[b] struct B; fn main() {} </ins>
Change:
Symptom: On Windows, the libstd test panicked for unexpectedly connected to a local closed TCP socket without timing out. Previous instances: 2018-05-19T07:41:59Z — (i686-msvc-1) 2018-06-04T15:32:27Z — (i686-mingw-1) 2018-06-30T14:00:20Z — (x86_64-mingw) 2018-07-21T18:51:09Z — (i686-msvc-1)
From the logs, the TCP port of both the TcpStream (self) and TcpListener (socket, dropped) are the same. : : : : According to the dynamic port range is 1025 to 5000 inclusive, so the collision rate is ≈1/3976 per build if uniformly distributed.
I've seen this on my Linux box recently, so much so that I think it has become a permafail.

Discussion:
} #[test] <del> fn connect_timeout_unbound() { // bind and drop a socket to track down a "probably unassigned" port let socket = TcpListener::bind("127.0.0.1:0").unwrap(); let addr = socket.local_addr().unwrap(); drop(socket); let timeout = Duration::from_secs(1); let e = TcpStream::connect_timeout(&addr, timeout).unwrap_err(); assert!(e.kind() == io::ErrorKind::ConnectionRefused || e.kind() == io::ErrorKind::TimedOut || e.kind() == io::ErrorKind::Other, "bad error: {} {:?}", e, e.kind()); } #[test] </del> fn connect_timeout_valid() { let listener = TcpListener::bind("127.0.0.1:0").unwrap(); let addr = listener.local_addr().unwrap();
Change:
In / , we reworded the error methods for type-mismatches-in-matches when the match comes from a -expression, and a suggestion to -wrap the expression. While that's often the right fix (notably, when a -expression is in tail position of a function that returns ), sometimes it isn't. Here's a counterexample: Currently, we emit: We should, somehow, not issue the "try wrapping with a success variant" suggestion (which lives in ) in cases like these.
Turns out this was already filed as .

Discussion:
err.span_label(arm_span, msg); } } <del> hir::MatchSource::TryDesugar => { // Issue #51632 if let Ok(try_snippet) = self.tcx.sess.source_map().span_to_snippet(arm_span) { err.span_suggestion_with_applicability( arm_span, "try wrapping with a success variant", format!("Ok({})", try_snippet), Applicability::MachineApplicable, ); } } </del> <ins> hir::MatchSource::TryDesugar => {} </ins> _ => { let msg = "match arm with an incompatible type"; if self.tcx.sess.source_map().is_multiline(arm_span) {

<del> // Copyright 2018 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. // run-rustfix #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> { Ok(1) } fn forbidden_narratives() -> Result<isize, ()> { Ok(missing_discourses()?) //~^ ERROR try expression alternatives have incompatible types //~| HELP try wrapping with a success variant } fn main() {} </del>

// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // run-rustfix </del> #![allow(dead_code)] fn missing_discourses() -> Result<isize, ()> {

fn forbidden_narratives() -> Result<isize, ()> { missing_discourses()? //~^ ERROR try expression alternatives have incompatible types <del> //~| HELP try wrapping with a success variant </del> } fn main() {}

error[E0308]: try expression alternatives have incompatible types <del> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:20:5 </del> <ins> --> $DIR/issue-51632-try-desugar-incompatible-types.rs:18:5 </ins> | LL |     missing_discourses()? <del> |     ^^^^^^^^^^^^^^^^^^^^^ |     | |     expected enum `std::result::Result`, found isize |     help: try wrapping with a success variant: `Ok(missing_discourses()?)` </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^ expected enum `std::result::Result`, found isize </ins> | = note: expected type `std::result::Result<isize, ()>` found type `isize`
Change:
This works with no : I expect this to be fixed with , but wanted to file explicitly for tracking.

Discussion:
(active, abi_x86_interrupt, "1.17.0", Some(40180), None), // Allows the `catch {...}` expression <del> (active, catch_expr, "1.17.0", Some(31436), Some(Edition::Edition2018)), </del> <ins> (active, catch_expr, "1.17.0", Some(31436), None), </ins> // Used to preserve symbols (see llvm.used) (active, used, "1.18.0", Some(40289), None),
Change:
Error: This only happens after cc The code that triggered this is .
cc seems like we need to report an error instead of panicking as originally written
Oh it's probably because we do promote
created a fix in , but I have no minimal repro and no time today
To clarify: you're making this an error? I don't see why we can't allow to be promoted.
good point
This ICE is currently causing errors in the , and crates in
I have tried building and it does not reproduce the issue for me on master or nightly :confused: trying a stage2 build now still can't repro on regex, but can repro on OPs file now.
ok, fix exists now
It looks like we've fixed the ICE here but there's still a change in behavior here, as well as a faulty diagnostic; this is while compiling cargo-registry from (at least the version in rustc-perf).

Discussion:
}), } } <del> // promoteds may never be mutated Place::Promoted(_) => bug!("encountered mutable promoted"), </del> <ins> // The rules for promotion are made by `qualify_consts`, there wouldn't even be a // `Place::Promoted` if the promotion weren't 100% legal. So we just forward this Place::Promoted(_) => Ok(RootPlace { place, is_local_mutation_allowed, }), </ins> Place::Static(ref static_) => { if self.tcx.is_static(static_.def_id) != Some(hir::Mutability::MutMutable) { Err(place)

<ins> // Copyright 2018 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. // compile-pass #![feature(nll)] pub fn main() { let y: &'static mut [u8; 0] = &mut []; } </ins>
Change:
Error: This only happens after cc The code that triggered this is .
cc seems like we need to report an error instead of panicking as originally written
Oh it's probably because we do promote
created a fix in , but I have no minimal repro and no time today
To clarify: you're making this an error? I don't see why we can't allow to be promoted.
good point
This ICE is currently causing errors in the , and crates in
I have tried building and it does not reproduce the issue for me on master or nightly :confused: trying a stage2 build now still can't repro on regex, but can repro on OPs file now.
ok, fix exists now
It looks like we've fixed the ICE here but there's still a change in behavior here, as well as a faulty diagnostic; this is while compiling cargo-registry from (at least the version in rustc-perf).

Discussion:
} (Place::Promoted(p1), Place::Promoted(p2)) => { if p1.0 == p2.0 { <ins> if let ty::TyArray(_, size) = p1.1.sty { if size.unwrap_usize(tcx) == 0 { // Ignore conflicts with promoted [T; 0]. debug!("place_element_conflict: IGNORE-LEN-0-PROMOTED"); return Overlap::Disjoint; } } </ins> // the same promoted - base case, equal debug!("place_element_conflict: DISJOINT-OR-EQ-PROMOTED"); Overlap::EqualOrDisjoint

<ins> // Copyright 2018 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. // Check that mutable promoted length zero arrays don't check for conflicting // access // run-pass #![feature(nll)] pub fn main() { let mut x: Vec<&[i32; 0]> = Vec::new(); for i in 0..10 { x.push(&[]); } } </ins>
Change:
Reducing the number of built LLVM targets reduces time to build LLVM. Previously was enough to pass the testing successfully on a typical x86 machine, but recently one test (, cc ) was that requires enabling Sparc as well. Target specific tests like this should preferably be somehow ignored if necessary LLVM targets are not built, or simply not included into the test suite.
The test should be marked , which is the complement of .
Hmm, is a tad too restrictive than I’d like, but since I know of no other solution, lets just add that.

Discussion:
// Checks that we correctly codegen extern "C" functions returning structs. // See issue #52638. <ins> // only-sparc64 </ins> // compile-flags: -O --target=sparc64-unknown-linux-gnu --crate-type=rlib #![feature(no_core, lang_items)] #![no_core]
Change:
Not sure if it's really something that is ever gonna happen in real code, but the following ICE's: <details<summaryBacktrace:</summary</details
Just figured out that declaring the existential type like this: won't panic. I guess because its being copied? But I think that it should not be allowed,
A version without transmutes and , but with pointer casts instead:

Discussion:
) -> Option<Const<'tcx>> { let span = source_info.span; match *rvalue { <del> // This branch exists for the sanity type check Rvalue::Use(Operand::Constant(ref c)) => { assert_eq!(c.ty, place_layout.ty); self.eval_constant(c, source_info) }, </del> Rvalue::Use(ref op) => { self.eval_operand(op, source_info) },

<ins> // Copyright 2018 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. // compile-pass macro_rules! m { () => {{ fn f(_: impl Sized) {} f }} } fn main() { fn f() -> impl Sized {}; m!()(f()); } </ins>
Change:
ICE's in 2018 edition, compiles fine in 2015 edition: <details<summaryBacktrace:</summary</details
Looks like this is a victim of "late delayspanbug" reporting. Apparently the span interner does not exist anymore at this point. I think is the call that fails. Not sure where GLOBALS is emptied. After that has been fixed, we should be seeing the actual bug :laughing:
So now we can actually see the bug: For a real backtrace we'd need to compile this with
As of now, compiles just fine! I could add this as a test somewhere? But Im not sure where I should put it.

Discussion:
<ins> // check-pass #![feature(const_fn)] #![feature(type_alias_impl_trait)] type Foo = impl Fn() -> usize; const fn bar() -> Foo { || 0usize } const BAZR: Foo = bar(); fn main() {} </ins>
Change:
This happens on Windows 7, cannot test on newer Windows. Basically, something wrong happens with file handles when using the macro, not sure what exactly. Minimal repro: Actual output: Expected output: Sorry for German localization in the error messages. I noticed this because of some obscure behaviour in the windows API (a function returned != 0, but LastError wasn't set accordingly). cc cc
Additional info: I am using stable rust 1.28
Works for me on Windows 10: 1.27.2 1.28 beta nightly Can't test Windows 7 :( sorry
Does it occur more than once? (e.g. can you reproduce it?)
Yes, this happens every time I execute the program
("Das Handle ist ungültig" means "The handle is invalid" in English)
Seems like it could be this call:
Windows system functions generally guarantee that they will set the last error when they fail, but offer no guarantees as to the state of the last error when they succeed (some may clear the error, some may leave it alone, some may change it). The only action that Rust could take here is for any libstd function that calls system functions to clear the last error when it returns success.
I'm using on windows 7 (which is just the mingw terminal if I'm not mistaken). Probably that resolves to in the call you mentioned. Maybe we should in that branch? I understand this is not really a bug (if the function errors, we have a pipe, otherwise a terminal), but perhaps we can reduce the confusion if we reset the OS error in the former case.
Personally I'd rather that Rust offer no guarantees about the result of when called after any libstd function that calls some system function. It should only be used directly after calling a system function yourself and only when that function is documented to have set the last error. There is a case to be made here about documenting this though.
Triage: I agree, though we should get signoff before re-categorizing this bug.
Same problem. As I see line break affects. Normal: Normal: Bug: Bug: Windows 10 51.0-nightly 49.0-stable

Discussion:
/// `GetLastError` on Windows) and will return a corresponding instance of /// [`Error`] for the error code. /// <ins> /// This should be called immediately after a call to a platform function, /// otherwise the state of the error value is indeterminate. In particular, /// other standard library functions may call platform functions that may /// (or may not) reset the error value even if they succeed. /// </ins> /// # Examples /// /// ``` /// use std::io::Error; /// <del> /// println!("last OS error: {:?}", Error::last_os_error()); </del> <ins> /// let os_error = Error::last_os_error(); /// println!("last OS error: {:?}", os_error); </ins> /// ``` #[stable(feature = "rust1", since = "1.0.0")] #[must_use]
Change:
This code triggers this ICE with rustc 1.29.0-beta.2 ( 2018-08-05) but compiles fine with current stable 1.28.0:

Discussion:
) -> Option<Const<'tcx>> { let span = source_info.span; match *rvalue { <del> // This branch exists for the sanity type check Rvalue::Use(Operand::Constant(ref c)) => { assert_eq!(c.ty, place_layout.ty); self.eval_constant(c, source_info) }, </del> Rvalue::Use(ref op) => { self.eval_operand(op, source_info) },

<ins> // Copyright 2018 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. // compile-pass macro_rules! m { () => {{ fn f(_: impl Sized) {} f }} } fn main() { fn f() -> impl Sized {}; m!()(f()); } </ins>
Change:
The following code panics: The problem is that env assumes that environ is not null. See The function on linux is often implemented by freeing environ and setting it to null. See and In my opinion the stdlib could handle this more gracefully and return an empty iterator instead of panicking
I'm working on a PR.

Discussion:
unsafe { let _guard = ENV_LOCK.lock(); let mut environ = *environ(); <del> if environ == ptr::null() { panic!("os::env() failure getting env string from OS: {}", io::Error::last_os_error()); } </del> let mut result = Vec::new(); <del> while *environ != ptr::null() { </del> <ins> while environ != ptr::null() && *environ != ptr::null() { </ins> if let Some(key_value) = parse(CStr::from_ptr(*environ).to_bytes()) { result.push(key_value); }

<ins> // Copyright 2018 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. // ignore-windows // ignore-wasm32-bare no libc to test ffi with // issue-53200 #![feature(libc)] extern crate libc; use std::env; // FIXME: more platforms? #[cfg(target_os = "linux")] fn main() { unsafe { libc::clearenv(); } assert_eq!(env::vars().count(), 0); } #[cfg(not(target_os = "linux"))] fn main() {} </ins>