jiebi/CodeConvo huggingface dataset:
Change:
Currently the build times for Azure Pipelines are through the roof compared to Travis, taking up to an hour longer on relevant builds. The has . We're going to have to rework quite a lot I think to get the current 2-core within our time limits. We're shooting to have everything in 2h on a good day, and up to 3h if necessary to do things like rebuild caches and such.
Ok to expand on the comment linked above, I've run azure again but this time with step timings enabled for the no assertions build, yielding this chart: Here are some comparisons of build times between Travis/Appveyor to Azure. A sign means azure is slower for a step, and a means azure is faster. <details<summaryBuild time discrepancies of dist-i686-msvc:</summary</details<details<summaryBuild time discrepancies of dist-x8664-apple</summary</details<details<summaryBuild time discrepancies of dist-x8664-linux-alt</summary</detailsFrom this all I can really see is that everything is just blanket slower on Azure, namely compiling rustc. That makes sense since compiling rustc is quite parallel already. It also doesn't look like azure is doing anything Travis/AppVeyor isn't by accident, and furthermore they're configured the same. All-in-all I don't really see a great win for us to cash in on here.
Your "chart" has a Python backtrace at the end of the table. Two stupid questions: are LLVM assertions enabled on Travis and AppVeyor? do the Travis and Azure VMs have the same number of cores?
Digging further into the build logs of MSVC it looks like we're building really big crates like Cargo and rustc-ap-syntax twice. That'll save 10-ish minutes of build time so I'm going to investigate why that's coming up and how to prevent it. it depends on the builder for whether assertions are enabled or not. There is a different number of cores between the services, where we're using 4 on Travis/AppVeyor and only 2 on Azure.
We've since switched to azure, so I don't think this issue is serving much any more, so I'm going to close.

Discussion:
src/libstd  src/liballoc  src/libcore <ins> # Debug assertions in rustc are largely covered by other builders, and LLVM # assertions cause this builder to slow down by quite a large amount and don't # buy us a huge amount over other builders (not sure if we've ever seen an # asmjs-specific backend assertion trip), so disable assertions for these # tests. ENV NO_LLVM_ASSERTIONS=1 ENV NO_DEBUG_ASSERTIONS=1 </ins>
Change:
Currently the build times for Azure Pipelines are through the roof compared to Travis, taking up to an hour longer on relevant builds. The has . We're going to have to rework quite a lot I think to get the current 2-core within our time limits. We're shooting to have everything in 2h on a good day, and up to 3h if necessary to do things like rebuild caches and such.
Ok to expand on the comment linked above, I've run azure again but this time with step timings enabled for the no assertions build, yielding this chart: Here are some comparisons of build times between Travis/Appveyor to Azure. A sign means azure is slower for a step, and a means azure is faster. <details<summaryBuild time discrepancies of dist-i686-msvc:</summary</details<details<summaryBuild time discrepancies of dist-x8664-apple</summary</details<details<summaryBuild time discrepancies of dist-x8664-linux-alt</summary</detailsFrom this all I can really see is that everything is just blanket slower on Azure, namely compiling rustc. That makes sense since compiling rustc is quite parallel already. It also doesn't look like azure is doing anything Travis/AppVeyor isn't by accident, and furthermore they're configured the same. All-in-all I don't really see a great win for us to cash in on here.
Your "chart" has a Python backtrace at the end of the table. Two stupid questions: are LLVM assertions enabled on Travis and AppVeyor? do the Travis and Azure VMs have the same number of cores?
Digging further into the build logs of MSVC it looks like we're building really big crates like Cargo and rustc-ap-syntax twice. That'll save 10-ish minutes of build time so I'm going to investigate why that's coming up and how to prevent it. it depends on the builder for whether assertions are enabled or not. There is a different number of cores between the services, where we're using 4 on Travis/AppVeyor and only 2 on Azure.
We've since switched to azure, so I don't think this issue is serving much any more, so I'm going to close.

