jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass pub trait Deserialize<'de>: Sized {} pub trait DeserializeOwned: for<'de> Deserialize<'de> {} pub trait Extensible { type Config; } // The `C` here generates a `C: Sized` candidate pub trait Installer<C> { fn init<B: Extensible<Config = C>>(&mut self) -> () where // This clause generates a `for<'de> C: Sized` candidate B::Config: DeserializeOwned, { } } fn main() {} </ins>

Discussion:
Hello After upgrading nightly rustc, I'm getting a lot of type inference errors on code that was compiling fine previously. Moreover, these are not at the call site, but at the definition site, so there doesn't seem to be any place to put any type annotations, like this: It spills more kinds of errors that make little sense, but I have the impression these will have a common cause: The problematic code is both released on (crate spirit, version 0.4.16, but I expect that to be happening through most of the history of the crate), and in master (). I think this is a regression, as it was compiling previously. It compiles fine with older nightly (and stable is fine way back, this particular code is looking mostly the same for some 2 years or more): Breaks with (Unfortunately, I haven't been keeping fully up to date recently, so I don't have a smaller range).
Bisected: searched nightlies: from nightly-2021-01-01 to nightly-2021-04-20 regressed nightly: nightly-2021-04-01 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: </detailsRegressed PR is , cc
An MCVE would be extremely helpful here.
ping icebreakers-cleanup-crew I've tried without success to reduce this, it's buried in layers of crates. Maybe one of you will have better luck.
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Reduced:
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-high
I can try to look into this over the weekend.
So, a bit of info: We end up trying to prove . We end up with two candidates: and that both evaluate to okay. This is ambiguous and WF checking fails.
This regression now slipped into beta 1.53.0.
Change:
default fn fly(&self) {} //~^ ERROR E0520 //~| NOTE cannot specialize default item `fly` <del> //~| NOTE either the parent `impl` or `fly` in the parent `impl` must be marked `default` </del> <ins> //~| NOTE `fly` in the parent `impl` must be marked `default` </ins> } fn main() {

Discussion:
Because the itself cannot be marked , only the individual item.
Hi, I'm very new to rust and I'm trying to learn more about this language. I would like to make the change. Seems that I have to change the error text (e.g. ..., but the item of the parent impl is not marked ), Is it right? However searching about specialization documents I found this issue where seems that a will be possible. Am i missing something?
The text should suggest that the item could be , but not that the parent impl could be, because it can't. It might be in the future (as suggested by ) but that is not certain.
Hi , I'm seeing a bit more deep the specialization feature. I'm wondering if I can try to implement the . I have in mind to do what is described in the following quotes taken from the RFC For the moment, with this implementation, the must define all items of the trait (not a part of them) and, therefore, they will be all treated as default items. Would you accept a PR for this?
there is some debate at the moment about some of the details of specialisation. It would probably be best to open a thread on before starting to work on this.
PR was merged, so this can be closed now.
Change:
debug!("exp_found {:?} terr {:?}", exp_found, terr); if let Some(exp_found) = exp_found { self.suggest_as_ref_where_appropriate(span, &exp_found, diag); <ins> self.suggest_accessing_field_where_appropriate(cause, &exp_found, diag); </ins> self.suggest_await_on_expect_found(cause, span, &exp_found, diag); }

Discussion:
Just encountered the following output: It would be nice if we could peek at the fields of and provide an appropriate structured suggestion: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
<ins> // Regression test for #122659 //@ build-pass //@ compile-flags: -O --crate-type=lib #![feature(core_intrinsics)] #![feature(const_eval_select)] use std::intrinsics::const_eval_select; #[inline] pub const fn f() { const_eval_select((), g, g) } #[inline] pub const fn g() { const_eval_select((), f, f) } </ins>

Discussion:
Apply this patch: And you'll get this query cycle error: There's a strange call graph here; which is responsible for emitting string slicing panics uses panicky string slicing. From reading the code, I'm pretty confident that the infinite recursion case is actually impossible, but our query cycle detection doesn't know or care, and is supposed to handle this case.
The cycle detection probably doesn't understand intrinsic. The intrinsic is lowered in query, while cycle detection operates on .
That was my instinct as well. What's tripping me up mentally is that with this patch, I can without a cycle error: There's no inside of the cycle detection logic. I think there should be. But I also think that since the latest beta, we accidentally fixed this somehow?
Nightly reproducer:
Change:
let (value_hash, old_hash): (Fingerprint, Fingerprint) = tcx.with_stable_hashing_context(|mut hcx| (hasher(&mut hcx, &value), hasher(&mut hcx, &old)) ); <del> assert_eq!( old_hash, value_hash, "Trying to feed an already recorded value for query {} key={key:?}:nold value: {old:?}nnew value: {value:?}", stringify!($name), ) </del> <ins> if old_hash != value_hash { // We have an inconsistency. This can happen if one of the two // results is tainted by errors. In this case, delay a bug to // ensure compilation is doomed, and keep the `old` value. tcx.sess.delay_span_bug(DUMMY_SP, format!( "Trying to feed an already recorded value for query {} key={key:?}:n old value: {old:?}nnew value: {value:?}", stringify!($name), )); } </ins> } else { <ins> // The query is `no_hash`, so we have no way to perform a sanity check. // If feeding the same value multiple times needs to be supported, // the query should not be marked `no_hash`. </ins> bug!( "Trying to feed an already recorded value for query {} key={key:?}:nold value: {old:?}nnew value: {value:?}", stringify!($name),

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
cc
searched toolchains nightly-2023-04-20 through nightly-2023-04-28 Regression in nightly-2023-04-22 searched toolchains through Regression in
Change:
<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. // aux-build:issue-41211.rs // FIXME: https://github.com/rust-lang/rust/issues/41430 // This is a temporary regression test for the ICE reported in #41211 #![feature(proc_macro)] #![emit_unchanged] //~^ ERROR: cannot find attribute macro `emit_unchanged` in this scope extern crate issue_41211; use issue_41211::emit_unchanged; fn main() {} </ins>

Discussion:
An ICE occurs when invoking a procedural macro attribute on the root of a crate with . Relevant backtrace frames: This happens on the latest nightly . cc
If you haven't started on this one I'll go ahead and take a crack at it since people are stumbling on it.
That second unwrap is which is infallible. That's kind of misleading, but okay.
Change:
ecx: &mut InterpCx<'mir, 'tcx, Self>, instance: ty::Instance<'tcx>, args: &[OpTy<'tcx>], <del> ret: Option<(PlaceTy<'tcx>, mir::BasicBlock)>, </del> <ins> _ret: Option<(PlaceTy<'tcx>, mir::BasicBlock)>, </ins> _unwind: Option<mir::BasicBlock>, // unwinding is not supported in consts ) -> InterpResult<'tcx, Option<&'mir mir::Body<'tcx>>> { debug!("find_mir_or_eval_fn: {:?}", instance);

Discussion:
Since , memoization of argumentless functions is restricted to intrinsics, because other functions could perform heap allocations and thus memoization would be incorrect. I doubt we have any argumentless intrinsic that is expensive enough that memoization is worth it, so I propose we remove the leftovers of that infrastructure. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I want to work on this but i never contributed to rust-lang before so i need some guidance.
Great! So... step 0 is to write as a comment here, this will make sure the issue is assigned to you and noone else tries to tackle it at the same time. The main change is to remove this function: entirely without a replacement. You'll then have to adjust the call site to act as if the function returned . This may allow some small cleanups at the call site; I expect nothing major to happen there. I do not think there will be further test changes due to this, so, should run through without any failures. If it doesn't, still open a PR and let us know of your findings.
claim
Change:
<ins> //@ check-pass #![feature(postfix_match)] fn main() { (&1).match { a => a }; (1 + 2).match { b => b }; } </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. --cc . I tried this code: I expected to see this happen: no warnings Instead, this happened: <!-- 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. --:
Change:
<ins> // Issue 61711: A crate pub re-exporting `crate` was causing an // infinite loop. // edition:2018 // aux-build:xcrate-issue-61711-b.rs // compile-flags:--extern xcrate_issue_61711_b // run-pass fn f<F: Fn(xcrate_issue_61711_b::Struct)>(_: F) { } fn main() { } </ins>

Discussion:
I have three crates: (library), (library), and (binary). has no dependencies, and its is just: has the following dependency and : has the following dependency and : The following error happens running or in crate : Try as I may, I can't manage to make the error happen without putting in every one of those lines and dependencies. EDIT: the bug only requires , not
pre-triage: P-high, removing nomination tag. assigning to self for initial investigation.
(seems to me like the line is not necessary to reproduce the bug?) ((but the nonetheless does remain necessary for reproduction....))
Here is a shell script to compile the files using itself (so we get out of the way) and run the compile of under :
and the backtrace from gives us a pretty good hint as to where we might be infinite-looping: (and so on, for at least 15,000 stack frames...)
(prior to rust 1.35.0, it seems like we might have infinite looped here with no stack overflow. Not 100% sure of that yet; and this test case currently relies on 2018 edition, so its not easy to go back to earlier than 1.31.0)
Also, you can inline the contents of crate a into crate b and preserve the erroneous behavior:
Okay I think I have a solution for this. Hope to post PR today or tomorrow.
Change:
| = help: to create the module `řųśť`, create file "$DIR/řųśť.rs" <del> error[E0754]: trying to load file for module `řųśť` with non ascii identifer name </del> <ins> error[E0754]: trying to load file for module `řųśť` with non-ascii identifier name </ins> --> $DIR/mod_file_nonascii_forbidden.rs:3:5 | LL | mod řųśť;

Discussion:
It was mentioned in that in the original RFC text, there's text that said the non-ASCII identifiers should be disallowed within extern blocks. This is a niche use-case and i believe this doesn't need to block stablization. Creating this issue here to track it.
What will something like actually link against? This seems like it might be a forward-compatiblity hazard when linking to external code, since the precise mangling/encoding isn't clear
I think we should just disallow for now; and later check out what C does and match that.
do you want to implement this? Should be a simple check in the parser.
Sure, let me give it a try.
Implemented in .
On the other hand the use of non-ASCII symbol names is already stable through link_name attribute.
Out of curiosity, I checked how Clang and GCC mangle the symbol: they simply use UTF-8. MSVC doesn't seem to allow non-ascii in identifier. (Notice how the byte-length encoding in C++ is using the UTF-8 byte count, and not the code point count, as I would expect)
Yeah I feel like the functionality can be re- with an FCP without much work, there just needs to be some research on how stable those mangling schemes are around this.
As for , my take on that is that once you're using that you're trying something weird and know what you're doing; there is no point restricting it further since it's very easy to accidently block out legit use cases.
Inversely, I've just noticed that despite usage of a properly-ASCII-ed , if the "Rust name" is non-ASCII then it is still rejected:
Change:
<ins> error[E0161]: cannot move a value of type [u8]: the size of [u8] cannot be statically determined --> $DIR/return-unsized-from-trait-method.rs:11:17 | LL |         let _ = f.foo(); |                 ^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0161`. </ins>

