jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: unnecessary parentheses around pattern --> $DIR/unused-parens-in-macro-issue-120642.rs:26:19 | LL |               let (_t) = 1; |                   ^^^^ ... LL | unused_parens!(T1, T2, T3); | -------------------------- in this macro invocation | note: the lint level is defined here --> $DIR/unused-parens-in-macro-issue-120642.rs:3:9 | LL | #![warn(unused_parens)] |         ^^^^^^^^^^^^^ = note: this warning originates in the macro `unused_parens` (in Nightly builds, run with -Z macro-backtrace for more info) warning: unnecessary parentheses around type --> $DIR/unused-parens-in-macro-issue-120642.rs:23:18 | LL |                 <($($rest),*)>::bar() |                  ^^^^^^^^^^^^ ... LL | unused_parens!(T1, T2, T3); | -------------------------- in this macro invocation | = note: this warning originates in the macro `unused_parens` (in Nightly builds, run with -Z macro-backtrace for more info) warning: unnecessary parentheses around pattern --> $DIR/unused-parens-in-macro-issue-120642.rs:26:19 | LL |               let (_t) = 1; |                   ^^^^ ... LL | unused_parens!(T1, T2, T3); | -------------------------- in this macro invocation | = note: this warning originates in the macro `unused_parens` (in Nightly builds, run with -Z macro-backtrace for more info) warning: 3 warnings emitted </ins>

Discussion:
This code: Creates this diagnostic: I ran (note that I created a local project called playground) which created this output: This told me to create an issue here. Going into more depth regarding the issue - the macro expands after one step like so: and we can see where the issue is: These parentheses are indeed fully removable, and it points to an issue in the macro definition. By changing to the compiler no longer emits the warning, because now it expands to which is properly recognized as a tuple with one element, rather than a type surrounded by redundant parentheses. Another way to fix it is to remove the outer parentheses in the macro call: which does compile without warnings, but breaks usage of the macro with tuples with more than two elements: as while its fine to remove the parentheses when there is only one element between the angle brackets ( to ), it is not fine when there are more than one element in the tuple ( to ). Importantly, the compiler still emits the unused parentheses warning and suggests their removal when the macro is called with three types when you haven't removed the parentheses (). Therefore, part of the issue is that rustc detects the problem, and assumes it can fix it by going straight to the macro and correcting it, neglecting previous expansions of the macro which require the currently redundant parentheses. I say part of the issue, because going back to the original diagnostic: rustc marks and as removable, and it suggests you do so: when the diagnostic should really only be suggesting the removal of the outer brackets. I'm not too sure why this one happens. Using Syn's terminology, my best guess is that it has something to do with the span of the outer parentheses including the inner and after expansion. : Also tried with nightly (had identical results):
Change:
data.0.trait_ref.substs.types.get_slice(TypeSpace) .iter() .cloned() <del> .any(is_self) </del> <ins> .any(|t| t.has_self_ty()) </ins> } ty::Predicate::Projection(..) | ty::Predicate::WellFormed(..) |