Discussion:
ENV RUST_CONFIGURE_ARGS --build=x86_64-unknown-linux-gnu --set rust.ignore-git=false ENV SCRIPT python2.7 ../x.py test distcheck ENV DIST_SRC 1 <ins> # The purpose of this builder is to test that we can `./x.py test` successfully # from a tarball, not to test LLVM/rustc's own set of assertions. These cause a # significant hit to CI compile time (over a half hour as observed in #61185), # so disable assertions for this builder. ENV NO_LLVM_ASSERTIONS=1 ENV NO_DEBUG_ASSERTIONS=1 </ins>
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 prioritization.
I just tried to update my rustc nightly, it breaks and says component is not available: Could the issue be also related to this one?
yes, very much related. I had a fix yesterday, but it didn't get through in time for todays nightly. Try again tomorrow

Discussion:
<del> Subproject commit 46e64911ad43c519c61d22afef7f82625dd9c4a8 </del> <ins> Subproject commit fb33fad08e8f08c032b443bab0df299ce22fe61b </ins>
Change:
I got this stacktrace while running "rust test" on a file. The end of the trace contains a failure message. I have an archlinux 64bits, with rust-0.6-3 (compiled on april 6th, 2013). The code is at the bottom of the page. code:
It seems you are using an old version of rust (based on your use of LinearMap, which has since been renamed to HashMap). Does this crash also happen on incoming?
Looks like my computer is not powerful enough to build rust from ...
I tested with master () And I get the same problem
Simpler test case: Reproduced with . Nominating for milestone 5, production-ready.
accepted for production-ready milestone
I don't get ICE anymore.
Hurrah! flagging as needstest, but this probably just needs the test case un-xfail'd
The test was actually already checked in and was un-xfail'd in

Discussion:
<ins> // Copyright 2013 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. // xfail-test use std::hashmap::HashMap; trait Graph<Node, Edge> { fn f(&self, Edge); } impl<E> Graph<int, E> for HashMap<int, int> { fn f(&self, _e: E) { fail!(); } } fn main() { let g : ~HashMap<int, int> = ~HashMap::new(); let _g2 : ~Graph<int,int> = g as ~Graph<int,int>; } </ins>
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 prioritization.
I'm going to guess that is to blame; cc
The fix is mostly to replace by . But really RLS shouldn't be using such implementation details...
The logs look like the failure is in clippy, not RLS? I am confused. (Great logs as usual, thanks Travis.)
breaking breaks RLS, AFAIK.
will fix it, only needs ci to pass.

Discussion:
<del> Subproject commit fb33fad08e8f08c032b443bab0df299ce22fe61b </del> <ins> Subproject commit d2f51228152a139a2a8aaba59b8a4e68f498ff26 </ins>
Change:
A clean project with this code: Produces this error:
cc (const generics) (qualification)
I think this is possibly down to not being implemented.
cc You may want to consider this as part of the work on .
Same as , the compiler still crashes with brackets:
I don't understand, how was this fixed without running into ? Special-casing a const generic param as an array length expression? Then why do I still see the array length expression that depends on a const generic param in , causing the telltale signs of , via ICE?
I think that a full fix for this would involve adding to this (i.e. the fix for ) but only if the workaround applies (because in that case, the cyclic issues of shouldn't trigger)

Discussion:
/// Returns the `DefId` of the constant parameter that the provided expression is a path to. pub fn const_param_def_id(&self, expr: &hir::Expr) -> Option<DefId> { <ins> // Unwrap a block, so that e.g. `{ P }` is recognised as a parameter. Const arguments // currently have to be wrapped in curly brackets, so it's necessary to special-case. let expr = match &expr.node { ExprKind::Block(block, _) if block.stmts.is_empty() && block.expr.is_some() => block.expr.as_ref().unwrap(), _ => expr, }; </ins> match &expr.node { ExprKind::Path(hir::QPath::Resolved(_, path)) => match path.res { Res::Def(DefKind::ConstParam, did) => Some(did),

ty, }; <del> let mut expr = &tcx.hir().body(ast_const.body).value; // Unwrap a block, so that e.g. `{ P }` is recognised as a parameter. Const arguments // currently have to be wrapped in curly brackets, so it's necessary to special-case. if let ExprKind::Block(block, _) = &expr.node { if block.stmts.is_empty() { if let Some(trailing) = &block.expr { expr = &trailing; } } } </del> <ins> let expr = &tcx.hir().body(ast_const.body).value; </ins> if let Some(def_id) = self.const_param_def_id(expr) { // Find the name and index of the const parameter by indexing the generics of the // parent item and construct a `ParamConst`.

