jiebi/CodeConvo huggingface dataset:
Code change:
cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo

Related discussion:
text: See also
The proper way to fix this is to wipe the build cache whenever the stage1 compiler changes. That will make builds a lot slower, but it's better than ICEs and having to wipe the cache anyway. I guess we could add a --keep-stage1-cache flag if you're sure you haven't touched metadata - not sure how useful it would be in practice. said on Zulip:
Wait, I'm confused again. Why does the metadata matter other than the incremental cache? Cargo already invalidates the cache when is modified, which is why libstd gets rebuilt when you modify the compiler. Is there anyone not using that's been hitting this issue?
I found while working on that this is not true: if you use --keep-stage-std 1, cargo will blithely keep the cache for all crates in build/stage1-rustc, without rebuilding. Copying over my comment from
Another possible fix is to make rebuilding after a commit cheap enough that we can include the hash unconditionally. Right now it's used in rustcsession; if we move it to rustcdriver, that would only need to relink the .so and recompile the final rustdoc/clippy/miri crates, not their dependencies. I guess it means we'd have to suggest using keep-stage-std more often :/ but people are doing that pretty frequently already.
Oh, and it has the downside that if you're testing the project on external crates cargo will recompile them after every commit. Maybe that's a good thing?
The only time it won't fully fix the issue is when you're modifying rustc_metadata or similar and don't make a commit between builds. I'm ok with not fixing that case, because anyone working on metadata is much more likely to understand what went happened and how to work around it than random contributors stumbling into this for the first time.
hit this issue this morning with incremental disabled, so it's relevant to all metadata loading, not just incremental.
Thanks for pointing me to the right issue. Following Tried some commits from the past few days Would it be useful to keep going with this approach? Oh, and this is with .
That's helpful, thanks! No need to find more commits, having a reproducer at all is already very useful.
This fundamental issue doesn't just apply to bootstrap, right?
Code change:
cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo

Related discussion:
text: If one uses a locally built toolchain to build some crates, and then updates the toolchain, the same ICEs can arise (because the dependency rlibs will now be in the wrong format). Bootstrap is just where people run into it most often. But a solution inside bootstrap won't fix the fundamental issue. (E.g., it won't fix the Miri version of this problem, which got reported at )
Yes, that's right, any two toolchains that were built from different sources but have the same version string will have this problem (this is why we set a custom description by default in the source tarballs, so they won't reuse metadata from the official toolchain). Removing or defaulting it to would work for miri though, or at least make it so that you have to try a lot harder to run into the bug (e.g. twice with different local changes that haven't been committed).
A more "principled" fix would be to have something like a metadata version number embedded in the files that contributors are responsible for updating when the format changes. But I worry people will forget to update it, the same way people often forget to bump and that causes caching issues:
oh right, and suggested adding incremental to dep-info: but given that this bug is also showing up for metadata, not just incremental, I suspect that's not a complete fix:
Yeah, if we could somehow ensure that such a version number is always correct it would be a proper fix but manual bumping probably won't work. Unless we find a way to at least have CI fail when one forgets to bump...
reported seeing these crashes for , not just for tools and stage 1 rustc. I think he's running into this line being buggy: that shouldn't filter only to build, nearly all the commands read metadata and need the same treatment. Not making a PR because I don't have a test case yet, but if anyone comes up with an MCVE that makes crash, I'd be interested to see if this diff fixes it: also, I wonder if we could fix the original problem with metadata/incremental in stage 1 by applying clearifdirty to rustc too:
reproducer unfortunately gives me a different ICE than the one in the linked issue; it's for stage0, not stage1. So I can't use it to test my diff.
Code change:
cargo.env("RUSTC_TLS_MODEL_INITIAL_EXEC", "1"); } <del> if self.config.incremental { </del> <ins> // Ignore incremental modes except for stage0, since we're // not guaranteeing correctness across builds if the compiler // is changing under your feet. if self.config.incremental && compiler.stage == 0 { </ins> cargo.env("CARGO_INCREMENTAL", "1"); } else { // Don't rely on any default setting for incr. comp. in Cargo

Related discussion:
text: a while ago found that reproduced the issue; if someone could run that both with and without my diff applied to see if it makes a difference that would be helpful; I'm out of time for today.
Code change:
StorageLive(_3);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:15 StorageLive(_4);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:6 _4 = &mut (*_1);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:6 <del> _3 = move _4;                    // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL </del> <ins> StorageLive(_5);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL _5 = &mut (*_4);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL _3 = &mut (*_5);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL StorageDead(_5);                 // scope 1 at $SRC_DIR/libcore/convert/mod.rs:LL:COL </ins> _2 = &mut (*_3);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:15 StorageDead(_4);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:14: 3:15 _0 = &mut (*_2);                 // scope 0 at $DIR/issue-58867-inline-as-ref-as-mut.rs:3:5: 3:15

Related discussion:
text: Since InstCombine can now introduce where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by the dataflow, but still be used in that uninitialized state. If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet. This impacts , which does run after InstCombine and relies on the dataflow. I've observed this on , where it produces this diff: The second use of occurs despite the first move deinitializing the local. cc
Maybe we should stop making instcombine convert to ? This could be done in the pre-codegen cleanups, but for MIR it is wrong to use or on such values in general. Alternatively instcombine needs to start using dataflow to only insert moves when the site is the last use of the local.
Code change:
/// Cancel the diagnostic (a structured diagnostic must either be emitted or /// canceled or it will panic when dropped). <del> /// BEWARE: if this DiagnosticBuilder is an error, then creating it will /// bump the error count on the Handler and canceling it won't undo that. /// If you want to decrement the error count you should use `Handler::cancel`. </del> pub fn cancel(&mut self) { self.level = Level::Cancelled; }

Related discussion:
text: Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?
Code change:
let expn_data = prefix_span.ctxt().outer_expn_data(); if expn_data.edition >= Edition::Edition2021 { <del> let mut silence = false; </del> // In Rust 2021, this is a hard error. let sugg = if prefix == "rb" { Some(errors::UnknownPrefixSugg::UseBr(prefix_span))

Related discussion:
text: <!-- [31mICE[0m: Rustc '--edition=2021 --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: prefix is unknown', 'error: internal compiler error: prefix is unknown' File: --snippet: 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: --
:thinking: this bisects to cc
very plausible :+1:
Reduced
Code 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. #![crate_type="lib"] pub trait Trait { // the issue is sensitive to interning order - so use names // unlikely to appear in libstd. type Issue25467FooT; type Issue25467BarT; } pub type Object = Option<Box<Trait<Issue25467FooT=(),Issue25467BarT=()>>>; </ins>

Related discussion:
text: It looks like if you go and grab this commit of timely-dataflow from github, you get a nicely reproducible ICE. TravisCI gets it too! In case anything changes in the meantime, the commit you want is Related issues: . The times I've seen this before I haven't be able to reproduce it, but since it seems to happen from a clean pull, I thought I would show you. To repro, just follow the commands here. git clone, cargo build, cargo test. Boom!
It seems like I can make the ICE go away by replacing a member variable with one that uses an equivalent trait which doesn't use associated types: Swapping that in removes the ICE, swapping it out brings the ICE back. So, maybe something isn't working great for boxed traits with associated types. The commit that fixes things is
Doing some testing, and the repro in (not mine) is way simpler. It also explodes on 1.1 stable, with a similar complaint. Just boxing a trait with two associated types.
I run into this problem, too (with stable ).
Code 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. #![crate_type="lib"] pub trait Trait { // the issue is sensitive to interning order - so use names // unlikely to appear in libstd. type Issue25467FooT; type Issue25467BarT; } pub type Object = Option<Box<Trait<Issue25467FooT=(),Issue25467BarT=()>>>; </ins>

Related discussion:
text: Hi, I ran into an interesting ICE while working on a personal project. This seems like it could be related to issues or , but I'm not sure. I set up a . The README includes a description of the bug and the compiler backtrace.
Getting the same ICE occasionally in (At more specifically, not minimized because I don't think I can produce a smaller example than the package above).
This is a somewhat flaky ICE I used to see a bunch back in April, but it seemed like it sorted itself out with the 1.0. I've found it again! It is on stable 1.1, so I thought I would bump this post 1.0 issue rather than my open pre-1.0 issues. I'm really not sure what causes this, but the common features tend to be doing a bunch of builds with light changes to a local crate (path="...") on which the project depends (in this case, local edits to the timely crate). It feels a lot like it is Cargo getting just a bit confused about what has changed and what hasn't, as will sometimes fix the problem. Previously, toggling LTO would tickle/untickle the bug, as would insisting on some inlining. Just now, fixed it up, after would not... Maybe someone should just put a on the bounds list... =/
Code change:
for autoderefs in range(0, fcx.tcx().sess.recursion_limit.get()) { let resolved_t = structurally_resolved_type(fcx, sp, t); <ins> if ty::type_is_bot(resolved_t) { return (resolved_t, autoderefs, None); } </ins> match should_stop(resolved_t, autoderefs) { Some(x) => return (resolved_t, autoderefs, Some(x)), None => {}

Related discussion:
text: Taking a look.
Probably the best fix for now is to disallow deref of outright. I'll work up a PR that fixes this and a few other ICEs surrounding .
This is fixed with a test, closing.
Code change:
<ins> // Check that `async fn` inside of an impl with `'_` // in the header compiles correctly. // // Regression test for #63500. // // check-pass // edition:2018 #![feature(async_await)] struct Foo<'a>(&'a u8); impl Foo<'_> { async fn bar() {} } fn main() { } </ins>

Related discussion:
text: The diagnostics ("use of undeclared lifetime name") are bad, but this indeed must be an error because the inner is an illegal use of the outer rather than an implicitly defined fresh lifetime.
Hm, I don't think that's quite what I'd expect: previously using in that context would be fine because there is no shadowing so to speak, that is, this compiles:
From Similarly, if a fn definition is nested inside another fn definition, it is an error to mention lifetimes from that outer definition (without binding them explicitly). This is again intended for future-proofing and clarity, and is an edge case. (In the second example there's an explicit definition that shadows the previous definition for following uses, in the first example there's no second definition, only use)
I see that this is in the RFC, but I think I more or less disagree with the reasoning given. Disallowing the use of inband lifetimes when nesting function seems arbitrary and not entirely helpful; it also makes a mechanical change from "old" to "new" more difficult because shadowing is visible only based on indent levels.
IMO it should be an error, with a helpful note like the one you get when writing . Let's not make in-band lifetimes any more confusing than they already are.
The distinction is that inband lifetime's selling point is that you don't need to declare lifetimes. If we say that, and then clarify it with "except" then I think the feature feels incomplete. Inband lifetimes confusion does not increase with permitting this, IMO.
The problem is if it's allowed, then has a different meaning than This seems unfortunate and confusing. Even unergonomic if I may say so. There's no way that the distinction between and won't be missed in a quick scan of the second one. But, like, the RFC process did decide that isn't important, so whatever.
Well, somewhat, but not really. Nothing outside of imports/definitions inherits into the inner function, unlike the impl where there is a history and multiple things which inherit (, lifetimes, generics).
Code change:
#[inline] #[must_use] #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_transmute_copy", issue = "83165")] </del> <ins> #[rustc_const_stable(feature = "const_transmute_copy", since = "CURRENT_RUSTC_VERSION")] </ins> pub const unsafe fn transmute_copy<Src, Dst>(src: &Src) -> Dst { assert!( size_of::<Src>() >= size_of::<Dst>(),

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: This is a tracking issue for making the function . <!-- Include a short description of the feature. --<!-- 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] Implementation: [ ] Final commenting 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 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.
This got reverted again by , but hopefully we can re-land it soon.
Sorry, I misread, this feature gate is not affected (but some others are).
Any news on this?
Code change:
#[inline] #[must_use] #[stable(feature = "rust1", since = "1.0.0")] <del> #[rustc_const_unstable(feature = "const_transmute_copy", issue = "83165")] </del> <ins> #[rustc_const_stable(feature = "const_transmute_copy", since = "CURRENT_RUSTC_VERSION")] </ins> pub const unsafe fn transmute_copy<Src, Dst>(src: &Src) -> Dst { assert!( size_of::<Src>() >= size_of::<Dst>(),

Related discussion:
text: I don't see anything holding it back; especially now that transmute itself is const. EDIT: Never mind, I just saw
Since is const-stable nowadays, I think this can be stabilized as well. Feel free to open a PR. :) Cc
I didn't do this before, I am reading the docs for how to do this, and there's an rfcbot final commenting period thing. Should this be done? If yes, how? I probably don't have the rights to do it.
You just need to prepare a PR. I can help get the FCP process started in the PR.
Code change:
/// assert!(ascii.is_ascii()); /// assert!(!non_ascii.is_ascii()); /// ``` <del> #[unstable(feature = "osstring_ascii", issue = "70516")] </del> <ins> #[stable(feature = "osstring_ascii", since = "1.53.0")] </ins> #[inline] pub fn is_ascii(&self) -> bool { self.inner.is_ascii()

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 .