Discussion:
This does generate code that calls in the vtable, but is not particularly useful. cc
Still a problem?
It's still true, but I'm not especially worried about it.
Isn't it a bug that you can declare such a trait at all? There's no way to implement it, right?
This code is now rejected with:
Change:
.label = lower bound larger than upper bound .teach_note = When matching against a range, the compiler verifies that the range is non-empty. Range patterns include both end-points, so this is equivalent to requiring the start of the range to be less than or equal to the end of the range. <ins> mir_build_literal_in_range_out_of_bounds = literal out of range for `{$ty}` .label = this value doesn't fit in `{$ty}` whose maximum value is `{$max}` </ins> mir_build_lower_range_bound_must_be_less_than_upper = lower range bound must be less than upper mir_build_leading_irrefutable_let_patterns = leading irrefutable {$count ->

Discussion:
For a match where I'm matching on a , I put on accident, and then rather than saying that 256 is out of range for , it decided to wrap 256 to 0 and then error that 251 is lower than the end of the range: Clearly this is not a good situation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to fix this claim
Triage: I'm going to release assignment due to inactivity. If you're still interested in this, feel free to re-claim. release-assignment
Explanation on how to solve this in
Change:
} } <ins> #[stable(feature = "symmetric_u32_duration_mul", since = "1.30.0")] impl Mul<Duration> for u32 { type Output = Duration; fn mul(self, rhs: Duration) -> Duration { rhs.checked_mul(self).expect("overflow when multiplying scalar by duration") } } </ins> #[stable(feature = "time_augmented_assignment", since = "1.9.0")] impl MulAssign<u32> for Duration { fn mul_assign(&mut self, rhs: u32) {

