jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass #![warn(unused_parens)] fn id<T>(t: T) -> T { t } fn main() { // This should not warn let _ = 1 as (i32) < 2; let _ = id(1 as (i32) < 2); let _ = id(1 as i32) as (i32) < 2; // These should warn let _ = 1 as ((i32)) < 2; //~WARN unnecessary parentheses let _ = 1 as (i32); //~WARN unnecessary parentheses let _ = 1 as (i32) > 2; //~WARN unnecessary parentheses let _ = id(1 as (i32)) //~WARN unnecessary parentheses as (i32) < 2; let _ = id(1 as (i32)) < 2; //~WARN unnecessary parentheses // This should not warn let _ = 1 as (i32) << 2; let _ = id(1 as (i32) << 2); let _ = id(1 as i32) as (i32) << 2; // These should warn let _ = 1 as ((i32)) << 2; //~WARN unnecessary parentheses let _ = 1 as (i32); //~WARN unnecessary parentheses let _ = 1 as (i32) >> 2; //~WARN unnecessary parentheses let _ = id(1 as (i32)) //~WARN unnecessary parentheses as (i32) << 2; let _ = id(1 as (i32)) << 2; //~WARN unnecessary parentheses } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: But with the suggestion applied the compiler displays an error with a different suggestion: <!-- The following is not always necessary. --Ideally the compiler should not output a warning and treat and as identical. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. -- label D-incorrect A-suggestion-diagnostics <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think it's relate with and
It would be great if it could give since parenthesizing the expression instead avoids the potential "is that a tuple?" confusion of .
Duplicate of .
Change:
} #[test] <del> #[cfg(unix)] // test doesn't work on Windows, see #31657 </del> fn close_read_wakes_up() { each_ip(&mut |addr| { let a = t!(TcpListener::bind(&addr));

Discussion:
It just happend with my unrelated pull request on auto-win-msvc-32-opt. It is the only test that dit not complete between this build and the previous. It also contains the comment: "this test will never finish if the child doesn't wake up"
This seems to be relevant. A thread may not wake up on Windows if a socket is shut down.
Hm that just seems to indicate that the child will eventually wake up... I wonder if would fix the problem here?
Change:
/// `etc` is true if the pattern said '...' and false otherwise. pub fn check_struct_pat_fields(pcx: &pat_ctxt, span: Span, <del> path: &ast::Path, </del> fields: &[ast::FieldPat], <del> class_fields: Vec<ty::field_ty> , </del> <ins> class_fields: Vec<ty::field_ty>, </ins> class_id: ast::DefId, substitutions: &ty::substs, etc: bool) {

