jiebi/CodeConvo huggingface dataset:
Code change:
lazy_state: LazyState::NoNode, type_shorthands: Default::default(), predicate_shorthands: Default::default(), <del> } .encode_crate_root(); </del> <ins> }; // Encode the rustc version string in a predictable location. rustc_version().encode(&mut ecx).unwrap(); // Encode all the entries and extra information in the crate, // culminating in the `CrateRoot` which points to all of it. ecx.encode_crate_root() }; </ins> let mut result = cursor.into_inner(); // Encode the root position.

Related discussion:
text: thread 'rustc' panicked at 'index out of bounds: the len is but the index is ', ../src/libserialize kind of expected, after switching toolchain from 1.15 back to 1.14. cargo clean && cargo build "repaired it"
Do you have some more information on how to reproduce this?
I hit this compiling hyper with 1.13 stable.
Which version of hyper is that? I can't reproduce with latest .
It was with master. I tried and now it works. So rustc/cargo were using libs compiled when I tried this with 1.15nightly?
Sounds a bit like cargo was re-using libraries that it should have re-compiled because the compiler has changed. cc
Sorry if I did not save the full backtrace - It was my first issue report. I switched away from 1.15 nightly back to 1.14 nightly in order to solve a serde macro issue. Cargo cleaning and rebuilding fixed the issue. I will make sure to run again and capture the output if it happens again. On 11/16/2016 4:54 PM, Michael Woerister wrote:
Sounds suspiciously like a Cargo bug! If there's a reproduction I'd be more than willing to dig in.
I believe I just reproduced this in Cargo itself: When executing with the last few lines are: So what's happening here is: is populating the entire crate cache with a bunch of libraries on the nightly compiler. switching compilers, Cargo decides to recompile everything. doesn't delete everything as it recompiles, rather incrementally builds up a new crate cache compiler, given to that directory, will read crates in that directory. compiler panics when reading a crate compiled by a future compiler. So I take back what I said earlier about this likely being a Cargo bug, it seems like this may be a bug in the compiler trying to read stale metadata? I thought we had like 10 checks in place to ensure we didn't do that, but maybe it's still leaking through?
I'm going to tag this as a stable-to-nightly regression as this appears to have been introduced in nightly. If I build cargo with beta and then switch to beta, the compiler doesn't ICE.
The panic on stable happens in we check version information. Did we change how we encode version information?
Code change:
lazy_state: LazyState::NoNode, type_shorthands: Default::default(), predicate_shorthands: Default::default(), <del> } .encode_crate_root(); </del> <ins> }; // Encode the rustc version string in a predictable location. rustc_version().encode(&mut ecx).unwrap(); // Encode all the entries and extra information in the crate, // culminating in the `CrateRoot` which points to all of it. ecx.encode_crate_root() }; </ins> let mut result = cursor.into_inner(); // Encode the root position.

Related discussion:
text: cc
I incremented the header version number though... It should be impossible for older rustc to get that far.
on it looks the same on . Perhaps we just need a PR to bump that?
Oh it looks like my changes have reached stable. I wonder if perhaps the is in a precarious spot and/or has been moved or the serialization otherwise changed. This requires further investigation.
Why is this even calling leb128? Are we using variable-length integers in the metadata header?
I assumed leb128 was the crate being built, not one used by the compiler.
Sure enough. Now every change to requires us to update the LLVM version number, because checking the rustc version number requires parsing . I think we should go back to JSON version guard.
Ahh that's what it was. We can put it at the start then, before/after the absolute address. I'd forgotten that the whole struct would have to be decoded.
What was the PR that modified the versioning scheme? I gather that something has changed about it. Can somebody explain more clearly what is going wrong here?
I mistakenly put the version string inside a larger , somehow thinking that it being at the start helped, but if the whole (that is, ) can't be decoded (e.g. because its definition changed) then you don't get to see the version string, whereas before it was separate. The fix would be to separate it again, put it back at the start and leave it there. Or just encode/decode it before instead of as part of it. Either will work as long as it can't be affected by changes to the metadata schema. The PR that introduced the new schema was , although breakage didn't happen until changed later, for procedural macros and/or the name resolution changes ( would know).
removed the field from for macro modularization.
I believe I have a fix ready. Does this affect beta too now, or just nightly?
AFAIK it's just nightly, not beta or stable
Code change:
/// /// assert_eq!("GRüßE, JüRGEN ❤", s); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> #[inline] pub fn make_ascii_uppercase(&mut self) { self.inner.make_ascii_uppercase()

