jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // This used to mis-compile because the mir-opt `SimplifyArmIdentity` // did not check that the types matched up in the `Ok(r)` branch. // // run-pass // compile-flags: -Zmir-opt-level=2 #[derive(Debug, PartialEq, Eq)] enum SpecialsRes { Res(u64) } fn e103() -> SpecialsRes { if let Ok(r) = "1".parse() { SpecialsRes::Res(r) } else { SpecialsRes::Res(42) } } fn main() { assert_eq!(e103(), SpecialsRes::Res(1)); } </ins>

Related discussion:
text: PR introduced an ICE in the following code with :
cc with mir-opt-level=1: with mir-opt-level=2: Where the types are
Code change:
<ins> // This used to mis-compile because the mir-opt `SimplifyArmIdentity` // did not check that the types matched up in the `Ok(r)` branch. // // run-pass // compile-flags: -Zmir-opt-level=2 #[derive(Debug, PartialEq, Eq)] enum SpecialsRes { Res(u64) } fn e103() -> SpecialsRes { if let Ok(r) = "1".parse() { SpecialsRes::Res(r) } else { SpecialsRes::Res(42) } } fn main() { assert_eq!(e103(), SpecialsRes::Res(1)); } </ins>

Related discussion:
text: Since few Rustc nightly versions I see a miscompilation problem with the code below. I am using: If I compile with: The code:
NB: this is because it needs an unstable CLI flag to reproduce.
cc since this might have something to do with recent const-eval work (apologies if I left anyone out)
I've managed to minify it to
Bisected it to , most probably the same issue as
Code change:
for (idx, (param_ty, param)) in inputs_fn.chain(maybe_va_list).zip(body.params).enumerate() { // Check the pattern. let ty_span = try { inputs_hir?.get(idx)?.span }; <del> fcx.check_pat_top(&param.pat, param_ty, ty_span, false); </del> <ins> fcx.check_pat_top(&param.pat, param_ty, ty_span, None); </ins> // Check that argument is Sized. // The check for a non-trivial pattern is a hack to avoid duplicate warnings

Related discussion:
text: <!-- 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: <!-- The following is not always necessary. --Ideally the output should suggest to the user that they need to initialize the enum variant's value in order to use the . <!-- 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. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you give the output of what it should look like?
It should probably look similar to the suggestion given for and So I guess sth. like: Edit: Or instead of saying “to instantiate this tuple variant” we could say “to call this function” like it's done for the erroneous snippet (where is a ).
claim
commit the fix
Code change:
/// Converts a vector of bytes to a `String`. /// <del> /// A string slice ([`&str`]) is made of bytes ([`u8`]), and a vector of bytes </del> <ins> /// A string ([`String`]) is made of bytes ([`u8`]), and a vector of bytes </ins> /// ([`Vec<u8>`]) is made of bytes, so this function converts between the /// two. Not all byte slices are valid `String`s, however: `String` /// requires that it is valid UTF-8. `from_utf8()` checks to ensure that

Related discussion:
text: This chunk was supposedly copy-pasted as is from It should read A String ([]) is made of bytes
Hi there. Can I pick this up as first-timer task?
Code change:
use rustc_span::symbol::{kw, sym, Symbol}; use rustc_span::Span; <del> use crate::clean::{self, Attributes, AttributesExt, FakeDefId, GetDefId, ToSource}; </del> <ins> use crate::clean::{ self, Attributes, AttributesExt, FakeDefId, GetDefId, NestedAttributesExt, ToSource, Type, }; </ins> use crate::core::DocContext; use crate::formats::item_type::ItemType;

Related discussion:
text: Last line yields several occurrences of in the generated file. ## Expected behavior No occurrences of anywhere since it was label C-bug T-rustdoc cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I expect the fix is to check for just after
claim
cc I checked for doc(hidden) like this: But it doesn't seem to work, as my test would fail. I also tried using the same way to check for but it also failed. I noticed that the issue involves so I might need to iterate over generic parameters, I cannot find any function that does that in , so can someone point me in the right direction? Thanks :)
You can look at how the pass works:
am I right in understanding this only happens for cross-crate traits, and impls for hidden traits in the same crate are still hidden? In other words, just makes the cross-crate case consistent?
I believe so, yes: the pass was already taking care of such cases for local types. FWIW, the thing that motivated this discussion was noticing a leaking on the docs for , but not on the ones for
Code change:
<ins> // Regression test for #71546. // ignore-compare-mode-nll // NLL stderr is different from the original one. pub fn serialize_as_csv<V>(value: &V) -> Result<String, &str> where V: 'static, for<'a> &'a V: IntoIterator, for<'a> <&'a V as IntoIterator>::Item: ToString + 'static, { let csv_str: String = value //~ ERROR: the associated type `<&'a V as IntoIterator>::Item` may not live long enough .into_iter() .map(|elem| elem.to_string()) .collect::<String>(); Ok(csv_str) } fn main() {} </ins>

Related discussion:
text: Playground: UPDATE: MCVE is here: Code: Crashes compiler with
Would be nice to figure out if this is a regression or not and if it is when has this regressed. ping cleanup
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
It has been present since at least 2019-08-01 according to bisect-rustc
Simplified code to remove dependencies This compiles for 1.20.0 and not for 1.30.0 (setting edition to 2015) I'll try and pinpoint at least the version where it causes the ICE
From what I can tell the first time this ICE would happen is in 1.24.0
Assigning
Even simpler:
Triage: This ICE has been fixed in the latest nightly, I assume it's fixed by . Marking as .
Wait, the original code and still triggers the ICE... glacier was tracking with but it seems the others encounter another roadblock. Dropping .
No longer ICEs since , likely from
Code change:
// check if the RHS is from desugaring let opt_assignment_rhs_span = self.body.find_assignments(local).first().map(|&location| { <del> let stmt = &self.body[location.block].statements [location.statement_index]; match stmt.kind { mir::StatementKind::Assign(box ( _, mir::Rvalue::Use(mir::Operand::Copy(place)), )) => { self.body.local_decls[place.local].source_info.span } _ => self.body.source_info(location).span, </del> <ins> if let Some(mir::Statement { source_info: _, kind: mir::StatementKind::Assign(box ( _, mir::Rvalue::Use(mir::Operand::Copy(place)), )), }) = self.body[location.block] .statements .get(location.statement_index) { self.body.local_decls[place.local].source_info.span } else { self.body.source_info(location).span </ins> } }); match opt_assignment_rhs_span.and_then(|s| s.desugaring_kind()) {

Related discussion:
text: <!-- 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. --: In case it helps, when using the stable toolchain, the compiler does not panic but instead emits this error: <!-- 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 --
Bisected to . CC searched nightlies: from nightly-2021-10-01 to nightly-2021-11-25 regressed nightly: nightly-2021-11-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details label regression-from-stable-to-nightly
I can fix this quickly -- seems like just changing an to a since the can be out of bounds. claim
(only tangentially related) I also noticed a regression in error spans between stable and beta... stable: beta:
That was an intentional change, meant to highlight the fact that the attempted mutable borrow is occurring because of the method call. However, it seems to be confusing for a lot of people, so I'll look into improving it.
Ah thanks for letting me know. Maybe we can split the span up into the receiver and the method, and add a note on the latter like "due to this method which takes &mut self". Not sure if that much info bubbles down into borrowck. I'd be interested in making that change if you've got a lot on your plate and it's (relatively) easy to do.
See for discussion about this exact idea. It'd be nice, but likely hard to implement.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Code change:
2) } <ins> // Indicate that we want CodeView debug information on MSVC if cx.sess().target.target.options.is_like_msvc { llvm::LLVMRustAddModuleFlag(cx.llmod(), "CodeView0".as_ptr() as *const _, 1) } </ins> // Prevent bitcode readers from deleting the debug info. let ptr = "Debug Info Version0".as_ptr(); llvm::LLVMRustAddModuleFlag(cx.llmod(), ptr as *const _,

