jiebi/CodeConvo huggingface dataset:
Code change:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

Related discussion:
text: ptr::drop_in_place(&mut self.ptr.as_mut().data); if self.inner().weak.fetch_sub(1, Release) == 1 { <del> atomic::fence(Acquire); </del> <ins> acquire!(self.inner().weak); </ins> Global.dealloc(self.ptr.cast(), Layout::for_value(self.ptr.as_ref())) } }
Code change:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

Related discussion:
text: // // [1]: (www.boost.org/doc/libs/1_55_0/doc/html/atomic/usage_examples.html) // [2]: (https://github.com/rust-lang/rust/pull/41714) <del> atomic::fence(Acquire); </del> <ins> acquire!(self.inner().strong); </ins> unsafe { self.drop_slow();
Code change:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.

Related discussion:
text: let inner = if let Some(inner) = self.inner() { inner } else { return }; if inner.weak.fetch_sub(1, Release) == 1 { <del> atomic::fence(Acquire); </del> <ins> acquire!(inner.weak); </ins> unsafe { Global.dealloc(self.ptr.cast(), Layout::for_value(self.ptr.as_ref())) } } }
Code change:
Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this: Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place. This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. , you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file). The user error here is of course that the needs to be kept in sync with the actual node number to which the mir dump sends its output. But it would be much better if did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.
(I have a patch for this; will post shortly)

Related discussion:
text: use common::{Codegen, DebugInfoLldb, DebugInfoGdb, Rustdoc, CodegenUnits}; use common::{Incremental, RunMake, Ui, MirOpt}; use errors::{self, ErrorKind, Error}; <ins> use filetime::FileTime; </ins> use json; use header::TestProps; use header;
Code change:
Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this: Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place. This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. , you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file). The user error here is of course that the needs to be kept in sync with the actual node number to which the mir dump sends its output. But it would be much better if did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.
(I have a patch for this; will post shortly)

Related discussion:
text: } } <ins> fn check_mir_test_timestamp(&self, test_name: &str, output_file: &Path) { let t = |file| FileTime::from_last_modification_time(&fs::metadata(file).unwrap()); let source_file = &self.testpaths.file; let output_time = t(output_file); let source_time = t(source_file); if source_time > output_time { debug!("source file time: {:?} output file time: {:?}", source_time, output_time); panic!("test source file `{}` is newer than potentially stale output file `{}`.", source_file.display(), test_name); } } </ins> fn compare_mir_test_output(&self, test_name: &str, expected_content: &Vec<&str>) { let mut output_file = PathBuf::new(); output_file.push(self.get_mir_dump_dir()); output_file.push(test_name); debug!("comparing the contests of: {:?}", output_file); debug!("with: {:?}", expected_content); <ins> self.check_mir_test_timestamp(test_name, &output_file); </ins> let mut dumped_file = fs::File::open(output_file.clone()).unwrap(); let mut dumped_string = String::new();
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

Related discussion:
text: { debug!("note_issue_32330: terr={:?}", terr); match *terr { <del> TypeError::RegionsInsufficientlyPolymorphic(_, &Region::ReVar(vid)) | TypeError::RegionsOverlyPolymorphic(_, &Region::ReVar(vid)) => { match self.region_vars.var_origin(vid) { RegionVariableOrigin::EarlyBoundRegion(_, _, Some(Issue32330 { fn_def_id, region_name })) => { diag.note( &format!("lifetime parameter `{0}` declared on fn `{1}`  appears only in the return type,  but here is required to be higher-ranked,  which means that `{0}` must appear in both  argument and return types", region_name, self.tcx.item_path_str(fn_def_id))); diag.note( &format!("this error is the result of a recent bug fix;  for more information, see issue #33685  <https://github.com/rust-lang/rust/issues/33685>")); } _ => { } } </del> <ins> TypeError::RegionsInsufficientlyPolymorphic(_, _, Some(box Issue32330 { fn_def_id, region_name })) | TypeError::RegionsOverlyPolymorphic(_, _, Some(box Issue32330 { fn_def_id, region_name })) => { diag.note( &format!("lifetime parameter `{0}` declared on fn `{1}`  appears only in the return type,  but here is required to be higher-ranked,  which means that `{0}` must appear in both  argument and return types", region_name, self.tcx.item_path_str(fn_def_id))); diag.note( &format!("this error is the result of a recent bug fix;  for more information, see issue #33685  <https://github.com/rust-lang/rust/issues/33685>")); </ins> } <del> _ => { } </del> <ins> _ => {} </ins> } }
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

Related discussion:
text: InferCtxt, LateBoundRegion, HigherRankedType, <ins> RegionVariableOrigin, </ins> SubregionOrigin, SkolemizationMap}; use super::combine::CombineFields;
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

Related discussion:
text: skol_br, tainted_region); <ins> let issue_32330 = if let &ty::ReVar(vid) = tainted_region { match self.region_vars.var_origin(vid) { RegionVariableOrigin::EarlyBoundRegion(_, _, issue_32330) => { issue_32330.map(Box::new) } _ => None } } else { None }; </ins> if overly_polymorphic { debug!("Overly polymorphic!"); return Err(TypeError::RegionsOverlyPolymorphic(skol_br, <del> tainted_region)); </del> <ins> tainted_region, issue_32330)); </ins> } else { debug!("Not as polymorphic!"); return Err(TypeError::RegionsInsufficientlyPolymorphic(skol_br, <del> tainted_region)); </del> <ins> tainted_region, issue_32330)); </ins> } } }
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