Related discussion:
text: <!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilization. Make sure to include the relevant RFC for the feature if it has one. If the new feature is small, it may be fine to skip the RFC process. In that case, you can use use in your initial implementation PR. The reviewer will ask you to open a tracking issue if they agree your feature can be without an RFC. --Feature gate: <!-- For most library features, it'd be useful to include a summarized version of the public API. (E.g. just the public function signatures without their doc comments or implementation.) --<!-- For larger features, more steps might be involved. If the feature is changed later, please add those PRs here as well. --- [x] - Stabilized traits necessary to obtain [x] - Added ASCII methods on [x] Final commenting period (FCP) [x] - Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final commenting period (FCP) is always needed before stabilization. This works as follows: A library team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final commenting period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Just needed to manipulate paths on windows -- I need to lower case driver letter, -.
Currently, SQLx contains The UTF-8 check that is included in there, while not a problem in practice, seems pointless. Changing to lands me here because of the .
Code change:
/// /// assert_eq!("GRüßE, JüRGEN ❤", s); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> #[inline] pub fn make_ascii_uppercase(&mut self) { self.inner.make_ascii_uppercase()

Related discussion:
text: Also, if somebody did a similar thing with instead of , the version could drop that and would then be a bit less noisy.
is a stabilization PR. Since lib team wants to do fcp in the tracking issue. could you start one ?
merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [x] [ ] Concerns: resolved by 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.
Slight question about -- normally when dealing with AsRef args, they come in without an explicit reference in the signature (), except when necessary to support a lifetime in the return value (). Currently is declared as: Is this supposed to be instead? concern eqignoreasciicase &amp;S
I think it should be. I'm not sure why I wrote it like I did originally, but this makes more sense to me. I can make that PR if needed. Or can it be done in the stabilization PR? Not sure what the process is from here.
resolve eqignoreascii_case &amp;S reviewed Fixed in .
:bell: This is now entering its final comment period, as per the . :bell:
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. The RFC will be merged soon.
you can tick the FCP box, as the FCP is complete.
Code change:
ascription: thir::Ascription { variance, user_ty, user_ty_span }, } => { // Apply the type ascription to the value at `match_pair.place`, which is the <del> candidate.ascriptions.push(Ascription { span: user_ty_span, user_ty, source: match_pair.place.clone().into_place(self.tcx, self.typeck_results), variance, }); </del> <ins> if let Ok(place_resolved) = match_pair.place.clone().try_upvars_resolved(self.tcx, self.typeck_results) { candidate.ascriptions.push(Ascription { span: user_ty_span, user_ty, source: place_resolved.into_place(self.tcx, self.typeck_results), variance, }); } </ins> candidate.match_pairs.push(MatchPair::new(match_pair.place, subpattern));

Related discussion:
text: Encountered an ICE when building  0.18.0 on edition 2021. I have roughly narrowed it down to the following (can probably be reduced further). Seems to be an issue with closure captures. <!-- 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</detailscc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The code can be further simplified to: The issue seems to be around using type annotation. If a type annotation is included, the right hand side of the let statement should always be read.
Is there a runtime check/ is MIR generated for checking if is valid? Because if that's the case then we need props2 to be caputred.
claim I should have a fix later tonight
We found another instance of this ICE that still fails with included: Found trying to migrate . Let me know if you need any more information.
Code change:
/// assert_eq!(*guard, 1); /// ``` #[inline] <del> #[unstable(feature = "mutex_unpoison", issue = "96469")] </del> <ins> #[stable(feature = "mutex_unpoison", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn clear_poison(&self) { self.poison.clear(); }

Related discussion:
text: Feature gate: This is a tracking issue for functions to clear the poisoned flag on and . [x] [x] Implementation: [x] Final comment period (FCP) [ ] Stabilization PR <!-- Once the feature has gone through a few release cycles and there are no unresolved questions left, the feature might be ready for stabilization. If this feature didn't go through the RFC process, a final comment period (FCP) is always needed before stabilization. This works as follows: A library API team member can kick off the stabilization process, at which point the rfcbot will ask all the team members to verify they agree with stabilization. Once enough members agree and there are no concerns, the final comment period begins: this issue will be marked as such and will be listed in the next This Week in Rust newsletter. If no blocking concerns are raised in that period of 10 days, a stabilzation PR can be opened by anyone. --<!-- Include any open questions that need to be answered before the feature can be stabilised. If multiple (unrelated) big questions come up, it can be a good idea to open a separate issue for each, to make it easier to keep track of the discussions. It's useful to link any relevant discussions and conclusions (whether on GitHub, Zulip, or the internals forum) here. --- None yet.
Hi, I read (wich got automatically closed by the way) and the PR It seems all good. What is the next step to make it in the stable API ? Can I help somehow ?
Hi, sorry if flooding but are there any updates regarding this issue?
I think the next step is one of the rust developers needs to start the final comment period. IDK what the criteria for doing so are.
fcp merge
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.
I was wondering whether the idea of had been considered and found that addressed it. SGTM!
Code change:
/// assert_eq!(*guard, 1); /// ``` #[inline] <del> #[unstable(feature = "mutex_unpoison", issue = "96469")] </del> <ins> #[stable(feature = "mutex_unpoison", since = "CURRENT_RUSTC_VERSION")] </ins> pub fn clear_poison(&self) { self.poison.clear(); }

Related discussion:
text: :bell: This is now entering its final comment period, as per the . :bell:
Given the state change this method causes, I am curious about rationale behind using vs ?
If it took , it wouldn't be possible to unpoison a mutex shared between threads despite that being the main case where poisoning can happen.
I just want to add that probably before stabilizing this method we should implement a lint which catches invalid patterns of using these methods since it is very easy to misuse. Or, at the very least, include information about potential footgun in documentation for these methods.
What kind of lint do you exactly want? What are the patterns in question that you are worried about?
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.
exactly the possible error outlined by Mara Bos: calling before acquiring a lock. The only way this usage is correct is when no other thread can act on mutex - either because they don't exist or because they are all blocked on something else. I believe that these situations are rare enough to flag such a pattern as at least suspicious.
If unpoison was a method of PoisonError or of MutexGuard instead of mutex, would it prevent such problems?
That was discussed here:
Code change:
}; append_arg(&mut cmd, arg, quote)?; } <ins> if is_batch_file { cmd.push(b'"' as u16); } </ins> return Ok(cmd); fn append_arg(cmd: &mut Vec<u16>, arg: &OsStr, quote: Quote) -> io::Result<()> {

Related discussion:
text: I tried this code: I expected to see this happen: Instead, this happened: This is caused by different quote handling. The first (correct) command line for the spawned process (as observed by ) is: The broken one is: The command for must be in additional set of quotes, as the first and last one are stripped. It works when there are no spaces in the arguments due to the exception rule, see Stable. It worked up until nightly-2021-11-20 nightly-2021-11-21 modify labels: +regression-from-stable-to-nightly -regression-untriaged
This is caused by Rust now handling finding the exe to run itself (for security reasons). The fix here would be. as you say, to detect or extensions and add the extra quotes. The underlying function call here is . As the documentation says, this can only be used to run files. However, an undocumented feature of is that it will do this for us if given a or file. Previously we used to leave the argument blank and let it guess the right application from the argument. So apparently it would fill in for the application name and add plus the extra quotes to . But now that we do fill in the ourselves, it will still change to and add to but evidentially doesn't add the extra quotes. Thus we need to do this ourselves.
That seems reasonable; could you or someone on the Windows team submit a PR adding the requisite quoting (since quoting is hard to get right)?
Oops, sorry! I had a PR lined up but forgot to submit.
Code change:
<ins> // check-pass #![feature(type_alias_impl_trait)] pub trait Trait { type A; fn f() -> Self::A; } pub trait Tr2<'a, 'b> {} pub struct A<T>(T); pub trait Tr { type B; } impl<'a, 'b, T: Tr<B = dyn Tr2<'a, 'b>>> Trait for A<T> { type A = impl core::fmt::Debug; fn f() -> Self::A {} } fn main() {} </ins>

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. --Playground stable: Playground nightly: Somewhat similar to Edit: Actually, it's identical except this is with two lifetimes. Edit 2: And this one crashes stable, while the other does not. Also crashes without enabling features, and complains that However, constraining removes this error, but not the crash. Two lifetimes are required for the crash. <!-- 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. --: Also crashes on Rust Playground with stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
Seems related to
No longer ICEs since
Code change:
name: Symbol, ) -> Result<Self, &'static str> { // FIXME: use direct symbol comparison for register names <del> name.with(|name| { Ok(match arch { InlineAsmArch::X86 | InlineAsmArch::X86_64 => { Self::X86(X86InlineAsmReg::parse(arch, has_feature, name)?) } InlineAsmArch::Arm => Self::Arm(ArmInlineAsmReg::parse(arch, has_feature, name)?), InlineAsmArch::AArch64 => { Self::AArch64(AArch64InlineAsmReg::parse(arch, has_feature, name)?) } InlineAsmArch::RiscV32 | InlineAsmArch::RiscV64 => { Self::RiscV(RiscVInlineAsmReg::parse(arch, has_feature, name)?) } }) </del> <ins> // Use `Symbol::as_str` instead of `Symbol::with` here because `has_feature` may access `Symbol`. let name = name.as_str(); Ok(match arch { InlineAsmArch::X86 | InlineAsmArch::X86_64 => { Self::X86(X86InlineAsmReg::parse(arch, has_feature, &name)?) } InlineAsmArch::Arm => Self::Arm(ArmInlineAsmReg::parse(arch, has_feature, &name)?), InlineAsmArch::AArch64 => { Self::AArch64(AArch64InlineAsmReg::parse(arch, has_feature, &name)?) } InlineAsmArch::RiscV32 | InlineAsmArch::RiscV64 => { Self::RiscV(RiscVInlineAsmReg::parse(arch, has_feature, &name)?) } </ins> }) }

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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
modify labels to +A-inline-assembly +F-asm +requires-nightly +O-riscv
Interestingly this does not reproduce when change register names to x86 ones; a error will be generated correctly.
I think I've located the issue. claim
claim
Code change:
} } <ins> // FIXME: This has the same issue as #108544, but since this isn't breaking // existing code, I'm not particularly inclined to do the same hack as above // where we process wf obligations manually. This can be fixed in a forward- // compatible way later. let collected_types = collector.types; for (_, &(ty, _)) in &collected_types { ocx.register_obligation(traits::Obligation::new( tcx, misc_cause.clone(), param_env, ty::ClauseKind::WellFormed(ty.into()), )); } </ins> // Check that all obligations are satisfied by the implementation's // RPITs. let errors = ocx.select_all_or_error();

