jiebi/CodeConvo huggingface dataset:
Code change:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

Related discussion:
text: <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. fn main() { let thing = (); let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant //~^ ERROR `typeof` is a reserved keyword but unimplemented [E0516] } fn f(){ let q = 1; <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant //~^ ERROR `typeof` is a reserved keyword but unimplemented [E0516] } </ins>
Code change:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

Related discussion:
text: <ins> error[E0435]: attempt to use a non-constant value in a constant --> $DIR/issue-42060.rs:13:23 | LL |     let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant |                       ^^^^^ non-constant value error[E0435]: attempt to use a non-constant value in a constant --> $DIR/issue-42060.rs:19:13 | LL |     <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant |             ^ non-constant value error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-42060.rs:13:16 | LL |     let other: typeof(thing) = thing; //~ ERROR attempt to use a non-constant value in a constant |                ^^^^^^^^^^^^^ reserved keyword error[E0516]: `typeof` is a reserved keyword but unimplemented --> $DIR/issue-42060.rs:19:6 | LL |     <typeof(q)>::N //~ ERROR attempt to use a non-constant value in a constant |      ^^^^^^^^^ reserved keyword error: aborting due to 4 previous errors Some errors occurred: E0435, E0516. For more information about an error, try `rustc --explain E0435`. </ins>
Code change:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

Related discussion:
text: <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. fn main() { | } //~^ ERROR expected `|`, found `}` | //~^ ERROR expected item, found `|` </ins>
Code change:
Even more minimal test case: The parser for some reason is expecting a pattern by end of the second .
The ICE is fixed in nightly.

Related discussion:
text: <ins> error: expected `|`, found `}` --> $DIR/issue-43196.rs:13:1 | LL |     | |      - expected `|` here LL | } | ^ unexpected token error: expected item, found `|` --> $DIR/issue-43196.rs:15:1 | LL | | | ^ expected item error: aborting due to 2 previous errors </ins>
Code change:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

Related discussion:
text: use tvec; use value::Value; <del> use super::MirContext; </del> <ins> use super::{MirContext, LocalRef}; </ins> use super::constant::const_scalar_checked_binop; use super::operand::{OperandRef, OperandValue}; use super::lvalue::LvalueRef;
Code change:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