Discussion:
This is one of those bugs where an earlier error is leading to poor error reporting later on in the output. So it should not be considered high priority. Nonetheless, it would be nice if we could strive for error messages to be sane when considered in isolation, which this example violates: Transcript: The issue is that the second message claims that does not have a field named , but it clearly does. I could understand this message if it said vec2 does not have a field named .
Change:
impl<A: Hash> Hash for VecDeque<A> { fn hash<H: Hasher>(&self, state: &mut H) { self.len().hash(state); <del> let (a, b) = self.as_slices(); Hash::hash_slice(a, state); Hash::hash_slice(b, state); </del> <ins> // It's not possible to use Hash::hash_slice on slices // returned by as_slices method as their length can vary // in otherwise identical deques. // // Hasher only guarantees equivalence for the exact same // set of calls to its methods. self.iter().for_each(|elem| elem.hash(state)); </ins> } }

Discussion:
VecDeque's hashcode changes after rotation. In the following example, the VecDeque should be in its original ordering, yet it produces a different hashcode. I've also opened but I was advised to open a new issue here. I tried this code: I expected to see this happen: The hashcode should not change and the example should terminate successfully Instead, this happened: The hashcode is different and the application panics. Yes, the bug exists in beta and nightly. : The issue is caused by an ambiguity in the contract - it's not clear whether the hashcode should be sensitive to the slice's length. The default hasher is not sensitive, while ahash is. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Ah, you edited it just now.
Ugh, not another bug
I also filed with code references, but I closed in favor of this issue. My conclusions: If both and may consider length, then is incorrect. If should hash without length, but is allowed to use length, then the integer optimization ( calling as ) is incorrect. If both and are supposed to be independent of length, hashing identically whether it's one big slice or any partitioned slices of the same data, then is incorrect.
So ultimately this falls into the realm?
claim I will work on this
I do think this needs a decision first on the specified behavior.
This may also be suspect if a hasher is endian-sensitive -- e.g. if it would normalize to big/little-endian, but the cast to makes it always hash native-endian. But I suppose this is not a problem if you're always consistent in whether you use or not.
We discussed this in the libs meeting 2 weeks ago and came to the conclusion that is in the wrong here: only guarantees hash equivalence for the exact same set of calls to methods. This allows hasher to perform various optimizations when hashing slices, such as using unaligned load instructions.
Incidentally  could use some additional documentation to clarify that it is not necessarily equivalent to hashing each element individually in sequence.
We could potentially add a new method to Hasher that does behave that way, but I don't know if it'd really be useful in many contexts outside of something like VecDeque.
Assigning as discussed as part of the and removing .
Change:
<ins> // compile-pass // compile-flags: -Z unpretty=hir #![feature(existential_type)] trait Animal { } fn main() { pub existential type ServeFut: Animal; } </ins>

Discussion:
expanded with yields we should not print that extra
Hi, I will like to work on this issue.
awesome! Most likely all that is required is to remove you can check if there's a test in that has a comment with in it. If there is, just add the above test line to it and run tests with . If there is no such test, add such a test ;)
I think I fixed this in one of my PRs, but not sure when it will merge, so go for it. :-)
While adding test, I am getting following error message: The existing test can be seen here:
you need to add to the test
Added that, many thanks!
Change:
<ins> // exact-check const QUERY = 'true'; const FILTER_CRATE = 'some_other_crate'; const EXPECTED = { 'others': [], }; </ins>

Discussion:
I loaded the std doc at Firefox 77.0.1, then I typed fast for the word "true" (or click this link: ). I expected to see this happen: The search result appears and includes the "true" keyword link. Instead, this happened: No search result was shown. Also in the Firefox console, this was printed after typing the word "true": Version of std docs: 1.46.0-nightly ( 2020-06-21) cc in case you interest.
The type error happened along this line:
It looks like it fails when you have a crate filter selected. Almost certainly caused by (cc
yeah, that's right. I forgot about that detail.
should fix this.
Change:
// This is used to track which lifetimes have already been defined, // and which need to be replicated when lowering an async fn. <del> match parent_hir.node().expect_item().kind { </del> <ins> let generics = match parent_hir.node().expect_item().kind { </ins> hir::ItemKind::Impl(impl_) => { self.is_in_trait_impl = impl_.of_trait.is_some(); <ins> &impl_.generics </ins> } <del> hir::ItemKind::Trait(_, _, generics, _, _) if self.tcx.features().effects => { self.host_param_id = generics .params .iter() .find(|param| { matches!( param.kind, hir::GenericParamKind::Const { is_host_effect: true, .. } ) }) .map(|param| param.def_id); </del> <ins> hir::ItemKind::Trait(_, _, generics, _, _) => generics, kind => { span_bug!(item.span, "assoc item has unexpected kind of parent: {}", kind.descr()) </ins> } <del> _ => {} </del> <ins> }; if self.tcx.features().effects { self.host_param_id = generics .params .iter() .find(|param| { matches!(param.kind, hir::GenericParamKind::Const { is_host_effect: true, .. }) }) .map(|param| param.def_id); </ins> } match ctxt {

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no host param id for call in const yet no errors reported', 'error: internal compiler error: no host param id for call in const yet no errors reported' 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: --
Regression in nightly-2023-08-09
Change:
target_os = "openbsd" )))] mod imp { <del> use crate::ptr; </del> pub unsafe fn init() {} pub unsafe fn cleanup() {} pub unsafe fn make_handler() -> super::Handler { <del> super::Handler { _data: ptr::null_mut() } </del> <ins> super::Handler::null() </ins> } pub unsafe fn drop_handler(_handler: &mut super::Handler) {}

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: and compiled it with: I expected to see asan report a bad pointer use and give a backtrace. Instead I just got a raw sigsegv: Running with verbose output shows that AddressSanitizer is intercepting the signal. It looks like is also installing a signal handler, which is overriding the AddressSanitizer one. <!-- 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. --: </p</details
(set handler and prevent override) is a workaround, but I think the Rust runtime shouldn't stomp SIGSEGV in the sanitizer case.
cc
Change:
target: Target, item: Option<ItemLike<'_>>, ) -> bool { <del> let is_function = matches!(target, Target::Fn | Target::Method(..)); </del> <ins> let is_function = matches!(target, Target::Fn); </ins> if !is_function { self.tcx .sess

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: I think it's just that this attr ICEs when attached to methods and not functions.
claim
Change:
Array => tcx.lang_items.slice_impl(), Tuple => None, RawPointer => tcx.lang_items.const_ptr_impl(), <ins> Reference => None, </ins> }; if let Some(did) = did { if !did.is_local() {

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.
Change:
ast::ExprKind::Block(ref block, None) if block.stmts.len() > 0 => { let start = block.stmts[0].span; let end = block.stmts[block.stmts.len() - 1].span; <del> if value.span.from_expansion() || start.from_expansion() || end.from_expansion() { ( value.span.with_hi(value.span.lo() + BytePos(1)), value.span.with_lo(value.span.hi() - BytePos(1)), ) </del> <ins> if let Some(start) = start.find_ancestor_inside(value.span) && let Some(end) = end.find_ancestor_inside(value.span) { Some(( value.span.with_hi(start.lo()), value.span.with_lo(end.hi()), )) </ins> } else { <del> (value.span.with_hi(start.lo()), value.span.with_lo(end.hi())) </del> <ins> None </ins> } } ast::ExprKind::Paren(ref expr) => { <del> if value.span.from_expansion() || expr.span.from_expansion() { ( value.span.with_hi(value.span.lo() + BytePos(1)), value.span.with_lo(value.span.hi() - BytePos(1)), ) </del> <ins> let expr_span = expr.span.find_ancestor_inside(value.span); if let Some(expr_span) = expr_span { Some((value.span.with_hi(expr_span.lo()), value.span.with_lo(expr_span.hi()))) </ins> } else { <del> (value.span.with_hi(expr.span.lo()), value.span.with_lo(expr.span.hi())) </del> <ins> None </ins> } } _ => return,

Discussion:
Reported by here: (Note that but does not fix this bug.)
searched nightlies: from nightly-2021-01-07 to nightly-2021-12-24 regressed nightly: nightly-2021-09-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This regression was introduced in . cc
Not a fix, but if I make this change then there is no longer an ICE and I get
Thanks for opening the issue If someone finds a fix but doesn't know how to add the test, this pull request which solves a similar ICE has an example of how to add a test when there is a missing newline:
Change:
<ins> error[E0308]: `if` and `else` have incompatible types --> $DIR/issue-101065.rs:12:9 | LL |       let _x = if true { |  ______________- LL | |         FakeResult::Ok(FakeResult::Ok(())) | |         ---------------------------------- expected because of this LL | |     } else { LL | |         FakeResult::Ok(()) | |         ^^^^^^^^^^^^^^^^^^ expected enum `FakeResult`, found `()` LL | |     }; | |_____- `if` and `else` have incompatible types | = note: expected enum `FakeResult<FakeResult<()>>` found enum `FakeResult<()>` help: try wrapping the expression in `FakeResult::Ok` | LL |         FakeResult::Ok(FakeResult::Ok(())) |         +++++++++++++++                  + error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
rustc version: rustc 1.65.0-nightly ( 2022-08-25) I have a very small reproducer for a weird fix advice from rustc when the two branches of an if had a type mismatch: This will produce the following output: Applying this fix obviously doesn't help:
label +A-diagnostics +T-compiler +D-invalid-suggestion
Change:
/// It's guaranteed to be in the first place pub fn has_deref(&self) -> bool { // To make sure this is not accidently used in wrong mir phase <del> debug_assert!(!self.projection[1..].contains(&PlaceElem::Deref)); </del> <ins> debug_assert!( self.projection.is_empty() || !self.projection[1..].contains(&PlaceElem::Deref) ); </ins> self.projection.first() == Some(&PlaceElem::Deref) }

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Ah damn it, we keep getting broken so there's still no nightly with Miri. :(
Building std now ICEs on windows...? The same target works fine on my system, so it is host-specific. Sounds like one of the PRs in that rollup is buggy...
do you have a stack trace for that ICE?
Nope, I cannot reproduce so all we got is the . The ICE is .
Miri CI , not even in a Windows host. It's a 32bit host though. Would be great if someone with an x86_64 windows host could try to clone the Miri repo and do .
We're seeing a related-looking issue on Fuchsia on the same commit:
I'm unable to reproduce the ICE with on Btw the advice of results in a build error, because Miri was broken again by another PR.
This does look like my PR causes this.
Yeah when I wrote that, the other PR had not landed yet. ;)
Hm, that is odd. Not sure what the tools builder does differently, maybe it has debug assertions enabled? The line number in the ICE is so bad due to
Not sure how related they really are, the original ICE is some kind of out-of-bounds slice access within rustc itself... Could someone try upgrading Miri to current git master? Miri CI passes with latest rustc, after all... even if it fails again, we'll at least get better line numbers since was fixed. Maybe there is a way to run the windows tools runner without using up a full bors slot?
on it
Turns out the strange Windows-only ICE was caused by a buggy debug assertion:
Change:
let borrow_region_vid = borrow.region; debug!(?borrow_region_vid); <del> let region_sub = self.regioncx.find_sub_region_live_at(borrow_region_vid, location); </del> <ins> let mut region_sub = self.regioncx.find_sub_region_live_at(borrow_region_vid, location); </ins> debug!(?region_sub); <del> match find_use::find(body, regioncx, tcx, region_sub, location) { </del> <ins> let mut use_location = location; let mut use_in_later_iteration_of_loop = false; if region_sub == borrow_region_vid { // When `region_sub` is the same as `borrow_region_vid` (the location where the borrow is // issued is the same location that invalidates the reference), this is likely a loop iteration // - in this case, try using the loop terminator location in `find_sub_region_live_at`. if let Some(loop_terminator_location) = regioncx.find_loop_terminator_location(borrow.region, body) { region_sub = self .regioncx .find_sub_region_live_at(borrow_region_vid, loop_terminator_location); debug!("explain_why_borrow_contains_point: region_sub in loop={:?}", region_sub); use_location = loop_terminator_location; use_in_later_iteration_of_loop = true; } } match find_use::find(body, regioncx, tcx, region_sub, use_location) { </ins> Some(Cause::LiveVar(local, location)) => { let span = body.source_info(location).span; let spans = self .move_spans(Place::from(local).as_ref(), location) .or_else(|| self.borrow_spans(span, location)); <del> let borrow_location = location; if self.is_use_in_later_iteration_of_loop(borrow_location, location) { let later_use = self.later_use_kind(borrow, spans, location); </del> <ins> if use_in_later_iteration_of_loop { let later_use = self.later_use_kind(borrow, spans, use_location); </ins> BorrowExplanation::UsedLaterInLoop(later_use.0, later_use.1, later_use.2) } else { // Check if the location represents a `FakeRead`, and adapt the error

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: It looks like the error is pointing to the wrong spot in the code and is quite misleading. Ideally the output should mention that is still mutably borrowed because it holds a reference to between loops. Or something, im not actually sure :P I have confirmed that this occurs in both the latest stable (1.62.1) and nightly () <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
With the proposed the output will be like this:
Change:
ENV TARGETS=$TARGETS,armv7-unknown-linux-musleabi ENV TARGETS=$TARGETS,i686-unknown-freebsd ENV TARGETS=$TARGETS,x86_64-unknown-none <del> ENV TARGETS=$TARGETS,loongarch64-unknown-none ENV TARGETS=$TARGETS,loongarch64-unknown-none-softfloat </del> ENV TARGETS=$TARGETS,aarch64-unknown-uefi ENV TARGETS=$TARGETS,i686-unknown-uefi ENV TARGETS=$TARGETS,x86_64-unknown-uefi

Discussion:
When downloading the (and variant) target, the that ships with the compiler is broken: Upon further inspection, the symbols are indeed built for x86-64 and not LoongArch: It's not clear what causes this, but contains no corresponding definitions for . This issue appears related, in that it would catch whatever causes this:
cc
Change:
{ debug!("RootCollector: ADT drop-glue for `{id:?}`",); <ins> // This type is impossible to instantiate, so we should not try to // generate a `drop_in_place` instance for it. if self.tcx.instantiate_and_check_impossible_predicates(( id.owner_id.to_def_id(), ty::List::empty(), )) { return; } </ins> let ty = self.tcx.type_of(id.owner_id.to_def_id()).no_bound_vars().unwrap(); visit_drop_use(self.tcx, ty, true, DUMMY_SP, self.output); }

Discussion:
<!-- [31mICE[0m: Rustc '-Clink-dead-code=true --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: Failed to normalize Alias(Projection, AliasTy { args: [Bar], defid: DefId(0:4 ~ tribo[552e]::Foo::Assoc) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Alias(Projection, AliasTy { args: [Bar], defid: DefId(0:4 ~ tribo[552e]::Foo::Assoc) }), maybe try to call instead' 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: [mirshims] generating MIR shim for [collectandpartitionmonoitems] collectandpartitionmonoitems -- label +F-trivialbounds
cc this is the one that still crashes from