Related discussion:
text: This is a use-after-free that compiles with 1.74.0-nightly (2023-09-13 ): cc
Code change:
self.suggest_derive(err, &preds); } <del> fn suggest_derive( </del> <ins> pub fn suggest_derive( </ins> &self, err: &mut Diagnostic, unsatisfied_predicates: &[(

Related discussion:
text: This gives the very unintuitive error: You expect to return , i.e. a . It mysteriously returns an instead. Because has a clone impl, it too, can be cloned (really, copied), returning a reference of the same lifetime. This is an operation you rarely want to do explicitly, except when dealing with generics. This error can crop up when you've forgotten to implement on , and have a reference (which could have been silently inserted using , as in the code above). However, it's not very obvious what's happening here. It can also crop up We should hint that itself isn't cloneable and thus we fell back to cloning here. This could be a lint on hitting the clone impl for references, but lints run too late. I'm not sure how this can be implemented, since we need to see the source of a value and that's a bit tricky.
cc
Interesting. This does seem like it would require some pretty special-case code to achieve, but I agree it'd be a nice case to capture.
A relatively easy way to catch most instances of this is to Pick up the expression which has a type error like this If it is a method call, check if that method call is a clone() call resolving to If it is a variable, find the variable's def If the def is a local def, look at the init expr, check if it's a bad clone This will miss things, but I think the majority of such bugs will be due to this. As it stands this feels like an incredibly easy case to hit (we've all forgotten to decorate structs).
cc
CC
As reported in : This reports:
Current output is even worse for the original report: The last comment's code is marginally different:
Current output: The last case should suggest constraining . Edit: that was easier than I thought (we already had the suggestion machinery): <img width="511" alt="Screen Shot 2022-12-13 at 6 41 23 PM" src="https://user-"