jiebi/CodeConvo huggingface dataset:
Change:
} } <del> // If all predicates are inferable, drop the entire clause </del> <ins> // If all predicates in where clause are inferable, drop the entire clause </ins> // (including the `where`) <del> if hir_generics.has_where_clause_predicates && dropped_predicate_count == num_predicates </del> <ins> if hir_generics.has_where_clause_predicates && dropped_where_predicate_count == num_where_predicates </ins> { let where_span = hir_generics.where_clause_span; // Extend the where clause back to the closing `>` of the

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: <!-- Please provide a link to --The current output is: Rustfix will fail to apply this: ` So we need to extend span to include the as well? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The relevant code is in , with . The should be computed using in the loop, instead of crafting a specific computation. Likewise, should use method. If using those 2 methods from is not enough to solve the issue, those methods should perhaps be adapted.
claim
release-assignment Haven't been able to focus on this. Releasing assignment.
claim
Progress report: I'm working on it.
claim
Change:
fn point_at_returns_when_relevant( &self, <del> err: &mut Diagnostic, </del> <ins> err: &mut DiagnosticBuilder<'tcx, ErrorGuaranteed>, </ins> obligation: &PredicateObligation<'tcx>, );

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: <!-- Please provide a link to --The current output is: We shouldn't show here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
without
another one 
What ideal output would you suggest? Should we remove the suggestion line like:
Ideally we should be checking that the return type . If it's not suggestable, don't mention it.
claim
I actually believe that neither the E0029 nor the E0277 should have been emitted. I would check explicitly for and change the error to be (that way the error isn't printed out, but rustc will ICE if no other error is emitted, which should have happened).
The PR will prevent E0029 and E0277 from printing out after checking the type references.
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. struct A; fn main() { let a = A; a + a; //~ ERROR binary operation `+` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::Add` might be missing for `A` a - a; //~ ERROR binary operation `-` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::Sub` might be missing for `A` a * a; //~ ERROR binary operation `*` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::Mul` might be missing for `A` a / a; //~ ERROR binary operation `/` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::Div` might be missing for `A` a % a; //~ ERROR binary operation `%` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::Rem` might be missing for `A` a & a; //~ ERROR binary operation `&` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::BitAnd` might be missing for `A` a | a; //~ ERROR binary operation `|` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::BitOr` might be missing for `A` a << a; //~ ERROR binary operation `<<` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::Shl` might be missing for `A` a >> a; //~ ERROR binary operation `>>` cannot be applied to type `A` //~^ NOTE an implementation of `std::ops::Shr` might be missing for `A` a == a; //~ ERROR binary operation `==` cannot be applied to type `A` //~^ NOTE an implementation of `std::cmp::PartialEq` might be missing for `A` a != a; //~ ERROR binary operation `!=` cannot be applied to type `A` //~^ NOTE an implementation of `std::cmp::PartialEq` might be missing for `A` a < a; //~ ERROR binary operation `<` cannot be applied to type `A` //~^ NOTE an implementation of `std::cmp::PartialOrd` might be missing for `A` a <= a; //~ ERROR binary operation `<=` cannot be applied to type `A` //~^ NOTE an implementation of `std::cmp::PartialOrd` might be missing for `A` a > a; //~ ERROR binary operation `>` cannot be applied to type `A` //~^ NOTE an implementation of `std::cmp::PartialOrd` might be missing for `A` a >= a; //~ ERROR binary operation `>=` cannot be applied to type `A` //~^ NOTE an implementation of `std::cmp::PartialOrd` might be missing for `A` } </ins>

