jiebi/CodeConvo huggingface dataset:
Change:
Version: The second function call is necessary. It will compile and run just fine with only one call. Output:
This may be irrelevant to async-await, as we can replace with any trait and still reproduces:

Discussion:
let mut opaque_types = self.opaque_types.borrow_mut(); for (ty, decl) in opaque_type_map { <del> let old_value = opaque_types.insert(ty, decl); assert!(old_value.is_none(), "instantiated twice: {:?}/{:?}", ty, decl); </del> <ins> let _ = opaque_types.insert(ty, decl); </ins> } value

<ins> // check-pass #![feature(type_alias_impl_trait)] type T = impl Sized; // The concrete type referred by impl-trait-type-alias(`T`) is guaranteed // to be the same as where it occurs, whereas `impl Trait`'s instance is location sensitive; // so difference assertion should not be declared on impl-trait-type-alias's instances. // for details, check RFC-2515: // https://github.com/rust-lang/rfcs/blob/master/text/2515-type_alias_impl_trait.md fn take(_: fn() -> T) {} fn main() { take(|| {}); take(|| {}); } </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.

Discussion:
[[package]] name = "compiletest_rs" <del> version = "0.3.24" </del> <ins> version = "0.3.25" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "676a74b493d50ac33cacd83fd536597e6b52c0b46b9856f7b9c809d82fef4ac0" </del> <ins> checksum = "f75b10a18fb53549fdd090846eb01c7f8593914494d1faabc4d3005c436e417a" </ins> dependencies = [ "diff", "filetime",

} } <del> #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy)] </del> <ins> // Clippy uses Hash and PartialEq #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy, Hash, PartialEq)] </ins> pub enum StrStyle { /// A regular string, like `"foo"`. Cooked,

pub span: Span, } <del> #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy)] </del> <ins> // Clippy uses Hash and PartialEq #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Copy, Hash, PartialEq)] </ins> pub enum LitIntType { Signed(IntTy), Unsigned(UintTy),

/// Literal kind. /// /// E.g., `"foo"`, `42`, `12.34`, or `bool`. <del> #[derive(Clone, RustcEncodable, RustcDecodable, Debug)] </del> <ins> // Clippy uses Hash and PartialEq #[derive(Clone, RustcEncodable, RustcDecodable, Debug, Hash, PartialEq)] </ins> pub enum LitKind { /// A string literal (`"foo"`). Str(Symbol, StrStyle),

pub use self::ColorConfig::*; pub use self::types::*; pub use self::types::TestName::*; <del> pub use self::options::{Options, ShouldPanic}; </del> <ins> pub use self::options::{ColorConfig, Options, OutputFormat, RunIgnored, ShouldPanic}; </ins> pub use self::bench::{Bencher, black_box}; <ins> pub use self::console::run_tests_console; pub use cli::TestOpts; </ins> // Module to be used by rustc to compile tests in libtest pub mod test {

use test_result::*; use time::TestExecTime; <del> use options::{RunStrategy, Concurrent, RunIgnored, ColorConfig}; </del> <ins> use options::{RunStrategy, Concurrent}; </ins> use event::{CompletedTest, TestEvent}; <del> use cli::TestOpts; </del> use helpers::sink::Sink; use helpers::concurrency::get_concurrency; use helpers::exit_code::get_exit_code;

<del> Subproject commit cbedd97b3a58023eff365a2fa74700d06115144a </del> <ins> Subproject commit e8d5a9e95c145a3a9be89c582d8a6f88d4ea7037 </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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 I-nominated.