Related discussion:
text: Symbol names are not properly supported yet on msvc, so backtraces are generally unhelpful. As a result, is currently disabled. This issue can be closed when it's been reenabled.
Code change:
if let ast::ExprKind::Await(_, _) | ast::ExprKind::Yield(_) = e.kind { ControlFlow::Break(()) } else { <del> visit::walk_expr(self, e); ControlFlow::Continue(()) </del> <ins> visit::walk_expr(self, e) </ins> } }

Related discussion:
text: searched nightlies: from nightly-2024-03-07 to nightly-2024-03-10 regressed nightly: nightly-2024-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.8</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
I suspect caused this regression, but I don't know how to use to test this pr(I tried some times but all failed). Do you have any ideas about this?
if you use the latest version of cargo-bisect-rustc it will bisect the roll-up for you.
Hi, I'm using the latest version of , but seems that it fails to bisect the roll-up. Here's the complete log: bash cargo bisect-rustc --start 2024-03-08 --end 2024-03-09 
It does bisect to for me. (With this visitor change in particular )
The fix has landed on master. Reopening to track beta backport.
Hi, 1.77.0 has been released, can this be backported to beta now?
I wasn’t at the weekly meeting and I don’t know for sure: is not yet marked as accepted for backport (it may just be an oversight in labeling, I’ll try to find out). Once that is done though, the release team, I believe, will backport it.
updated labels on (sorry for the delay)
That was backported in .
Code change:
self.rust_codegen_backends.get(0).cloned() } <ins> pub fn check_build_rustc_version(&self) { if self.dry_run() { return; } // check rustc version is same or lower with 1 apart from the building one let mut cmd = Command::new(&self.initial_rustc); cmd.arg("--version"); let rustc_output = output(&mut cmd) .lines() .next() .unwrap() .split(' ') .nth(1) .unwrap() .split('-') .next() .unwrap() .to_owned(); let rustc_version = Version::parse(&rustc_output.trim()).unwrap(); let source_version = Version::parse(&fs::read_to_string(self.src.join("src/version")).unwrap().trim()) .unwrap(); if !(source_version == rustc_version || (source_version.major == rustc_version.major && source_version.minor == rustc_version.minor + 1)) { let prev_version = format!("{}.{}.x", source_version.major, source_version.minor - 1); eprintln!( "Unexpected rustc version: {}, we should use {}/{} to build source with {}", rustc_version, prev_version, source_version, source_version ); crate::detail_exit(1); } } </ins> /// Returns the commit to download, or `None` if we shouldn't download CI artifacts. fn download_ci_rustc_commit(&self, download_rustc: Option<StringOrBool>) -> Option<String> { // If `download-rustc` is not set, default to rebuilding.

Related discussion:
text: building 1.68 with 1.69; we use deny-warnings in most cases and have no guarantees that unstable features will be the same between releases. Only building 1.68 with 1.67 or 1.68 should be allowed.
btw I've noticed you running into a few different bootstrap bugs the past few days — reading through https://rustc-dev- may or may not make it easier to diagnose these issues without having to spend ages interpreting the diagnostics. I'm also happy to chat about "how should this work" sorts of things .
Yes, I've read that. Thanks!
The error message could be improved though. Maybe one could make the to put into libcore/bootstrap's
I don't think rust-version is a good way to solve this, no - that won't give a warning or error if you use a future version to compile an older version. Also it won't be able to catch local-rebuild issues where the nightly version of the bootstrap compiler is too old. See my suggestion in
Hmm, I'm afraid I might have said something unclear. I'm not asking for forward compatibility in diagnostics. The feature was in version 1.68.0, according to , and I was using rustc version 1.68.2. So it should "know" about that feature, but my understanding is that when I was invoking rustc it was with flags that prevent unstable features from being used.
hmm, in that case something strange is going on because playground gives a much more reasonable error than the one you saw:
what commit of rustc were you trying to build when you got this error? I'm going to see if I can replicate it locally.
I was trying to build .
Ah ok, it was related to the context of the closure: If you look at the same gist with beta, the error message is much better: So I think this particular diagnostic issue has already been fixed. I still want to keep this issue open to track checking the version of the bootstrap compiler, though.
Code change:
LL | import std::{ | ^^^^^^ help: items are imported using the `use` keyword <ins> error: expected item, found `require` --> $DIR/use_instead_of_import.rs:9:1 | LL | require std::time::Duration; | ^^^^^^^ help: items are imported using the `use` keyword error: expected item, found `include` --> $DIR/use_instead_of_import.rs:12:1 | LL | include std::time::Instant; | ^^^^^^^ help: items are imported using the `use` keyword </ins> error: expected item, found `using` <del> --> $DIR/use_instead_of_import.rs:9:5 </del> <ins> --> $DIR/use_instead_of_import.rs:15:5 </ins> | LL | pub using std::io; |     ^^^^^ help: items are imported using the `use` keyword <del> error: aborting due to 2 previous errors </del> <ins> error: aborting due to 4 previous errors </ins>

Related discussion:
text: I was looking at namely issue when I thought about this. If work is being put into improving error messages when somebody uses a keyword that defines a function in another language, there should also be improved error messages if someone uses the incorrect directive to bring something into the scope of their module or namespace/ Given the following code: The current output is: The error message should preferably suggest the user to use the directive to bring something into scope of their module. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
For the record, on nightly, both and suggest using . I'm sure it's not that difficult to add .
ah. I was not aware of this. Less work to do then!
[Ignore this, just notes]
And also add ? Rust may go tooooo friendly in diagnostic message . Do you mind that I make a PR for it? I'm a newbie in hacking Rust compiler.
Sure! The earlier message should clarify where the edits are needed to be made. Ain't nothing as a diagnostic too friendly. =)
Remember to assign yourself using rustbot. Just a note for the future, usually if someone has already claimed an issue, it's not exactly common for someone else to fix it [aside from if the issue is abandoned by the claimee]. Since you're a newcomer here, I removed my assignment (and because I was working on another). However, you can find loads of easy issues with the E-Easy and/or E-Mentor tag for gaining experience. A few resources that might be helpful - Have fun hacking on Rust!
claim
Totally forgot about ! Good catch!
Code change:
ref s => { tcx.sess.span_bug( span, <del> format!("ty_region() invoked on in appropriate ty: {:?}", </del> <ins> format!("ty_region() invoked on an inappropriate ty: {:?}", </ins> s).as_slice()); } }

Related discussion:
text: Sorry for not providing smaller case but I hope this is better than nothing: Both versions works (compile and start), but runtime behavior changes. The code that follows the above part: will match no matter what really is, if the value is partially moved (so mouse events are updating my game). If I use the version with , the code works as intended and game is updated only on keyboard presses.
Minimal: This shouldn't compile at all.
Nominating.
Looks like a regression. 0.10 rejects this code.
Code change:
/// assert_eq!("GRüßE, JüRGEN ❤", s); /// ``` #[stable(feature = "ascii_methods_on_intrinsics", since = "1.23.0")] <del> #[rustc_const_unstable(feature = "const_make_ascii", issue = "130698")] </del> <ins> #[rustc_const_stable(feature = "const_make_ascii", since = "CURRENT_RUSTC_VERSION")] </ins> #[inline] <ins> #[cfg_attr(bootstrap, rustc_allow_const_fn_unstable(const_mut_refs))] </ins> pub const fn make_ascii_uppercase(&mut self) { // SAFETY: changing ASCII letters only does not invalidate UTF-8. let me = unsafe { self.as_bytes_mut() };

Related discussion:
text: Feature gate: This is a tracking issue for marking the and methods in , , , and as "const." [x] Implementation for : [x] Implementation for : [x] Implementation for and : [x] Final comment period (FCP) [x] Stabilization PRNone yet.
fcp merge / have been stable in const since 1.52. / are unblocked now by the stabilization of
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
Can the methods be included in this? Similarly const stable / since 1.52.
Yes, that sounds like a good idea. I'll try adding another PR later.
:bell: This is now entering its final comment period, as per the . :bell:
stabilises this.
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
Code change:
#[stable(feature = "rust1", since = "1.0.0")] #[inline] pub fn len_utf8(self) -> usize { <del> let code = self as u32; if code < MAX_ONE_B { 1 } else if code < MAX_TWO_B { 2 } else if code < MAX_THREE_B { 3 } else { 4 } </del> <ins> len_utf8(self as u32) </ins> } /// Returns the number of 16-bit code units this `char` would need if

Related discussion:
text: The following program causes UB: Miri says: The problem is this code: This calls unless the new code point is in , but what about surrogates in ? This code is unchanged since its introduction in I am not sure what the intended safety contract of is. That method is not marked but clearly should be -- it calls . So my guess is the safety precondition is that must not be part of a surrogate pair, but the thing is, calls it without actually ensuring that condition. The condition it does ensure is that the codepoint is not in , but that does not help.
is excluded from Unicode scalar values a.k.a. , but it’s fine as a Unicode code point. I think this bug is not in the contract of (which is private anyway) but in its implementation, namely going through . The fix is to either duplicate the logic of into , or (to avoid duplication) move that logic to a new function in libcore that takes a parameter and that is called by both and . This function would need to be public because is in a different crate, but it should be prema-unstable and .
I would classify the priority of this bug as low. Although this call to is UB, I expect Miri checking for it explicitly is the only case where that has any consequence in today’s implementation: behaves as expected (for the purpose of WTF-8) in the surrogate range and does not exploit this UB The "layout" of in rustc excludes values beyond but not surrogates:
By the way, the docs at feel insufficient: Which values are invalid? Similarly, and say that represents Unicode Scalar values, but I couldn’t find it documented anywhere that constructing an out of range is Undefined Behavior rather than "merely" a logic bug. Is this specified elsewhere? What is the closest we have to a written down normative resource that specifies what is or isn’t UB in the the Rust language? (For APIs I assume this is the responsibility of their respective doc-comments.)
I agree the impact is low, but it's not just Miri -- this blocks , which is how I discovered the problem. That would be
But then what is "unchecked" about it? Elsewhere in that file the code is careful not to construct a from a without checking for surrogates: That made me assume the author was aware that surrogates in are UB.
Code change:
#[stable(feature = "rust1", since = "1.0.0")] #[inline] pub fn len_utf8(self) -> usize { <del> let code = self as u32; if code < MAX_ONE_B { 1 } else if code < MAX_TWO_B { 2 } else if code < MAX_THREE_B { 3 } else { 4 } </del> <ins> len_utf8(self as u32) </ins> } /// Returns the number of 16-bit code units this `char` would need if

Related discussion:
text: The type contains a (generalized-UTF-8-encoded) sequence of code point (including potentially surrogates) that doesn’t form a surrogate pair. doesn’t check for surrogate pairs. is a public method that is documented as returning a scalar value, therefore excluding all surrogates. Ok I looked into it, there are three different people involved. The original code in 2014 was YOLO Later in 2014, moved to duplicating logic instead. In 2015, PR which first imported WTF-8 support in libstd deduplicated that logic by adding a function that takes . (I knew that approach sounded familiar…) In 2016, PR changed the signature of and in passing removed . It made use + instead, presumably in the middle of updating many callers other.
Okay, so the fix would be to revert the part of that removed ?
That or copy into . I find them both not great, so meh.
Even with that done, there's still UB in another testcase: This is converting something to a before calling -- so probably the same issue as the above, just for a different encoding.