Discussion:
The error should give a note that the PartialEq trait might be missing. In the example below, I couldn't spot for a very long time why the Result<T, StringLikeTypewas working but my own error type failed with the error above. Rust beginners like me would enjoy such hints and save time finding simple problems. Relevant code: : rustc 1.5.0-nightly ( 2015-10-03)
Change:
// It tries to find a positive number k such that `f << k / 10^e` is an in-range // significand. This will result in about `2^53 * f * 10^e` < `10^17 * f * 10^e`. // One input that triggers this is 0.33...33 (375 x 3). <del> f_len + (e.abs() as u64) + 17 </del> <ins> f_len + e.unsigned_abs() + 17 </ins> } }

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
if is_int_bool_or_char(lhs_ty) && is_int_bool_or_char(rhs_ty) { // Int, bool, and char operations are fine. } else if lhs_ty.is_fn_ptr() || lhs_ty.is_unsafe_ptr() { <del> assert_eq!(lhs_ty, rhs_ty); </del> assert!(matches!( op, BinOp::Eq

Discussion:
<!-- [31mICE[0m: Rustc '' 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'', 'assertion failed ' left: Binder(fn(), [])' ' right: Binder(fn(), [Region(BrNamed(DefId(0:4 ~ 9CACA62BEBDE508A04F27A9C164063CBF2C6A046198481389A0AC4A29C2578C3[3bbd]::cmp::'a), 'a))])'' 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: [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
Regression in cc
that seems off :sweat_smile: this PR should not result in behavior differences
ah yes my bad :D I left in by accident from a previous bisection and that was the pr that the flag :laughing:
should exist since pretty much forever :grin: 1.48
Regression in nightly-2023-04-20 fetching (via remote github) commits from max(, 2023-04-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 10 commit[0] 2023-04-18: Auto merge of - petrochenkov:slimchild, r=cjgillot commit[1] 2023-04-18: Auto merge of - saethlin:encode-hashes-as-bytes, r=cjgillot commit[2] 2023-04-19: Auto merge of - jyn514:download-rustc-tests,

r=albertlarsan68 commit[3] 2023-04-19: Auto merge of - miguelraz:canoodling2-electric-boogaloo, r=compiler-errors commit[4] 2023-04-19: Auto merge of - matthiaskrgr:rollup-9m7rw3u, r=matthiaskrgr commit[5] 2023-04-19: Auto merge of - Nilstrieb:fluent-macro, r=davidtwco commit[6] 2023-04-19: Auto merge of - fee1-dead-contrib:rm-const-traits, r=oli-obk commit[7] 2023-04-19: Auto merge of - WaffleLapkin:‍sound, r=compiler-errors commit[8] 2023-04-19: Auto merge of - matthiaskrgr:rollup-346kik6, r=matthiaskrgr commit[9] 2023-04-19: Auto merge of - ecnelises:big_archive, r=bjorn3
This might be related to cc one nightly before this errors with so maybe const-related
the cause is that the assert mentioned in is wrong. COmparing pointers with different bound vars is ok. This should either use actual semantic equality or just yeet the assert
Change:
<ins> error: expected one of `(`, `+`, `,`, `::`, `<`, or `{`, found `->` --> $DIR/issue-108109-fn-trait-missing-paren.rs:3:34 | LL | pub fn func<F>() where F: FnOnce -> () {} |                           -------^^ expected one of `(`, `+`, `,`, `::`, `<`, or `{` |                           |     | |                           |     help: try adding parentheses |                           `Fn` bounds require arguments in parentheses error: aborting due to previous error </ins>

Discussion:
It feels like rustc should be able to determine that a trait followed by a is a -family trait bound and be able to suggest this behavior. If that is too general it could just check for , , . Very similar is if parenthesis are missing from regular declarations: Also happens on nightly according to Rust Playground. I'd like to try my hand at implementing this diagnostic, but I'll likely need a little bit of locational guidance. A naive code search show that the message is emitted by this code is the parser diagnostics, but I'm not sure if the adjustment would need to be made within that or from where it is invoked in this case. Edit: Updated to use the wording "-family trait bounds" rather than "HRTBs"._
Where this function is invoked. Try looking for the code that parses .
If you end up writing a fix, note that those trait bounds are usually called -family trait bounds, not “HRTBs”. The latter would require at least one higher-rank parameter to be involved (e.g. ).
It seems this diagnostic contextually comes from which does this token search by . As corroboration it also seems that declaring a regular without parenthesis causes a similar if more contextually understandable error: I naively think that the adjustment point should probably be rather than ... However I don't understand how the output gets multiple possibilities e.g. and in this output: or the whole list of Since it's only calling with from ... I guess this requires catching the result in and handling this result type somehow?
Any time you call , it stashes the token type you tried probing for and it'll present that in a list whenever you get to . (Or something like that).
Anyways, it shouldn't matter -- in the caller to (when parsing ), you could add a check for before calling and handle the token specifically.
Just chiming in to mention: in any parser change you make here make sure you don't start accepting new code and add tests for all combinations you can think of.
Change:
let mut by_move_body = body.clone(); MakeByMoveBody { tcx, field_remapping, by_move_coroutine_ty }.visit_body(&mut by_move_body); dump_mir(tcx, false, "coroutine_by_move", &0, &by_move_body, |_, _| Ok(())); <ins> // Let's just always validate this body. validate_body(tcx, &mut by_move_body, "Initial coroutine_by_move body".to_string()); </ins> // FIXME: use query feeding to generate the body right here and then only store the `DefId` of the new body. by_move_body.source = mir::MirSource::from_instance(InstanceKind::CoroutineKindShim { coroutine_def_id: coroutine_def_id.to_def_id(),

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:
} } <del> pub fn getenv(k: &OsStr) -> io::Result<Option<OsString>> { unsafe { match ENV.as_ref().unwrap().lock().unwrap().get_mut(k) { Some(value) => Ok(Some(value.clone())), None => Ok(None), } } </del> <ins> pub fn getenv(k: &OsStr) -> Option<OsString> { unsafe { ENV.as_ref().unwrap().lock().unwrap().get_mut(k).cloned() } </ins> } pub fn setenv(k: &OsStr, v: &OsStr) -> io::Result<()> {

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 --
Simplified. The other malformed-looking bytes don't matter, do they?
You are right, they don't. I should have simplified it before submit.
Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself. claim
Still working on this, but I figured an update may be helpful. My research indicates that the two characters that are potentially problematic are and . The work that needs to be done consists of 1) updating the macro expansion functions in to error in these cases; and 2) updating the macro documentation in to mention the new errors. Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I don't think just adding a check to raise error in these cases would be enough. The function shouldn't really panic (from the internals discussion). Another problem is when the OS supports this kind of environment variable. e.g. as key. would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) as this must be changes to which would take a while.
If this is going to be fixed upstream in in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.
Actually, simple solution: I'll do the fix.

Working on that now.
Was this fuzzer output? If so, which fuzzer were you using
Yes, I am using kira, a work-in-progress fuzzing tool
Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.
Yes, actually kira is structure-aware.
Change:
/// Provides a reference to the next element, without changing the iterator. /// <del> /// # Examples /// /// ``` /// #![feature(linked_list_extras)] /// /// use std::collections::LinkedList; /// /// let mut list: LinkedList<_> = vec![1, 2, 3].into_iter().collect(); /// /// let mut it = list.iter_mut(); /// assert_eq!(it.next().unwrap(), &1); /// assert_eq!(it.peek_next().unwrap(), &2); /// // We just peeked at 2, so it was not consumed from the iterator. /// assert_eq!(it.next().unwrap(), &2); /// ``` </del> <ins> /// This method will be removed soon. </ins> #[inline] #[unstable( feature = "linked_list_extras", reason = "this is probably better handled by a cursor type -- we'll see", issue = "27794" )] <ins> #[rustc_deprecated( reason = "Deprecated in favor of CursorMut methods. This method will be removed soon.", since = "1.47.0" )] </ins> pub fn peek_next(&mut self) -> Option<&mut T> { if self.len == 0 { None

Discussion:
This is a tracking issue for the unstable methods in the standard library. cc perhaps you can fill this in some more? The specific methods in question are: -
This is basically a lame version of cursors, which is what we should use instead imo. It's not 1:1 though -- this api lets you have all the elements yielded at once. Classic iterator tradeoff.
Triage: these are still unstable.
There are some ideas for a more complete API in
seems misnamed. Doesn't it do exactly what we call elsewhere?
I'm going to echo thoughts: An iterator conceptually represents a (double-ended) range of elements. The only operation that it supports is popping an element off the end of that range. A cursor on the other hand represents a position in a collection, and can be moved backwards or forwards in the collection. The cursor can be used to insert or remove an element at any given position in the collection. I strongly oppose adding insertion/deleting methods to since they do not fit at all with existing iterator usage patterns ( loops and functional-style methods). As I mentioned in the linked thread, a design based on the types in could be used.
Since we now have cursors, I think these methods should be removed.
Reopening since we only deprecated the methods instead of removing them. I'd say give it about 2 weeks then remove them.
Change:
<ins> // check-pass // From https://github.com/rust-lang/rust/issues/54121/ // // Whether the code compiled depended on the order of the trait bounds in // `type T: Tr<u8, u8> + Tr<u16, u16>` // But both should compile as order shouldn't matter. trait Tr<A, B> { fn exec(a: A, b: B); } trait P { // This compiled successfully type T: Tr<u16, u16> + Tr<u8, u8>; } trait Q { // This didn't compile type T: Tr<u8, u8> + Tr<u16, u16>; } #[allow(dead_code)] fn f<S: P>() { <S as P>::T::exec(0u8, 0u8) } #[allow(dead_code)] fn g<S: Q>() { // A mismatched types error was emitted on this line. <S as Q>::T::exec(0u8, 0u8) } // Another reproduction of the same issue trait Trait { type Type: Into<Self::Type1> + Into<Self::Type2> + Copy; type Type1; type Type2; } #[allow(dead_code)] fn foo<T: Trait>(x: T::Type) { let _1: T::Type1 = x.into(); let _2: T::Type2 = x.into(); } fn main() { } </ins>

Discussion:
I can't be sure that this behavior is unintended, but it definitely seems very strange and undesirable to me. This code works fine: But change the order of the trait bounds in the associated type , and it fails:
Probably a duplicate of
Here is another case of such behavior (). However, this will compile: Also, an example with concrete types will compile too: Similar issues:
This is fixed on nightly. Presumably by
I just bisected, and indeed this was fixed by . I think this needs a test, and then it can be closed.
Change:
} pub fn run_tests(config: Config) { <del> // FIXME(#33435) Avoid spurious failures in codegen-units/partitioning tests. if let Mode::CodegenUnits = config.mode { let _ = fs::remove_dir_all("tmp/partitioning-tests"); } </del> // If we want to collect rustfix coverage information, // we first make sure that the coverage file does not exist. // It will be created later on.

Discussion:
When doing a build with rustbuild, it turns out that two tmp/ dirs end up being created. One is in the directory that rustbuild owns, and one is in the current directory (next to the directory). The one next to the directory contains some information for partitioning tests and information about the error index. Both of these shouldn't exist and their output should be in the rustbuild build/ directory. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
More on rustbuild:
I seem to recall seeing a tmp directory inside build, but I can't seem to recreate it now. Maybe it only appears temporarily during some particular steps and I've deleted it. What do you see as the steps for removing the tmp directory inside build/? Or is the solution to leave that and move the tmp directory created in the root into the build/ directory?
I'd advocate to move the root tmp directory into the build/ directory, personally. The strategy here is to track down what's creating that dir (I'm not sure myself) and just update it to all use the build/ dir
Doesn't seem to be case anymore, creates only .
Perhaps creates it because I still see the second outside of the directory created in the last few days.
claim Indeed created this directory, I'll see if I can fix it.
This directory is created by tests which use like . I'll have PR soon.
cc (re-adds the outer to ).
release-assignment