Discussion:
Attempting to compile the following with my  crate yields an ICE: Output from
Reduced:
I'm able to reproduce this exact same error on stable and nightly today using this 8 line example:
Change:
#[test] #[cfg_attr(target_os = "emscripten", ignore)] <del> fn wait_timeout_ms() { </del> <ins> fn wait_timeout_wait() { </ins> let m = Arc::new(Mutex::new(())); <del> let m2 = m.clone(); </del> let c = Arc::new(Condvar::new()); <del> let c2 = c.clone(); let g = m.lock().unwrap(); let (g, _no_timeout) = c.wait_timeout(g, Duration::from_millis(1)).unwrap(); // spurious wakeups mean this isn't necessarily true // assert!(!no_timeout); let _t = thread::spawn(move || { let _g = m2.lock().unwrap(); c2.notify_one(); }); let (g, timeout_res) = c.wait_timeout(g, Duration::from_millis(u32::MAX as u64)).unwrap(); assert!(!timeout_res.timed_out()); drop(g); </del> <ins> loop { let g = m.lock().unwrap(); let (_g, no_timeout) = c.wait_timeout(g, Duration::from_millis(1)).unwrap(); // spurious wakeups mean this isn't necessarily true // so execute test again, if not timeout if !no_timeout.timed_out() { continue; } break; } } #[test] #[cfg_attr(target_os = "emscripten", ignore)] fn wait_timeout_wake() { let m = Arc::new(Mutex::new(())); let c = Arc::new(Condvar::new()); loop { let g = m.lock().unwrap(); let c2 = c.clone(); let m2 = m.clone(); let notified = Arc::new(AtomicBool::new(false)); let notified_copy = notified.clone(); let t = thread::spawn(move || { let _g = m2.lock().unwrap(); thread::sleep(Duration::from_millis(1)); notified_copy.store(true, Ordering::SeqCst); c2.notify_one(); }); let (g, timeout_res) = c.wait_timeout(g, Duration::from_millis(u64::MAX)).unwrap(); assert!(!timeout_res.timed_out()); // spurious wakeups mean this isn't necessarily true // so execute test again, if not notified if !notified.load(Ordering::SeqCst) { t.join().unwrap(); continue; } drop(g); t.join().unwrap(); break; } </ins> } #[test]