<ins> #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn f<T: Copy, const N: usize>(x: T) -> [T; N] { [x; {N}] } fn g<T, const N: usize>(x: T) -> [T; N] { [x; {N}] //~^ ERROR the trait bound `T: std::marker::Copy` is not satisfied [E0277] } fn main() { let x: [u32; 5] = f::<u32, 5>(3); assert_eq!(x, [3u32; 5]); } </ins>

<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-61336-2.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ error[E0277]: the trait bound `T: std::marker::Copy` is not satisfied --> $DIR/issue-61336-2.rs:9:5 | LL |     [x; {N}] |     ^^^^^^^^ the trait `std::marker::Copy` is not implemented for `T` | = help: consider adding a `where T: std::marker::Copy` bound = note: the `Copy` trait is required because the repeated element will be copied error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Change:
On OpenBSD, the function fails if the binary is not invoked with a full path (see ). This leads to the following crash when running doc tests: Note that this using rustc/cargo 1.33.0, installed on OpenBSD 6.5 using its native package (). The offending code, I believe, must be one of the calls in , which are both unwrapped, and have to do with figuring out the sysroot, if not already known. The issue can be worked around by adjusting the command line like this: I guess solving this completely may be tricky, but I think the code should definitely not panic, and ideally cargo/rustdoc would issue an error message pointing (OpenBSD) users to the workaround.
It seems that simply using the code of from would be an improvement over using directly; the latter is patched on OpenBSD to consider the environment variable; see .

Discussion:
let input = config::Input::File(options.input.clone()); let sessopts = config::Options { <del> maybe_sysroot: options.maybe_sysroot.clone().or_else( || Some(env::current_exe().unwrap().parent().unwrap().parent().unwrap().to_path_buf())), </del> <ins> maybe_sysroot: options.maybe_sysroot.clone(), </ins> search_paths: options.libs.clone(), crate_types: vec![config::CrateType::Dylib], cg: options.codegen_options.clone(),

let outputs = OutputTypes::new(&[(OutputType::Exe, None)]); let sessopts = config::Options { <del> maybe_sysroot: maybe_sysroot.or_else( || Some(env::current_exe().unwrap().parent().unwrap().parent().unwrap().to_path_buf())), </del> <ins> maybe_sysroot, </ins> search_paths: libs, crate_types: vec![config::CrateType::Executable], output_types: outputs,
Change:
Given the following source code in both and , I encounter an internal compiler error using nalgebra 0.18.0. The code is probably not legal to begin with as I ran into it as I was moving from my own homebrewn math code to nalgebra. I have the impression that the compiler probably shouldn't ICE regardless of what junk you feed it, so I'm still reporting this. Build output from : I unfortunately do not have a newer nightly to test with due to the lack of a more recent RLS blocking the rustup attempt.
Still encountering this in . Indepent of the issue, you can install specific compiler versions with necessary components and .
This ICE itself arises from this line:
triage: P-high, assigning to self. Removing nomination.
Okay I've narrowed the test case down <details<summaryclick for first reduction</summaryHere is a standalone file (): </detailsUpdate: Got a better reduction now ():
This is a stable-to-stable regression, injected between rust 1.23 and 1.24.
the fact that the bug goes away if you take away the on leads me to hypothesize that the bug is caused by some internal layout code for checking the validity (or just computing the effects) of that use of )
(Also, bisection on my mac has shown this was injected by PR )

Discussion:
let field_ty = self.tcx.type_of(self.tcx.hir().local_def_id_from_hir_id(field.hir_id)); let field_ty = self.normalize_associated_types_in(field.span, &field_ty); <ins> let field_ty = self.resolve_vars_if_possible(&field_ty); debug!("non_enum_variant: type of field {:?} is {:?}", field, field_ty); </ins> AdtField { ty: field_ty, span: field.span } }) .collect();

<ins> // If a struct is packed and its last field has drop glue, then that // field needs to be Sized (to allow it to be destroyed out-of-place). // // This is checked by the compiler during wfcheck. That check used // to have problems with associated types in the last field - test // that this doesn't ICE. #![allow(unused_imports, dead_code)] pub struct S; pub trait Trait<R> { type Assoc; } impl<X> Trait<X> for S { type Assoc = X; } #[repr(C, packed)] struct PackedAssocSized { pos: Box<<S as Trait<usize>>::Assoc>, } fn main() { println!("Hello, world!"); } </ins>
Change:
The following code ICEs when compiled with a rustc with debug-assertions enabled: The problem is in the implementation of , specifically in this line: The subtraction overflows here. Cc
Fix should be:
Ya I'll take this on :+1:
awesome! above already pretty much gave the mentoring instructions, except for one thing: please also add a test case. Or rather, please extend the existing test case at . Let me know if you need any more assistance.
looks like you are both on this now? Not sure how that happened...

Discussion:
let raw_shift_bits = self.read_scalar(args[1])?.to_bits(layout.size)?; let width_bits = layout.size.bits() as u128; let shift_bits = raw_shift_bits % width_bits; <del> let inv_shift_bits = (width_bits - raw_shift_bits) % width_bits; </del> <ins> let inv_shift_bits = (width_bits - shift_bits) % width_bits; </ins> let result_bits = if intrinsic_name == "rotate_left" { (val_bits << shift_bits) | (val_bits >> inv_shift_bits) } else {

const LEFT: u32 = 0x10000b3u32.rotate_left(8); const RIGHT: u32 = 0xb301u32.rotate_right(8); <ins> // Rotating these should make no difference // // We test using 124 bits because to ensure that overlong bit shifts do // not cause undefined behaviour. See #10183. const LEFT_OVERFLOW: i16 = 0i16.rotate_left(124); const RIGHT_OVERFLOW: i16 = 0i16.rotate_right(124); const ONE_LEFT_OVERFLOW: u16 = 1u16.rotate_left(124); const ONE_RIGHT_OVERFLOW: u16 = 1u16.rotate_right(124); const NON_ZERO_LEFT_OVERFLOW: u16 = 0b10u16.rotate_left(124); const NON_ZERO_RIGHT_OVERFLOW: u16 = 0b10u16.rotate_right(124); // Rotating by 0 should have no effect const ZERO_ROTATE_LEFT: i8 = 0b0010_0001i8.rotate_left(0); const ZERO_ROTATE_RIGHT: i8 = 0b0111_1001i8.rotate_right(0); // Rotating by a multiple of word size should also have no effect const MULTIPLE_ROTATE_LEFT: i32 = 0b0010_0001i32.rotate_left(128); const MULTIPLE_ROTATE_RIGHT: i32 = 0b0010_0001i32.rotate_right(128); </ins> fn ident<T>(ident: T) -> T { ident } fn main() { assert_eq!(LEFT, ident(0xb301)); <del> assert_eq!(RIGHT, ident(0x10000b3)); </del> <ins> assert_eq!(RIGHT, ident(0x0100_00b3)); assert_eq!(LEFT_OVERFLOW, ident(0)); assert_eq!(RIGHT_OVERFLOW, ident(0)); assert_eq!(ONE_LEFT_OVERFLOW, ident(0b0001_0000_0000_0000)); assert_eq!(ONE_RIGHT_OVERFLOW, ident(0b0001_0000)); assert_eq!(NON_ZERO_LEFT_OVERFLOW, ident(0b0010_0000_0000_0000)); assert_eq!(NON_ZERO_RIGHT_OVERFLOW, ident(0b0000_0000_0010_0000)); assert_eq!(ZERO_ROTATE_LEFT, ident(0b0010_0001)); assert_eq!(ZERO_ROTATE_RIGHT, ident(0b0111_1001)); assert_eq!(MULTIPLE_ROTATE_LEFT, ident(0b0010_0001)); assert_eq!(MULTIPLE_ROTATE_RIGHT, ident(0b0010_0001)); </ins> }
Change:
ICE when some lints fail on an async-fn. Make the xs mutable and no ICE. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels: A-async-await C-bug I-ICE
Discussed in async-await meeting. Marking as blocking as this looks pretty bad for the user experience. Hopefully an easy fix. Presumably in the desugared form we are somehow failing because the keyword is missing or something like that.
claim

Discussion:
<ins> // edition:2018 #![feature(async_await)] pub async fn f(x: Option<usize>) { x.take(); //~^ ERROR cannot borrow `x` as mutable, as it is not declared as mutable [E0596] } pub async fn g(x: usize) { x += 1; //~^ ERROR cannot assign twice to immutable variable `x` [E0384] } fn main() {} </ins>

<ins> error[E0596]: cannot borrow `x` as mutable, as it is not declared as mutable --> $DIR/issue-61452.rs:5:5 | LL | pub async fn f(x: Option<usize>) { |                - help: consider changing this to be mutable: `mut x` LL |     x.take(); |     ^ cannot borrow as mutable error[E0384]: cannot assign twice to immutable variable `x` --> $DIR/issue-61452.rs:10:5 | LL | pub async fn g(x: usize) { |                - |                | |                first assignment to `x` |                help: make this binding mutable: `mut x` LL |     x += 1; |     ^^^^^^ cannot assign twice to immutable variable error: aborting due to 2 previous errors Some errors have detailed explanations: E0384, E0596. For more information about an error, try `rustc --explain E0384`. </ins>
Change:
root: yup-oauth2 - 360 detected crates which regressed due to this; cc <details</details
I think this might have been caused by
I can confirm that is the cause. Patch coming shortly.

Discussion:
} _ => { Err(if self.prev_token_kind == PrevTokenKind::DocComment { <del> self.span_fatal_err(self.prev_span, Error::UselessDocComment) } else { self.expected_ident_found() }) </del> <ins> self.span_fatal_err(self.prev_span, Error::UselessDocComment) } else { self.expected_ident_found() }) </ins> } } }

path = self.parse_path(PathStyle::Type)?; path_span = path_lo.to(self.prev_span); } else { <del> path = ast::Path { segments: Vec::new(), span: DUMMY_SP }; </del> path_span = self.span.to(self.span); <ins> path = ast::Path { segments: Vec::new(), span: path_span }; </ins> } // See doc comment for `unmatched_angle_bracket_count`.

// want to keep their span info to improve diagnostics in these cases in a later stage. (true, Some(AssocOp::Multiply)) | // `{ 42 } *foo = bar;` or `{ 42 } * 3` (true, Some(AssocOp::Subtract)) | // `{ 42 } -5` <del> (true, Some(AssocOp::Add)) => { // `{ 42 } + 42 </del> <ins> (true, Some(AssocOp::LAnd)) | // `{ 42 } &&x` (#61475) (true, Some(AssocOp::Add)) // `{ 42 } + 42 // If the next token is a keyword, then the tokens above *are* unambiguously incorrect: // `if x { a } else { b } && if y { c } else { d }` if !self.look_ahead(1, |t| t.is_reserved_ident()) => { </ins> // These cases are ambiguous and can't be identified in the parser alone let sp = self.sess.source_map().start_point(self.span); self.sess.ambiguous_block_expr_parse.borrow_mut().insert(sp, lhs.span);

let mut where_clause = WhereClause { id: ast::DUMMY_NODE_ID, predicates: Vec::new(), <del> span: DUMMY_SP, </del> <ins> span: self.prev_span.to(self.prev_span), </ins> }; if !self.eat_keyword(kw::Where) {

<ins> // run-pass #![allow(dead_code)] enum E { A, B } fn main() { match &&E::A { &&E::A => { } &&E::B => { } }; } </ins>
Change:
() Errors:
/cc Related to but different from
This can be avoided by expressly allowing the type to be inferred:
: (as compared to )
After , this isn't fixed, but commenting out the call will cause it to error without ICEing (at the moment, it ICEs even without that line).
I configure struct by complicated const value and get this ICE. My code does something like this: Error: Note that type erase (as proposed does not help in my case. Until I found a way around this ICE.
Same error on:
I tried to port 's from to . Some of code is commented because of this bug and several other. I think this is good test for
Cannot reproduce the ICE with the above playground link.
It should be noted that while this no longer ICEs, this is because rustc no longer attempts to infer the type parameter causing it to fail to compile.

Discussion:
self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }

<ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>

<ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>

<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>

<ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>

<ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>