Related discussion:
text: } mir::Rvalue::Len(ref lvalue) => { <del> let tr_lvalue = self.trans_lvalue(&bcx, lvalue); </del> <ins> let size = self.evaluate_array_len(&bcx, lvalue); </ins> let operand = OperandRef { <del> val: OperandValue::Immediate(tr_lvalue.len(bcx.ccx)), </del> <ins> val: OperandValue::Immediate(size), </ins> ty: bcx.tcx().types.usize, }; (bcx, operand)
Code change:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

Related discussion:
text: } } <ins> fn evaluate_array_len(&mut self, bcx: &Builder<'a, 'tcx>, lvalue: &mir::Lvalue<'tcx>) -> ValueRef { // ZST are passed as operands and require special handling // because trans_lvalue() panics if Local is operand. if let mir::Lvalue::Local(index) = *lvalue { if let LocalRef::Operand(Some(op)) = self.locals[index] { if common::type_is_zero_size(bcx.ccx, op.ty) { if let ty::TyArray(_, n) = op.ty.sty { return common::C_uint(bcx.ccx, n); } } } } // use common size calculation for non zero-sized types let tr_value = self.trans_lvalue(&bcx, lvalue); return tr_value.len(bcx.ccx); } </ins> pub fn trans_scalar_binop(&mut self, bcx: &Builder<'a, 'tcx>, op: mir::BinOp,
Code change:
This code: gives this ICE: Doesn't happen if you use e.g. instead of , or use instead of .
Minimized to:
Fixed in .

Related discussion:
text: <ins> // Copyright 2016 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. fn main() { &&[()][0]; println!("{:?}", &[(),()][1]); } </ins>
Code change:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

Related discussion:
text: <ins> pub trait Trait<'a> { type Assoc; } pub struct Type; impl<'a> Trait<'a> for Type { type Assoc = (); } pub fn break_me<T, F>(f: F) where T: for<'b> Trait<'b>, F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { break_me::<Type, fn(_)>; //~^ ERROR: type mismatch in function arguments //~| ERROR: type mismatch resolving } fn main() {} </ins>
Code change:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

Related discussion:
text: <ins> error[E0631]: type mismatch in function arguments --> $DIR/issue-43623.rs:14:5 | LL |     break_me::<Type, fn(_)>; |     ^^^^^^^^^^^^^^^^^^^^^^^ |     | |     expected signature of `for<'b> fn(<Type as Trait<'b>>::Assoc) -> _` |     found signature of `fn(_) -> _` | note: required by `break_me` --> $DIR/issue-43623.rs:11:1 | LL | / pub fn break_me<T, F>(f: F) LL | | where T: for<'b> Trait<'b>, LL | |       F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { LL | |     break_me::<Type, fn(_)>; LL | | LL | | LL | | } | |_^ error[E0271]: type mismatch resolving `for<'b> <fn(_) as std::ops::FnOnce<(<Type as Trait<'b>>::Assoc,)>>::Output == ()` --> $DIR/issue-43623.rs:14:5 | LL |     break_me::<Type, fn(_)>; |     ^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter 'b, found concrete lifetime | note: required by `break_me` --> $DIR/issue-43623.rs:11:1 | LL | / pub fn break_me<T, F>(f: F) LL | | where T: for<'b> Trait<'b>, LL | |       F: for<'b> FnMut(<T as Trait<'b>>::Assoc) { LL | |     break_me::<Type, fn(_)>; LL | | LL | | LL | | } | |_^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0271`. </ins>
Code change:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

Related discussion:
text: <ins> use std::ops::Index; struct Test; struct Container(Test); impl Test { fn test(&mut self) {} } impl<'a> Index<&'a bool> for Container { type Output = Test; fn index(&self, _index: &'a bool) -> &Test { &self.0 } } fn main() { let container = Container(Test); let mut val = true; container[&mut val].test(); //~ ERROR: cannot borrow data } </ins>
Code change:
The compiler ices with error "Failed to unify obligation" when I try to compile the following code: I get the following error: : Backtrace:
Another version:
triage: p-medium
minimal version Note that if you pass in the closure to it doesn't ICE the compiler when I used , bud did ICE the compiler when I used /. i.e.
none of the programs provided seem to ICE with the latest nightly.

Related discussion:
text: <ins> error[E0596]: cannot borrow data in an index of `Container` as mutable --> $DIR/issue-44405.rs:21:5 | LL |     container[&mut val].test(); |     ^^^^^^^^^^^^^^^^^^^ cannot borrow as mutable | = help: trait `IndexMut` is required to modify indexed content, but it is not implemented for `Container` error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>
Code change:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

Related discussion:
text: // Building with a static libstdc++ is only supported on linux right now, // not for MSVC or macOS if build.config.llvm_static_stdcpp && <ins> !target.contains("freebsd") && </ins> !target.contains("windows") && !target.contains("apple") { cargo.env("LLVM_STATIC_STDCPP",
Code change:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

Related discussion:
text: libssl-dev  pkg-config <del> COPY dist-i686-freebsd/build-toolchain.sh /tmp/ RUN /tmp/build-toolchain.sh i686 </del> <ins> COPY scripts/freebsd-toolchain.sh /tmp/ RUN /tmp/freebsd-toolchain.sh i686 </ins> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV  AR_i686_unknown_freebsd=i686-unknown-freebsd10-ar  <del> CC_i686_unknown_freebsd=i686-unknown-freebsd10-gcc  CXX_i686_unknown_freebsd=i686-unknown-freebsd10-g++ </del> <ins> CC_i686_unknown_freebsd=i686-unknown-freebsd10-clang  CXX_i686_unknown_freebsd=i686-unknown-freebsd10-clang++ </ins> ENV HOSTS=i686-unknown-freebsd
Code change:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

Related discussion:
text: FROM ubuntu:16.04 RUN apt-get update && apt-get install -y --no-install-recommends  <del> g++  </del> <ins> clang  </ins> make  file  curl
Code change:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

Related discussion:
text: libssl-dev  pkg-config <del> COPY dist-x86_64-freebsd/build-toolchain.sh /tmp/ RUN /tmp/build-toolchain.sh x86_64 </del> <ins> COPY scripts/freebsd-toolchain.sh /tmp/ RUN /tmp/freebsd-toolchain.sh x86_64 </ins> COPY scripts/sccache.sh /scripts/ RUN sh /scripts/sccache.sh ENV  AR_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-ar  <del> CC_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-gcc  CXX_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-g++ </del> <ins> CC_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-clang  CXX_x86_64_unknown_freebsd=x86_64-unknown-freebsd10-clang++ </ins> ENV HOSTS=x86_64-unknown-freebsd
Code change:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…

Related discussion:
text: let stdcppname = if target.contains("openbsd") { // llvm-config on OpenBSD doesn't mention stdlib=libc++ "c++" <ins> } else if target.contains("freebsd") { "c++" </ins> } else if target.contains("netbsd") && llvm_static_stdcpp.is_some() { // NetBSD uses a separate library when relocation is required "stdc++_pic"
Code change:
"Cousins" of borrowed union sub-fields (and their further children) are not marked as borrowed.
This is , though I sort of thought we had tried to fix this.
I'm tagging this as WG-compiler-nll; I think it's something we should fix there.
For the sake of potential testsuite additions: this also should not compile with a simultaneous borrow of and .
I'll take a look at this one.
I'm not really sure what the bug is here, but I can explain what I think should be happening. This function: is responsible for determining when two values overlap. I expect us to say that two fields from a union are always considered to potentially overlap. In this case, and would be considered to overlap. Specifically, comparing those two fields would return : This is the code that I think should be responsible for doing that: It already looks a little fishy to me; in particular, it is returning if is a union, but I guess it should be equally true if is a union. Anyway, something here seems to be going awry!
So it seems like I forgot about how smart the compiler is now. This version of the test does error, as expected:
I think the policy is that we will keep this bug open, but file it under
(Since it is only fixed when NLL is enabled)
should this be ?
Note that to get an NLL test failure, you have to use after declaring :
NLL (migrate mode) is enabled in all editions as of PR . The only policy question is that, under migrate mode, we only emit a warning on this (unsound) test case. Therefore, I am not 100% sure whether we should close this until that warning has been turned into a hard-error under our (still in development) future-compatibility lint policy.

Related discussion:
text: <ins> // Copyright 2017 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. #![allow(unused)] #![feature(nll)] #[derive(Clone, Copy, Default)] struct S { a: u8, b: u8, } #[derive(Clone, Copy, Default)] struct Z { c: u8, d: u8, } union U { s: S, z: Z, } fn main() { unsafe { let mut u = U { s: Default::default() }; let mref = &mut u.s.a; *mref = 22; let nref = &u.z.c; //~^ ERROR cannot borrow `u.z.c` as immutable because it is also borrowed as mutable [E0502] println!("{} {}", mref, nref) //~^ ERROR cannot borrow `u.s.a` as mutable because it is also borrowed as immutable [E0502] } } </ins>