Discussion:
Attempting to compile this: will give this error: I was thinking that a clearer error could be something along the lines of: and give this hint:
This should be straightforward to add a help message for. This error message is emitted here: The immediately afterwards is responsible for giving suggestions relevant to the particular type. You'd need to add a new case for () and emit an appropriate message (there are examples for other types in the expression), if the field is numeric. If anyone'd like to tackle this, just post a reply here — I can give more details as needed (but it's always useful to try working things out yourself first, to get a feel for where to find things).
I don't have any experience with Rustc's codebase, but I would be willing to give it a try.
great! If you need any help, you can post a comment here, or ask on or #rustc. Once you add the help message, you'll need to add a test for it (there are plenty of examples in — you can run to test and produce the output).

Do you have some more info? Is this something users experience? Or is it mostly custom drivers running into problems?
When implementing myself I accidentally tried to parse a different file type. This returned an error from , but the error was never printed to the user, instead it said ...`.
It's possible if an rlib/dylib gets corrupt, because then it won't say the file is corrupt. Yes
Change:
<ins> fn foo() { let a = 0; let b = 4; if a =< b { //~ERROR println!("yay!"); } } fn bar() { let a = 0; let b = 4; if a = <b { //~ERROR println!("yay!"); } } fn baz() { let a = 0; let b = 4; if a = < b { //~ERROR println!("yay!"); } } fn qux() { let a = 0; let b = 4; if a =< i32>::abs(-4) { //~ERROR: mismatched types println!("yay!"); } } fn main() {} </ins>

Discussion:
The simplest reproduction would be something like this: the `note points at the operator A new user might get confused about needing a type, as the error points at the number instead of the comparator. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
output: Option<Type> } <del> impl fmt::Display for IndexItemFunctionType { /// Formats a full fn type as a JSON {inputs: [Type], outputs: Type/null}. fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { </del> <ins> impl ToJson for IndexItemFunctionType { fn to_json(&self) -> Json { </ins> // If we couldn't figure out a type, just write `null`. <del> if self.inputs.iter().any(|ref i| i.name.is_none()) || (self.output.is_some() && self.output.as_ref().unwrap().name.is_none()) { return write!(f, "null") </del> <ins> if self.inputs.iter().chain(self.output.iter()).any(|ref i| i.name.is_none()) { Json::Null } else { let mut data = BTreeMap::new(); data.insert("inputs".to_owned(), self.inputs.to_json()); data.insert("output".to_owned(), self.output.to_json()); Json::Object(data) </ins> } <del> let inputs: Vec<String> = self.inputs.iter().map(|ref t| { format!("{}", t) }).collect(); try!(write!(f, "{{"inputs":[{}],"output":", inputs.join(","))); match self.output { Some(ref t) => try!(write!(f, "{}", t)), None => try!(write!(f, "null")) }; Ok(try!(write!(f, "}}"))) </del> } }

Discussion:
E.g. doesn't show the crate.
ccing myself, will have a look at this in the next week or so.
cc me
Triage: searching for libc doesn't show libc.
Hmm, I deliberately removed the search-index entry in because it was .
Change:
} } <ins> trait Bar { fn foo() -> Wrapper<impl Sized>; //~^ ERROR missing lifetime specifier //~| ERROR struct takes 0 generic arguments but 1 generic argument was supplied } impl Bar for () { fn foo() -> Wrapper<impl Sized> { //~^ ERROR missing lifetime specifier //~| ERROR struct takes 0 generic arguments but 1 generic argument was supplied Wrapper(&()) } } </ins> fn main() {}

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '', 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '' 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Okay, lol, here the types obviously do unify and therefore isn't effective in this situation.
More fundamentally, the thing that goes “wrong” in these kinds of situations is the fact that we call if we have which is the case because generated one because the HIR (!) type visitor inside found an opaque type in the HIR type (here ) while the lowered type (here ) no longer contains any opaque types ultimately leading to the assert triggering. In short: visit the HIR ty , see an opaque type and take note of that synthesize an assoc ty for the RPITIT (I think) because of (1) lower the ty to due to the argument kind mismatch try to collect RPITITs on the lowered type & fail to find the opaque type I don't know if this is actually useful in general :thinking: What kinds of bugs is it supposed to catch?
cc
So either we delay the detection of RPITITs and the synthesis of RPITIT assoc tys until after HIR ty lowering / AstConv (but I don't know if that's an option) or we modify the assert (either remove it outright or check the corresp. HIR ty, I don't know if that makes sense; furthermore oli is/was on a roll to remove HIR operations from this part of the code base iirc).

Yeah, this assertion was simply there to make sure we weren't incorrectly calling for methods that had no RPITITs themselves (b/c it's expensive, and it actually is a bit stronger in what it enforces in the method signatures since it uses rather than in the signature relation for lifetime reasons), but now that this code isn't being changed much, I doubt that will ever happen. Feel free to remove it, or else I can do.
We could also delay a bug on mismatch
Change:
<ins> // Make sure that the mono-item collector does not crash when trying to // instantiate a default impl for DecodeUtf16<<u8 as A>::Item> // See https://github.com/rust-lang/rust/issues/58375 // build-pass // compile-flags:-C link-dead-code #![crate_type = "rlib"] pub struct DecodeUtf16<I>(I); pub trait Arbitrary { fn arbitrary() {} } pub trait A { type Item; } impl A for u8 { type Item = char; } impl Arbitrary for DecodeUtf16<<u8 as A>::Item> {} </ins>

Discussion:
With the change in function shouldrunsuccessfully() of commit : RunPass =true, Ui == Some(PassMode::Run), RunPass | Ui =self.effectivepass_mode() == Some(PassMode::Run), The test cases under run-pass directory are tested for building only, the compiled test cases are not running any more. Does it work as design?
Oh. This is bad. Will fix today. cc (on vacation)
Fixed in