Discussion:
extra_features: Vec::new(), }); if let Some(miri) = miri { <ins> let mut cargo = builder.cargo(compiler, Mode::ToolRustc, host, "install"); cargo.arg("xargo"); // Configure `cargo install` path. cargo adds a `bin/`. cargo.env("CARGO_INSTALL_ROOT", &builder.out); let mut cargo = Command::from(cargo); if !try_run(builder, &mut cargo) { return; } </ins> // # Run `cargo miri setup`. <del> // As a side-effect, this will install xargo. </del> let mut cargo = tool::prepare_tool_cargo( builder, compiler,

cargo.env("XARGO_RUST_SRC", builder.src.join("src")); // Debug things. cargo.env("RUST_BACKTRACE", "1"); <del> // Configure `cargo install` path, and let cargo-miri know that that's where // xargo ends up. cargo.env("CARGO_INSTALL_ROOT", &builder.out); // cargo adds a `bin/` </del> <ins> // Let cargo-miri know where xargo ended up. </ins> cargo.env("XARGO", builder.out.join("bin").join("xargo")); let mut cargo = Command::from(cargo);

<del> Subproject commit fccb2398248802a268fcda544ff3945247ef2119 </del> <ins> Subproject commit d9ae0285169e52050416fb3618f05b5fdf582b6b </ins>
Change:
Consider the following code: The borrow of the tuple field in is promoted out along with the tuple itself in accordance with the rules for rvalue static promotion. However, in the , the mechanism for promotion does not remove / for the tuple, causing to dangle. On stable, this is only caught during const-evaluation and results in a warning. If this warning is supressed, an ICE occurs. On nightly, the MIR borrow checker prevents this from happening, and this code is rejected instead. It should be accepted in all contexts.

Discussion:
} else { self.valid_promotion_candidates() }; debug!("qualify_const: promotion_candidates={:?}", promotion_candidates); for candidate in promotion_candidates { match candidate { <del> Candidate::Repeat(Location { block: bb, statement_index: stmt_idx }) => { if let StatementKind::Assign(box(_, Rvalue::Repeat( Operand::Move(place), _ ))) = &self.body[bb].statements[stmt_idx].kind { if let Some(index) = place.as_local() { promoted_temps.insert(index); } } } </del> Candidate::Ref(Location { block: bb, statement_index: stmt_idx }) => { <del> if let StatementKind::Assign( box( _, Rvalue::Ref(_, _, place) ) ) = &self.body[bb].statements[stmt_idx].kind { if let Some(index) = place.as_local() { promoted_temps.insert(index); </del> <ins> if let StatementKind::Assign(box( _, Rvalue::Ref(_, _, place))) = &self.body[bb].statements[stmt_idx].kind { if let PlaceBase::Local(local) = place.base { promoted_temps.insert(local); </ins> } } } <del> Candidate::Argument { .. } => {} </del> <ins> // Only rvalue-static promotion requires extending the lifetime of the promoted // local. Candidate::Argument { .. } | Candidate::Repeat(_) => {} </ins> } }

<ins> // run-pass // From https://github.com/rust-lang/rust/issues/65727 const _: &i32 = { let x = &(5, false).0; x }; fn main() { let _: &'static i32 = &(5, false).0; } </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.
triage: P-medium. Removing I-nominated.
There is opening PR to fix this:

Discussion:
] [[package]] <ins> name = "cargo_metadata" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "8d2d1617e838936c0d2323a65cc151e03ae19a7678dd24f72bccf27119b90a5d" dependencies = [ "semver", "serde", "serde_derive", "serde_json", ] [[package]] </ins> name = "cargotest2" version = "0.1.0"

name = "clippy" version = "0.0.212" dependencies = [ <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.9.0", </ins> "clippy-mini-macro-test", "clippy_lints", "compiletest_rs",

name = "clippy_lints" version = "0.0.212" dependencies = [ <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.9.0", </ins> "if_chain", "itertools 0.8.0", "lazy_static 1.3.0",

version = "0.1.0" dependencies = [ "byteorder", <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.8.0", </ins> "colored", "compiletest_rs", "directories",

version = "1.39.0" dependencies = [ "cargo", <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.8.0", </ins> "clippy_lints", "crossbeam-channel", "difference",

dependencies = [ "annotate-snippets", "bytecount", <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.8.0", </ins> "derive-new", "diff", "dirs",

<del> Subproject commit e8d5a9e95c145a3a9be89c582d8a6f88d4ea7037 </del> <ins> Subproject commit 8ab24d76dd6990394e72e94d08021df9a7e4e6c9 </ins>
Change:
Tracking issue for by See
Anything holding up stabilization on this? I'd like to be able to use this to check if two slices overlap, as pointers implement . It seems like a simple API that doesn't have a ton of complexity to it.
Note that with these functions can be made . The stabilization of these methods as can just be tracked as part of .
Thanks! PR: .

Discussion:
/// element of this slice: /// /// ``` <del> /// #![feature(slice_ptr_range)] /// </del> /// let a = [1, 2, 3]; /// let x = &a[1] as *const _; /// let y = &5 as *const _;

/// ``` /// /// [`as_ptr`]: #method.as_ptr <del> #[unstable(feature = "slice_ptr_range", issue = "65807")] </del> <ins> #[stable(feature = "slice_ptr_range", since = "1.48.0")] </ins> #[rustc_const_unstable(feature = "const_ptr_offset", issue = "71499")] #[inline] pub const fn as_ptr_range(&self) -> Range<*const T> {

/// common in C++. /// /// [`as_mut_ptr`]: #method.as_mut_ptr <del> #[unstable(feature = "slice_ptr_range", issue = "65807")] </del> <ins> #[stable(feature = "slice_ptr_range", since = "1.48.0")] </ins> #[rustc_const_unstable(feature = "const_ptr_offset", issue = "71499")] #[inline] pub const fn as_mut_ptr_range(&mut self) -> Range<*mut T> {
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.

Discussion:
<del> Subproject commit 66df92aeba64547f3e9600635a30df34b12a11d8 </del> <ins> Subproject commit c8e3cfbdd997839c771ca32c7ac860fe95149a04 </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri 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: has PR (in ). Marking P-medium and removing nomination.

Discussion:
"crypto-hash", "curl", "curl-sys", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "failure", "filetime", "flate2",

version = "0.0.0" dependencies = [ "diff", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "getopts", "lazy_static 1.3.0", "libc",

[[package]] name = "env_logger" <del> version = "0.7.0" </del> <ins> version = "0.7.1" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "39ecdb7dd54465526f0a56d666e3b2dd5f3a218665a030b6e4ad9e70fa95d8fa" </del> <ins> checksum = "44533bbbb3bb3c1fa17d9f2e4e38bbbaf8396ba82193c4cb1b6445d711445d36" </ins> dependencies = [ "atty", "humantime",

version = "0.1.0" dependencies = [ "byteorder", <del> "cargo_metadata 0.8.0", </del> <ins> "cargo_metadata 0.9.0", </ins> "colored", "compiletest_rs", "directories", <del> "env_logger 0.6.2", </del> <ins> "env_logger 0.7.1", </ins> "getrandom", <del> "hex 0.3.2", </del> <ins> "hex 0.4.0", </ins> "log", "num-traits", "rand 0.7.0",

"clippy_lints", "crossbeam-channel", "difference", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "failure", "futures", "heck",

version = "0.6.0" dependencies = [ "clippy_lints", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "failure", "futures", "log",

name = "rustc_driver" version = "0.0.0" dependencies = [ <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "graphviz", "lazy_static 1.3.0", "log",

<del> Subproject commit d9ae0285169e52050416fb3618f05b5fdf582b6b </del> <ins> Subproject commit d4e4fe71e6a9568f5d081d99f1c621c5a4ddd7db </ins>
Change:
I posted on stackoverflow. What happens is that when using retain over a vector, it seems to be a lot slower in version 1.38.0. host is: x86_64-unknown-linux-gpu (according to rustc--version --verbose) and LLVM version is 8.0. I'm using ubuntu 19.04. As I wrote on SO, I tried: And changed between versions with and , having updated rust before with . p.s.: From my complete program I also noticed that version 1.38.0 was still a little bit slower without using retain(). But the difference was minimal (~5%) and hard to come up with another culprit.
Performance of this code in 1.37 is similar to that in 1.36, so this would appear to be a regression in 1.38. Rust 1.37.0: 2.8 seconds Rust 1.38.0: 5.7 seconds
Minimal example:
Could you check against nightly compiler?
In the nightly version it takes about the same time as in stable.
stable is Rust 1.38.0?
yes, stable is 1.38.0.
Will this ever be fixed or looked at? I understand that the devs may have too much work and too little help, I wish I had the knowledge to help, just sincerely asking.
I bet it's fallout from upgrade to LLVM 9 but bisecting it would greatly help (either manually or with ).

Discussion:
pub fn retain<F>(&mut self, mut f: F) where F: FnMut(&T) -> bool { <del> self.drain_filter(|x| !f(x)); </del> <ins> let len = self.len(); let mut del = 0; { let v = &mut **self; for i in 0..len { if !f(&v[i]) { del += 1; } else if del > 0 { v.swap(i - del, i); } } } if del > 0 { self.truncate(len - del); } </ins> } /// Removes all but the first of consecutive elements in the vector that resolve to the same
Change:
I have a fresh Rust library, started with , and I have the following in : edition2018 /// assert_eq!(1 + 1, 999) /// I can and this library. The doctest is obviously never run because is false. The output from confirms this, showing that zero test were run. lead me to believe the doctest should still work, even if marked as . is:
That's really strange! It works on nightly! I think it is due to this code: Was this maybe forgotten to be stabilized when editions were stabilized?
This still happens with Rust . I created a minimal project that demonstrates this bug at .
I posted PR to fix this.

Discussion:
seen_rust_tags = !seen_other_tags || seen_rust_tags; data.no_run = true; } <del> x if allow_error_code_check && x.starts_with("edition") => { // allow_error_code_check is true if we're on nightly, which // is needed for edition support </del> <ins> x if x.starts_with("edition") => { </ins> data.edition = x[7..].parse::<Edition>().ok(); } x if allow_error_code_check && x.starts_with("E") && x.len() == 5 => {

<del> // compile-flags:--test -Z unstable-options </del> <ins> // compile-flags:--test </ins> // edition:2018 /// ```rust
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.
Miri fix:
triage: P-medium. Removing nomination label.

Discussion:
<del> Subproject commit d4e4fe71e6a9568f5d081d99f1c621c5a4ddd7db </del> <ins> Subproject commit 8355437d5d0e747b7e7239cd0a2af8a3825bd912 </ins>
Change:
Case sensitivity is a property of the filesystem, not operating system and these functions are filesystem agnostic. As thus, this issue is not actionable. Closing. If you feel differently please complain and I’ll reopen.
It's fine if the functions want to be case-sensitive, but their docs need to be changed to point this out explicitly and noticeably. Every Windows user is going to assume that the functions are case-insensitive just like they are in other languages on the platform. (I imagine OSX users will have the same expectation?) It's made slightly worse because is handled in a special way that makes evaluate to despite the mismatched case. So someone using that as a quick test of their assumption would end up with the wrong idea. Would you mind reopening for this reason?
I think it would also be good to have a crate like provide a that does hit the filesystem. Such an API would also be able to detect when the same folder is specified but using alternate prefixes or mount points or through symbolic links.
The driver letter is a symlink in the Object Manager and lookup is always case-insensitive. Folders are located on the filesystem and may or may not be case sensitive. I do think platform specific behaviour should be documented if it can be a source of confusion.

Discussion:
//! [`PathBuf`]; note that the paths may differ syntactically by the //! normalization described in the documentation for the [`components`] method. //! <ins> //! ## Case sensitivity //! //! Unless otherwise indicated path methods that do not access the filesystem, //! such as [`Path::starts_with`] and [`Path::ends_with`], are case sensitive no //! matter the platform or filesystem. An exception to this is made for Windows //! drive letters. //! </ins> //! ## Simple usage //! //! Path manipulation includes both parsing components from slices and building
Change:
Attempt to use destructuring on incorrectly defined struct produces ICE. Code: Output:
There's no need for , and there's also no need to use a non-existing field (maybe you implied that with "any field"). The following also ICEs: <details<summaryrustc 1.40.0-nightly ( 2019-11-09) running on x86_64-unknown-linux-gnu backtrace</summary</details
thank you for corrections! I wanted to show that correct nested destructuring produces ICE Field doesn't exist too because it has incorrect definition Try following code (): <details<summarySpoiler</summary<p</p</detailsExactly, it has name because of that
cc since you are working on cc
This is fixed by . I'll add a test for this tomorrow.
did the test get ? Looks to me that got lost to the ether
Oh. I guess not then.

Discussion:
let span = self.tcx.def_span(generator_did); // Do not ICE on closure typeck (#66868). <del> if let None = self.tcx.hir().as_local_hir_id(generator_did) { </del> <ins> if self.tcx.hir().as_local_hir_id(generator_did).is_none() { </ins> return false; }

<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct Const<const N: usize>; impl<const C: usize> Const<{C}> { fn successor() -> Const<{C + 1}> { Const } } fn main() { let _x: Const::<2> = Const::<1>::successor(); } </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61747.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

<ins> // check-pass #![allow(incomplete_features, dead_code, unconditional_recursion)] #![feature(const_generics)] fn fact<const N: usize>() { fact::<{ N - 1 }>(); } fn main() {} </ins>

<ins> // Fixed by #67160 trait Trait1 { type A; } trait Trait2 { type Type1<B>: Trait1<A=B>; //~^ ERROR: generic associated types are unstable //~| ERROR: type-generic associated types are not yet implemented } fn main() {} </ins>

<ins> error[E0658]: generic associated types are unstable --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable error: type-generic associated types are not yet implemented --> $DIR/issue-67424.rs:8:5 | LL |     type Type1<B>: Trait1<A=B>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: for more information, see https://github.com/rust-lang/rust/issues/44265 error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

<ins> // Regression test for #66270, fixed by #66246 struct Bug { incorrect_field: 0, //~^ ERROR expected type } struct Empty {} fn main() { let Bug { any_field: Empty {}, } = Bug {}; } </ins>

<ins> error: expected type, found `0` --> $DIR/issue-66270-pat-struct-parser-recovery.rs:4:22 | LL |     incorrect_field: 0, |                      ^ expected type error: aborting due to previous error </ins>
Change:
The following rust code crashes . (Note, changing to fixes the crash.) Running with RUSTBACKTRACE, I get the following error message. yields Thank you.
I reduced the proc macro to the following: with tokens being:
panic due to not found inside snippet while trying to suggest to . cc
triage: P-high. Removing I-nominated.

Discussion:
if let Ok(snippet) = self.sess.source_map().span_to_snippet(data.span) { // Do not suggest going from `Trait()` to `Trait<>` if data.inputs.len() > 0 { <del> let split = snippet.find('(').unwrap(); let trait_name = &snippet[0..split]; let args = &snippet[split + 1 .. snippet.len() - 1]; err.span_suggestion( data.span, "use angle brackets instead", format!("{}<{}>", trait_name, args), Applicability::MaybeIncorrect, ); </del> <ins> if let Some(split) = snippet.find('(') { let trait_name = &snippet[0..split]; let args = &snippet[split + 1 .. snippet.len() - 1]; err.span_suggestion( data.span, "use angle brackets instead", format!("{}<{}>", trait_name, args), Applicability::MaybeIncorrect, ); } </ins> } }; err.emit();
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.

Discussion:
<del> Subproject commit 3abdd2f1ced4cf3a44c7de88c5e39b3bb5037c4d </del> <ins> Subproject commit 86b8643586aa39f36fb7a02e98c8d64d31415e70 </ins>