Related discussion:
text: RegionsDoesNotOutlive(&'tcx Region, &'tcx Region), RegionsNotSame(&'tcx Region, &'tcx Region), RegionsNoOverlap(&'tcx Region, &'tcx Region), <del> RegionsInsufficientlyPolymorphic(BoundRegion, &'tcx Region), RegionsOverlyPolymorphic(BoundRegion, &'tcx Region), </del> <ins> RegionsInsufficientlyPolymorphic(BoundRegion, &'tcx Region, Option<Box<ty::Issue32330>>), RegionsOverlyPolymorphic(BoundRegion, &'tcx Region, Option<Box<ty::Issue32330>>), </ins> Sorts(ExpectedFound<Ty<'tcx>>), IntMismatch(ExpectedFound<ty::IntVarValue>), FloatMismatch(ExpectedFound<ast::FloatTy>),
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

Related discussion:
text: RegionsNoOverlap(..) => { write!(f, "lifetimes do not intersect") } <del> RegionsInsufficientlyPolymorphic(br, _) => { </del> <ins> RegionsInsufficientlyPolymorphic(br, _, _) => { </ins> write!(f, "expected bound lifetime parameter {},  found concrete lifetime", br) } <del> RegionsOverlyPolymorphic(br, _) => { </del> <ins> RegionsOverlyPolymorphic(br, _, _) => { </ins> write!(f, "expected concrete lifetime,  found bound lifetime parameter {}", br) }
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

Related discussion:
text: self.note_and_explain_region(db, "...does not overlap ", region2, ""); } <del> RegionsInsufficientlyPolymorphic(_, conc_region) => { </del> <ins> RegionsInsufficientlyPolymorphic(_, conc_region, _) => { </ins> self.note_and_explain_region(db, "concrete lifetime that was found is ", conc_region, ""); } <del> RegionsOverlyPolymorphic(_, &ty::ReVar(_)) => { </del> <ins> RegionsOverlyPolymorphic(_, &ty::ReVar(_), _) => { </ins> // don't bother to print out the message below for // inference variables, it's not very illuminating. } <del> RegionsOverlyPolymorphic(_, conc_region) => { </del> <ins> RegionsOverlyPolymorphic(_, conc_region, _) => { </ins> self.note_and_explain_region(db, "expected concrete lifetime is ", conc_region, ""); }
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

Related discussion:
text: RegionsNoOverlap(a, b) => { return tcx.lift(&(a, b)).map(|(a, b)| RegionsNoOverlap(a, b)) } <del> RegionsInsufficientlyPolymorphic(a, b) => { return tcx.lift(&b).map(|b| RegionsInsufficientlyPolymorphic(a, b)) </del> <ins> RegionsInsufficientlyPolymorphic(a, b, ref c) => { let c = c.clone(); return tcx.lift(&b).map(|b| RegionsInsufficientlyPolymorphic(a, b, c)) </ins> } <del> RegionsOverlyPolymorphic(a, b) => { return tcx.lift(&b).map(|b| RegionsOverlyPolymorphic(a, b)) </del> <ins> RegionsOverlyPolymorphic(a, b, ref c) => { let c = c.clone(); return tcx.lift(&b).map(|b| RegionsOverlyPolymorphic(a, b, c)) </ins> } IntMismatch(x) => IntMismatch(x), FloatMismatch(x) => FloatMismatch(x),
Code change:
Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.

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. #![feature(closure_to_fn_coercion)] fn main() { let bar: fn(&mut u32) = |_| {}; //~ ERROR mismatched types //~| expected concrete lifetime, found bound lifetime parameter fn foo(x: Box<Fn(&i32)>) {} let bar = Box::new(|x: &i32| {}) as Box<Fn(_)>; foo(bar); //~ ERROR mismatched types //~| expected concrete lifetime, found bound lifetime parameter } </ins>
Code change:
see I'm happy to help mentor anyone who wants to fix this issue.
Hello, I would like to work on this issue.
I would love to work on this and be mentored as well in case topecongiro can not. Thank you!
got sent in, so maybe we can work together on some other issue? Just let me know, happy to help you help me.
That would be great, thank you so much would love to work with you.
Awesome. Maybe jump on IRC and message me? Or comment in another issue marked E-mentor? Whatever works
Awesome! What is your nick on IRC? Mine is jhorwitz
same as github: steveklabnik

Related discussion:
text: - [abi_sysv64](abi-sysv64.md) - [abi_unadjusted](abi-unadjusted.md) - [abi_vectorcall](abi-vectorcall.md) <ins> - [abi_x86_interrupt](abi-x86-interrupt.md) </ins> - [advanced_slice_patterns](advanced-slice-patterns.md) - [alloc_jemalloc](alloc-jemalloc.md) - [alloc_system](alloc-system.md)
Code change:
see I'm happy to help mentor anyone who wants to fix this issue.
Hello, I would like to work on this issue.
I would love to work on this and be mentored as well in case topecongiro can not. Thank you!
got sent in, so maybe we can work together on some other issue? Just let me know, happy to help you help me.
That would be great, thank you so much would love to work with you.
Awesome. Maybe jump on IRC and message me? Or comment in another issue marked E-mentor? Whatever works
Awesome! What is your nick on IRC? Mine is jhorwitz
same as github: steveklabnik

Related discussion:
text: <ins> # `abi_x86_interrupt` The tracking issue for this feature is: [#40180] [#40180]: https://github.com/rust-lang/rust/issues/40180 ------------------------ </ins>
Code change:
seems to be ignored For example: I expected to see no warning about the mut flag of a Instead, this happened: This currently happens on all 3 major branches: stable, beta, nightly: Backtrace: does not give more information.
Note that increasing the scope of the avoids the warning as expected: Unclear whether applying the to the should be sufficient.
I'm guessing that the lint passes were just not updated when attributes were allowed to be attached to statements.
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address.
cc
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address. is also ignored when statement is located inside of a macro, regardless of whether is located above the statement, macro, or function in which macro is called: ,L235 It would be nice if it did work for single statements inside of a macro. Main channels are still affected: stable: rustc 1.20.0 ( 2017-08-27) beta: rustc 1.21.0-beta.3 ( 2017-09-15) nightly: rustc 1.22.0-nightly ( 2017-09-14)

Related discussion:
text: } impl<'a, 'tcx> LateLintPass<'a, 'tcx> for UnusedMut { <del> fn check_expr(&mut self, cx: &LateContext, e: &hir::Expr) { if let hir::ExprMatch(_, ref arms, _) = e.node { for a in arms { self.check_unused_mut_pat(cx, &a.pats) } } </del> <ins> fn check_arm(&mut self, cx: &LateContext, a: &hir::Arm) { self.check_unused_mut_pat(cx, &a.pats) </ins> } <del> fn check_stmt(&mut self, cx: &LateContext, s: &hir::Stmt) { if let hir::StmtDecl(ref d, _) = s.node { if let hir::DeclLocal(ref l) = d.node { self.check_unused_mut_pat(cx, slice::ref_slice(&l.pat)); } } </del> <ins> fn check_local(&mut self, cx: &LateContext, l: &hir::Local) { self.check_unused_mut_pat(cx, slice::ref_slice(&l.pat)); </ins> } fn check_fn(&mut self,
Code change:
seems to be ignored For example: I expected to see no warning about the mut flag of a Instead, this happened: This currently happens on all 3 major branches: stable, beta, nightly: Backtrace: does not give more information.
Note that increasing the scope of the avoids the warning as expected: Unclear whether applying the to the should be sufficient.
I'm guessing that the lint passes were just not updated when attributes were allowed to be attached to statements.
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address.
cc
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address. is also ignored when statement is located inside of a macro, regardless of whether is located above the statement, macro, or function in which macro is called: ,L235 It would be nice if it did work for single statements inside of a macro. Main channels are still affected: stable: rustc 1.20.0 ( 2017-08-27) beta: rustc 1.21.0-beta.3 ( 2017-09-15) nightly: rustc 1.22.0-nightly ( 2017-09-14)

Related discussion:
text: let mut a = 3; let mut b = vec![2]; } <ins> // make sure the lint attribute can be turned off on let statements #[deny(unused_mut)] fn bar() { #[allow(unused_mut)] let mut a = 3; let mut b = vec![2]; //~ ERROR: variable does not need to be mutable } </ins>