Discussion:
I have encountered what I think is unexpected behavior from on OSX: when called with "large" values the call will return immediately, instead of waiting for an call. What constitutes "large" is variable, and appears to correspond to the current value in the system monotonic clock source. The following code reproduces the issue: If you run the code above with the "small" value uncommented the internal loop only runs once, waiting for the 1-second sleep to expire before is called. But if you run with the "large" value uncommented, the internal loop runs a very large number of times as each call to returns almost immediately. As noted above, the actual value of "large" decreases over time, I believe based on . I unfortunately couldn't come up with a way to prove this is the case. I've seen this behavior on OSX Yosemite and Sierra. Edit: this happens on 1.11, 1.12, beta, and nightly.
This is likely related to the implementation using unchecked arithmetic and something overflowing. I'll tweak it to much Linux and test out to make sure it works.
Hm no that's correctly handling overflow... Hmm...
Fixed by
Change:
pub fn trans_foreign_mod(ccx: &CrateContext, foreign_mod: &ast::ForeignMod) { let _icx = push_ctxt("foreign::trans_foreign_mod"); for &foreign_item in foreign_mod.items.iter() { <ins> let lname = link_name(foreign_item); </ins> match foreign_item.node { ast::ForeignItemFn(..) => { match foreign_mod.abi { Rust | RustIntrinsic => {} <del> abi => { register_foreign_item_fn(ccx, abi, foreign_item); } </del> <ins> abi => { let ty = ty::node_id_to_type(ccx.tcx(), foreign_item.id); register_foreign_item_fn(ccx, abi, ty, lname.get().as_slice(), Some(foreign_item.span)); } </ins> } } _ => {} } <del> let lname = link_name(foreign_item); </del> ccx.item_symbols.borrow_mut().insert(foreign_item.id, lname.get().to_strbuf()); }

Discussion:
Spidermonkey's type is a union of size 64 bits. We represent this as in Rust. This works great on 64bit platforms. On 32bit platforms, the values get mangled when passed to the C library functions. This seems to be an ABI issue. We've encountered this before with which was about 32bit ARM. This gist contains sample programs and the generated IR for minimal test programs using rust-mozjs: Note that you will need my 32bit branch of rust-mozjs: You can put debugging printfs in in to see the value on the C side. The only notable thing I see in the IR is that the clang IR has when passing the . This seems like a Rust bug, but I'd also be interested if there is a workaround that will work on all platforms.
cc
cc me
Change:
pub fn node_ty(&self, id: ast::NodeId) -> Ty<'tcx> { match self.inh.node_types.borrow().get(&id) { Some(&t) => t, <ins> None if self.err_count_since_creation() != 0 => self.tcx().types.err, </ins> None => { self.tcx().sess.bug( &format!("no type for node {}: {} in fcx {}",

Discussion:
Found another bug in the compiler: This is the output from :
Do you have an example of code that produces this crash?
I managed to reproduce the error in the Rust play-pen: I will copy the snippet here anyway:
A simpler repro:
Change:
packages: &[], features: None, manifest_path: None, <ins> filters: &[], </ins> }, Test { name: "xsv",

Discussion:
As part of our CI we run "cargotest" on a variety of ecosystem crates, making sure they successfully build and run tests. Unfortunately, some of use stochastic tests like quickcheck, which means that a crate passing our CI one day may not necessarily mean it passes CI the next. Perhaps we should audit the tests being run and filter out ones like these? See and cc
Yeah I think we've discussed this to some extent previously within infra team as part of our "what to do about cargotest" discussions. cc in particular Not sure that we came to any conclusions though.
Related:
The test from xsv fails occasionally:
This just bit me and took a lot of time as I triple-checked that after bors failing twice (!) in xsv, the same test actually works fine on my system.
The xsv test suite seems to be full of quickcheck tests, so I think the only way to fix this is to remove xsv from cargotest (or to only run a short list of curated tests).
See where there is some discussion fo changing the cargotest set. I think implies dropping xsv.
Hm, that discussion seems to have stalled though. So to fix the immediate problem, I propose we do something like
Change:
tcx.adt_def(tcx.hir().get_parent_item(hir_id)).repr().discr_type().to_ty(tcx) } <del> Node::TypeBinding( TypeBinding { hir_id: binding_id, kind: TypeBindingKind::Equality { term: Term::Const(e) }, ident, .. }, ) if let Node::TraitRef(trait_ref) = tcx.hir().get_parent(*binding_id) </del> <ins> Node::TypeBinding(TypeBinding { hir_id: binding_id, kind: TypeBindingKind::Equality { term: Term::Const(e) }, ident, .. }) if let Node::TraitRef(trait_ref) = tcx.hir().get_parent(*binding_id) </ins> && e.hir_id == hir_id => { let Some(trait_def_id) = trait_ref.trait_def_id() else {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
--> $DIR/match-arm-without-braces.rs:26:27 | LL |         Some(Val::Foo) => 3; <del> |                        -- ^- help: use a comma to end a `match` arm expression: `,` |                        |  | |                        |  this statement is not surrounded by a body </del> <ins> |                        -- ^ this statement is not surrounded by a body |                        | </ins> |                        while parsing the `match` arm starting here <ins> | help: replace `;` with `,` to end a `match` arm expression | LL |         Some(Val::Foo) => 3, |                            ~ </ins> error: `match` arm body without braces --> $DIR/match-arm-without-braces.rs:31:11

Discussion:
The reason why it should be changed is because the new error message makes it clearer you should replace with . I was following the book, and I encountered this error. I didn't understand how to solve it and asked on the community discord, then a user in the community server then helped me and I managed to fix the error. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
assert!(!is_line_non_doc_comment("/// blah")); assert!(is_line_non_doc_comment("////")); } <ins> #[test] fn nested_block_comments() { let env = setup(@"/* /* */ */'a'"); let TokenAndSpan {tok, sp: _} = env.string_reader.next_token(); assert_eq!(tok,token::LIT_CHAR('a' as u32)); } </ins> }

Discussion:
Currently we don't support nested block comments. This allows lexing to be regular, but it widely seen as an inconvenience. Modify the lexer to keep track of comment nesting. Nominating backcompat.
I thought we were going to grow a macro to handle block quotes. Did that ever get implemented?
I don't know what you mean by block quotes.
Accepted for feature-complete
Don't line comments address pretty much all uses of nested block comments?
by block quote, I mean in the style of CPP's to allow for nesting comments. Something like this:
From what I've gathered from the code, there are two implementations of the comment parsing, one of which supports nested comments, so I guess should be fixed before this bug.
That's pretty funny that the pretty printer already supports nested comments. I don't think they necessarily have to be merged to fix this bug, though our lexing is a bit of a mess.
Are you going to tackle this?
If there's no massive refactoring to do, I can try! Expect a PR soon.
The reference manual says "Comments in Rust code follow the general C++ style of line and block-comment forms, with no nesting of block-comment delimiters" ... right after production rules for nested comments.
looks like it was forgotten to be updated, thanks for noticing! (I opened )
Change:
<ins> //@ compile-flags: -Zvalidate-mir //@ edition: 2021 #![feature(async_closure)] // NOT copy. struct Ty; fn hello(x: &Ty) { let c = async || { *x; //~^ ERROR cannot move out of `*x` which is behind a shared reference }; } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is:
Change:
fn test_iterator_peekable() { let xs = vec![0u, 1, 2, 3, 4, 5]; let mut it = xs.iter().map(|&x|x).peekable(); <ins> assert_eq!(it.len(), 6); </ins> assert_eq!(it.peek().unwrap(), &0); <ins> assert_eq!(it.len(), 6); </ins> assert_eq!(it.next().unwrap(), 0); <ins> assert_eq!(it.len(), 5); </ins> assert_eq!(it.next().unwrap(), 1); <ins> assert_eq!(it.len(), 4); </ins> assert_eq!(it.next().unwrap(), 2); <ins> assert_eq!(it.len(), 3); </ins> assert_eq!(it.peek().unwrap(), &3); <ins> assert_eq!(it.len(), 3); </ins> assert_eq!(it.peek().unwrap(), &3); <ins> assert_eq!(it.len(), 3); </ins> assert_eq!(it.next().unwrap(), 3); <ins> assert_eq!(it.len(), 2); </ins> assert_eq!(it.next().unwrap(), 4); <ins> assert_eq!(it.len(), 1); </ins> assert_eq!(it.peek().unwrap(), &5); <ins> assert_eq!(it.len(), 1); </ins> assert_eq!(it.next().unwrap(), 5); <ins> assert_eq!(it.len(), 0); </ins> assert!(it.peek().is_none()); <ins> assert_eq!(it.len(), 0); </ins> assert!(it.next().is_none()); <ins> assert_eq!(it.len(), 0); </ins> } #[test]

Discussion:
This should be in : This would require either implementing for (where ), or decoupling and (like in )
Change:
<ins> // Copyright 2015 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. // Regression test for #17746 fn main() {} struct A; impl A { fn b(&mut self) { self.a() } } trait Foo { fn dummy(&self) {} } trait Bar { fn a(&self); } impl Foo for A {} impl<T> Bar for T where T: Foo { fn a(&self) {} } </ins>

Discussion:
Test case: rustc output: Expected behavior: is automatically converted to in the call. The bug disappears if is changed to take , if is changed to take , or if the call is changed to . CC
cc
I can sort of imagine why this happens. I'm planning on picking at the method dispatch code over next week and I imagine I can fix this as I go.
Triage visit: this appears to be fixed. Tagging as needs test.
The original message includes a test case. Does it need to be modified somehow or just be in a PR?
Change:
try!(self.print_pat(&**p)); } try!(space(&mut self.s)); <del> match arm.guard { Some(ref e) => { try!(self.word_space("if")); try!(self.print_expr(&**e)); try!(space(&mut self.s)); } None => () </del> <ins> if let Some(ref e) = arm.guard { try!(self.word_space("if")); try!(self.print_expr(&**e)); try!(space(&mut self.s)); </ins> } try!(self.word_space("=>")); match arm.body.node { ast::ExprBlock(ref blk) => { // the block will close the pattern's ibox <del> try!(self.print_block_unclosed_indent(&**blk, indent_unit)); </del> <ins> try!(self.print_block_unclosed_indent(&**blk, indent_unit)); // If it is a user-provided unsafe block, print a comma after it if let ast::UnsafeBlock(ast::UserProvided) = blk.rules { try!(word(&mut self.s, ",")); } </ins> } _ => { try!(self.end()); // close the ibox for the pattern

Discussion:
The pretty printer is removing trailing commas from match arms that contain an block expression: Running it with produces: Which when compiled errors with:
Actually, I'm not sure what the right tag is here...
Change:
use back::archive::{Archive, METADATA_FILENAME}; use back::rpath; <ins> use back::manifest; </ins> use driver::driver::CrateTranslation; use driver::session::Session; use driver::session;

Discussion:
Windows executables should contain embedded application manifests [1]. This is especially important for 32-bit executables, because in the absence of a manifest they are subject to UAC installer detection heuristics [2], which may cause unexpected UAC prompts or even complete failure to execute (in unattended contexts) depending on presence of certain keywords in executable's file name.
You beat me by a few hours :) Here is the description I had in : The UAC issue in is caused by a missing in the binaries. We should include the following in all binaries: In an ideal world, we would allow the user to provide a custom manifest should they wish to require UAC elevation, for example. As another example, a user might want to provide entries in order to fully support Windows 8.1 (where the / functions unless is present in the manifest). The VC++ linker has the option for the UAC part. In a traditional MinGW build, this would be implemented something like this: Where would contain something like this (application.manifest would contain the XML stuff above):
I wonder if it would be easier to skip windres altogether and write resource directly into linked executable using .
I use to add manifest but I always felt this is a hack.
As of MSVC 2008, passing to should add the necessary manifest bits for UAC.
In case anyone finds this issue, you can use in a script to solve this:
Hello. It is over 1 year later now since this comment was posted. Is this nasty work around still necessary? Or does the Rust Compiler finally supports embedding Windows Manifest Files and Resources etc. (in anyway whatsoever)? Thanks!
Change:
<del> error: compilation successful --> $DIR/borrowing.rs:15:1 </del> <ins> error[E0597]: `a` does not live long enough --> $DIR/borrowing.rs:18:18 </ins> | <del> LL | / fn main() { #![rustc_error] // rust-lang/rust#49855 LL | |     let _b = { LL | |         let a = 3; LL | |         unsafe { (|| yield &a).resume() } ...  | LL | |     }; LL | | } | |_^ </del> <ins> LL |         unsafe { (|| yield &a).resume() } |                  ^^^^^^^^^^^^^ |                  | |                  borrowed value does not live long enough |                  borrow may end up in a temporary, created here LL |         //~^ ERROR: `a` does not live long enough LL |     }; |     -- temporary later dropped here, potentially using the reference |     | |     borrowed value only lives until here </ins> <del> error: aborting due to previous error </del> <ins> error[E0597]: `a` does not live long enough --> $DIR/borrowing.rs:24:9 | LL | /         || { LL | |             yield &a LL | |             //~^ ERROR: `a` does not live long enough LL | |         } | |_________^ borrowed value does not live long enough LL |       }; |       - borrowed value only lives until here LL |   } |   - borrow later used here, when `_b` is dropped error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0597`. </ins>

Discussion:
Code shows a case where doesn't stay borrowed for long enough allowing it to be mutated while a reference to it exists. I think treating generators as if they implement would fix this, but I'm not sure if this will end up causing incorrect errors in other places.
Change:
<ins> error[E0308]: mismatched types --> $DIR/clarify-error-for-generics-with-default-issue-120785.rs:6:9 | LL |     let mut b: What<usize> = What(5, vec![1, 2, 3]); |                ----------- expected due to this type LL |     let c: What<usize, String> = What(1, String::from("meow")); LL |     b = c; |         ^ expected `What`, found `What<usize, String>` | = note: expected struct `What<_, Vec<usize>>` found struct `What<_, String>` error[E0308]: mismatched types --> $DIR/clarify-error-for-generics-with-default-issue-120785.rs:10:9 | LL |     let mut f: What<usize, Vec<String>> = What(1, vec![String::from("meow")]); |                ------------------------ expected due to this type LL |     let e: What<usize> = What(5, vec![1, 2, 3]); LL |     f = e; |         ^ expected `What<usize, Vec<String>>`, found `What` | = note: expected struct `What<_, Vec<String>>` found struct `What<_, Vec<usize>>` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
or The current error message does not tell me the mismatch is in rather than in . It is also inconsistent with the error message I would get if has without the default types. When removing the default for the first parameter (which is not the mismatched one) like this: the error message is clearer: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim