jiebi/CodeConvo huggingface dataset:
Change:
use rustc_hir::def_id::DefId; use rustc_middle::ty::layout::LayoutOf; use rustc_middle::ty::{self, DefIdTree, Ty}; <del> use rustc_target::abi::VariantIdx; </del> <ins> use rustc_target::abi::Variants; </ins> use crate::common::CodegenCx; use crate::llvm;

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. --code from <!-- 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 It looks like this might be related to
reports that this is regression in (which is indeed in PR ).
reports in zulip that this test case fails at that same injection point when combined with (aka ): ./src/test/run-pass-valgrind/dst-dtor-4.rs : <details<summaryContent of above file</summary</details
Files that reproduce the ice one way or another with : `
Thanks for the bug report, I'll look into it.
Looks like this should be an easy fix. The code just doesn't expect tuples to be unsized (which of course it should).
Change:
<ins> error: unexpected token: `...` --> $DIR/issue-96335.rs:2:6 | LL |     0.....{loop{}1}; |      ^^^ | help: use `..` for an exclusive range | LL |     0....{loop{}1}; |      ~~ help: or `..=` for an inclusive range | LL |     0..=..{loop{}1}; |      ~~~ error[E0308]: mismatched types --> $DIR/issue-96335.rs:2:9 | LL |     0.....{loop{}1}; |     ----^^^^^^^^^^^ |     |   | |     |   expected integer, found struct `RangeTo` |     arguments to this function are incorrect | = note: expected type `{integer}` found struct `RangeTo<{integer}>` note: associated function defined here --> $SRC_DIR/core/src/ops/range.rs:LL:COL | LL |     pub const fn new(start: Idx, end: Idx) -> Self { |                  ^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after reporting some other errors, so I guess low priority. Affected versions: nightly 2022-04-22 does show the ICE, but beta 1.61.0-beta.3 does not show the ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-04-22 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
A invocation should be replaced by and producing an error type as the adjustment result
I think this is still open and it looks like a fun problem to dig into. Please let me know if I should let someone else work on it though please! claim
I also found this issue in that version's nightly rustc. I consider that is a nontrival problem worth digging into.
I have opened a PR () that I believe addresses the ICE. I think I pretty much implemented what Oli described, but I'm a little unclear as to whether this is the actual solution or is the fact that there's an adjustment on a never type at all the real bug? I also wasn't able to reduce the minimal error case much beyond what Badel2 posted. Do you happen to have a simpler error case, Peter?
I'm assigned to your PR, and looked into this issue really quickly. So this is due to the new argument type compatibility algorithm implemented in (cc: The after  has been called once before during the "good" path of . This is somewhat problematic, since this means that typeck code deeper in the stack attemps to apply adjustments twice and sometimes panicks because of this. A similar bug was fixed in when other diagnostic code called several times on a bad path.

Since this will only reasonably happen during diagnostic code, I think it's fine for now to delay a bug.
Thank you for the background! That helps a lot to clarify things. I clearly need to do a lot more reading.
Yeah, I also just have a simple ICE from rustc. But there has been some expositions from , so I think maybe this issue would be solved in the future.
Change:
<ins> error[E0499]: cannot borrow `foo` as mutable more than once at a time --> $DIR/two-phase-multi-mut.rs:23:16 | LL |     foo.method(&mut foo); |     -----------^^^^^^^^- |     |          | |     |          second mutable borrow occurs here |     first mutable borrow occurs here |     borrow later used here error[E0499]: cannot borrow `foo` as mutable more than once at a time --> $DIR/two-phase-multi-mut.rs:23:5 | LL |     foo.method(&mut foo); |     ^^^^^^^^^^^--------^ |     |          | |     |          first mutable borrow occurs here |     second mutable borrow occurs here |     borrow later used here error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0499`. </ins>

Discussion:
This program : See also , which I believe to be relevant. I'm refactoring some of this code, trying to explore the new NLL approach, so I will probably wind up fixing this. But obviously we should have this as a test! cc
Is this similar to this ICE?
Change:
.flatten(); features.extend(feats); <ins> // -Zfixed-x18 if sess.opts.unstable_opts.fixed_x18 { if sess.target.arch != "aarch64" { sess.dcx().emit_fatal(FixedX18InvalidArch { arch: &sess.target.arch }); } else { features.push("+reserve-x18".into()); } } </ins> if diagnostics && let Some(f) = check_tied_features(sess, &featsmap) { sess.dcx().emit_err(TargetFeatureDisableOrEnable { features: f,

Discussion:
On the target, specifying the target feature using the flag results in the following warning: The desired effect of this flag is to reserve the x18 register so that LLVM does not use it during codegen. Note that despite the warning, the flag still works fine today since it is passed on to LLVM. This feature is necessary for Rust to work when using the Linux Kernel's dynamic shadow call stack feature on aarch64 (). The shadow call stack feature requires that the x18 register is reserved, since it is used to store the shadow stack. In C code, the dynamic version of shadow call stack requires you to pass but not (which is only used for non-dynamic SCS). Clang has a collection of flags for reserving other registers than x18 as well. I think it would make sense to add those as well, even if they are less useful than x18. Related to . Related to .
This affects the ABI, right? I think adding a target spec option makes the most sense (or actually you can already set it as target feature in the target spec without giving a warning). That way you can't enable or disable it for individual functions or crates, which would break the ABI.
Yeah, it would be nice to have a flag for this (or having something like "global target features", i.e. like , but that it ensures it is set the same way for all compilation units).
There could be ABI concerns with this in general. AAPCS64 defines x18 as a platform register if required, or temporary if a platform register isn't needed. For x18 it's probably unlikely for it to have ABI concerns as it's already reserved for use on some platforms, the ones where it's not already reserved, it's only supposed to be a temporary register so not using it should be OK as it is not used for any fixed purpose. That's obviously assuming a platform defines its ABI based on the Arm standards. LLVM does support reserve on other registers, most notably for ABI reasons, x1 through x7 which would have ABI problems. LLVM does have test cases to ensure that a function call doesn't occur if any of the argument registers have been reserved. I'm not sure what other codegen backends do in that case though, or if they even support reserving those registers.

The analysis that LLVM does, doesn't seem to care if it would need to use that register for ABI reasons, even a function such as can't be called in a quick test. Using target features for this feels strange to me though, I'm wondering if a codegen option to reserve certain registers would be a better approach here. While this issue is specifically about reserving a register on AArch64, LLVM does support this for multiple other architectures and multiple registers, which we should maybe consider for the future.
Change:
/// /// [`chars`]: ../../std/primitive.str.html#method.chars /// [`str`]: ../../std/primitive.str.html <del> #[derive(Clone, Debug)] </del> <ins> #[derive(Clone)] </ins> #[stable(feature = "rust1", since = "1.0.0")] pub struct Chars<'a> { iter: slice::Iter<'a, u8>

Discussion:
Currently, the Debug of prints the underlying bytes, rather than the chars: Returns: As I was trying to work out what was (whether it was unicode points or bytes or something else), the first output was v confusing - is there a reason we don't print something like the second case? Would you take a PR to change this? I couldn't find any previous discussion on this - was the closest I could find.
The first one is UTF-8 bytes. You see this because the impl for is auto-generated: Strictly speaking, since the bytes inside of should always be valid UTF-8, this could have a custom impl that makes it pretend to contain a string by formatting the member as . The reason it doesn't display as individual chars is because it doesn't have individual ; determining their boundaries is the entire point of the iterator. I suppose this same argument could be used against the call to , which needs to scan the whole string to validate it. (but then the solution seems to be to use , which seems awfully heavy-handed for a impl. And perhaps it doesn't even matter, because the cost of most impls probably outweighs the cost of this validation) I guess that, questionable concerns of efficiency aside, my main concern is simply that showing a list of individual chars would be... dishonest, I guess.
Do & contain more data than ? I had thought they both contained the underlying bytes and then these were decoded as needed - including as part of the & implementations
No, they contain the same data. They're all just UTF-8 bytes. And the implementation of simply writes the bytes contained in the directly to the instance. Suppose we are writing to STDOUT. On UNIX, the impl writes these bytes directly to the underlying file descriptor with no processing: I would imagine this is because the console on any UNIX platform almost certainly uses UTF-8.[^1] It is your terminal application that is then responsible for decoding these bytes and producing glyphs. Considering that UTF-8 dominates much of the web space as well, it's quite possible that even on the playground, these bytes are ultimately sent over the wire to your PC with minimal processing, where your browser is responsible for decoding and displaying them. On Windows, transcodes the UTF-8 into the UTF-16 format expected by the windows APIs: and then Windows does whatever it does with those UTF-16 code units.

(Quite likely, it hands them directly to the console, which is then responsible for decoding and displaying them) [^1]: (I think in actuality UNIX accepts arbitrary strings of bytes, and then the portions of these strings which are valid UTF-8 are rendered appropriately by the console. I don't know; doesn't really matter)
OK, so given that - is there still an objection to displaying the unicode characters for but not ?
Change:
<ins> // Copyright 2016 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. pub trait Resources<'a> {} pub trait Buffer<'a, R: Resources<'a>> { fn select(&self) -> BufferViewHandle<R>; //~^ ERROR mismatched types //~| lifetime mismatch //~| NOTE expected type `Resources<'_>` //~| NOTE    found type `Resources<'a>` //~| NOTE the lifetime 'a as defined on the method body at 14:4... //~| NOTE ...does not necessarily outlive the anonymous lifetime #1 defined on the method body //~| ERROR mismatched types //~| lifetime mismatch //~| NOTE expected type `Resources<'_>` //~| NOTE    found type `Resources<'a>` //~| NOTE the anonymous lifetime #1 defined on the method body at 14:4... //~| NOTE ...does not necessarily outlive the lifetime 'a as defined on the method body } pub struct BufferViewHandle<'a, R: 'a+Resources<'a>>(&'a R); fn main() {} </ins>

Discussion:
Receiving info about MIR or some other intermediate form in a user error report. I tried this code which most likely has some lifetime issue that I am yet to resolve: I should have received information about the scope defined by some part of my code or if the issue is with auto-generated code then possibly no information about an internal scope. Instead, this happened: :
This seems to be more common than I first thought: Made a resulted in:
Issue exists in latest nightly as well.
Can confirm experiencing it. Smaller sample: Not an issue in current stable or beta, which reports rather than
Does this qualify as a regression?
Yes, though not the kind we'd do a point release for, IMO
should mark as such then :)
Here's another small one:
It took me a minute to figure out that this issue is about the error message & not the error. I've also been getting CallSiteScope and so on nonsense in my error output recently. This seems like a pretty serious regression in the usability of our error messages! My impression has been that this impacts just about every lifetime issue I've been getting recently, but I could be wrong. Could we get this fixed by next stable release? I disagree with that this isn't worth making a point release for (currently its only in nightly, so that's not an issue).
Nominated for consideration by the compiler team.
This appears to be in beta (testing on the playground). Super tiny repro: gives
Has nobody looked into this? I'll take a peek before the compiler meeting today. EDIT: Of course it was me who introduced this bug, or rather triggered sigh. EDIT2: Basically, after , any uses of are suspicious. I'll try to make a PR.
Fix is at , using reduction as the testcase for this issue.
triage: P-high We have a fix though =)
Change:
binder: EarlyBinder<TraitRef<'tcx>>, mut did_has_local_parent: impl FnMut(DefId) -> bool, ) -> bool { <del> let infcx = tcx.infer_ctxt().build(); </del> <ins> let infcx = tcx .infer_ctxt() // We use the new trait solver since the obligation we are trying to // prove here may overflow and those are fatal in the old trait solver. // Which is unacceptable for a lint. // // Thanksfully the part we use here are very similar to the // new-trait-solver-as-coherence, which is in stabilization. // // https://github.com/rust-lang/rust/issues/123573 .with_next_trait_solver(true) .build(); </ins> let trait_ref = binder.instantiate(tcx, infcx.fresh_args_for_item(infer_span, trait_def_id)); let trait_ref = trait_ref.fold_with(&mut ReplaceLocalTypesWithInfer {

Discussion:
Sorry, I don't have simple code to reproduce the issue, because the project is large. The repro is this: Contents of the mentioned file is: I tried increasing , did not help. Also works on stable. This may be duplicate of because timing.
This is also affecting :
Using the starlark-rust repro, this bisects to
overflow is fatal in the old trait solver, so by proving additional goals, especially if they have inference variables, we can end up with new sources of overflow causing an error. the most straightforward fix is to use the new solver for this lint given that the lint uses an empty environment it uses pretty much the same parts of the solver as coherence so it should already be ready for that
WG-prioritization assigning priority (). label -I-prioritize +P-high
I have a somewhat minimal repro, it has a lot of deps (via bevy) but not much code: Where is not something (I think) that can be decomposed into a tuple.
Change:
<ins> // Reexport of a structure with public inherent impls having doc links in their comments. The doc // link points to an associated item, so we check that traits in scope for that link are populated. // aux-build:extern-inherent-impl-dep.rs extern crate extern_inherent_impl_dep; pub use extern_inherent_impl_dep::PublicStruct; </ins>

Discussion:
Running on nightly causes an ICE. Judging by my for PRs this broken between 2 and 4 days ago (26th-28th Jan). See attached minified project: . Essentially, this is: <details<summary<strongBacktrace</strong</summary<p</p</details
I see the same on Docs build fine with latest stable (1.58.1), but I get the same error with
This is probably a duplicate of , right? The fix for that () isn't in yesterday's (2022-01-29) nightly yet, but should be in today's.
I get the same error with , which does include .
works for me on aarch64-apple-darwin, but not on
There are definitely three crates still hitting this ICE on (at least based on message, and backtrace in 2 cases, but I couldn't reproduce on when testing locally) in
You can use () in your code to figure out what change caused this regression.
Not so surprisingly bisection reveals as the cause.
I'm not sure if this is helpful, but this is the stack I get when attempting to run rustdoc with nightly (which is the most recent nightly available on macOS). I also get the same build failure in CI with . This error comes from building the docs on
Fixed in
Assigning same priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
It seems this issue has regressed recently? Hitting the same ICE on . <details<summary<strongBacktrace</strong</summary<p</p</details
The recent regression should be fixed by , most likely.
Change:
} } <del> /// Returns [`true`] if this is a unique local address (fc00::/7). </del> <ins> /// Returns [`true`] if this is a unique local address (`fc00::/7`). </ins> /// /// This property is defined in [IETF RFC 4193]. ///

Discussion:
This code should be correct, because according to document, all address in are not global reachable. But it panic on assertion failed in latest nightly (2019-01-11) (see )
Relevant thread:
Sorry, fixed
Change:
<ins> /* //~ ERROR E0758 /* */ /* */ </ins>

Discussion:
Given: The compiler says: This initially confused me quite a bit because I couldn't figure out why Rust wasn't seeing block comment terminator. Eventually, I realized that the line changed from being a commented out line, to starting a nested block comment. Since block comments nest in Rust, I'm used to commenting out blocks without worrying about what's inside of them which made this behaviour surprising. I'm not sure how practical it is, but it would be cool if we could check for comments like in block comments to suggest them as the source of the problem. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
empty: Empty, } let _enum_without_variants = [NoVariants { int: 0 }]; <ins> // A non-UTF-8 string slice. Regression test for #75763 and #78520. struct Str<const S: &'static str>; let _non_utf8_str: Str::<{ unsafe { std::mem::transmute::<&[u8], &str>(&[0xC0, 0xC1, 0xF5]) } }>; </ins> }

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. --code from <!-- 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
Heh, I guess wasn't fixed after all. I wonder when it regressed.
That label is for , I do not think it is the right one here.
cargo bisect rustc says this regressed in Perhaps ?
Untagging as a regression, this requires nightly (const generics).
The bug no longer needs the to trigger.
Change:
parser.approx_token_stream_pos(), track, ); if let Some(res) = res { return res; }

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
[package] name = "x" <del> version = "0.1.0" </del> <ins> version = "0.1.1" </ins> description = "Run x.py slightly more conveniently" edition = "2021" publish = false

Discussion:
Since , src/tools/x unconditionally looks for the shell scripts when running. That's good in most cases because it avoids having to run python. However, on old checkouts the shell scripts don't exist and it needs to fall back to using python. cc do you have time to fix this? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim If it can wait for the weekend to pass, then yes. Anyone, feel free to claim of you can do it in the weekend
i could help! Could you give me some pointers on what needs to be done?
What you should do is re-add the code that was removed in , using it when the shell scripts are not found, but x.py is. You could even add an env var that forces the use of python, but that's a later step.
I see! Okay I'll give this a shot! But I may need more time than just the weekends cause I probably need some time to figure things out. But if it's urgent then feel free to unassign me claim
I don't think this is necessary, there shouldn't be any functionality that's available in python but not shell.
It is future-proofing for when python does get used only when building bootstrap, and the shell scripts won't be able to call python
That can be done with a function argument so it's not exposed to users.
Yes, it can work like this.
Hi ! Currently working on this. Could you list out the steps needed to replicate this issue so I could get a bit more context of the problem? Thank you!
install it from a current version of the repository, then check out any commit from before and run . It will says "x.py not found" even though it exists in the repository.
Err sorry, that was the commit that changes src/tools/x - you want the commit that initially the ./x and x.ps1 scripts.
One reason may be because they work on a pr that started before this commit, and that (miraculously) didn't conflict. Another reason would have been because the work was done on stable/beta, but I think the scripts are now on stable (correct me if I'm wrong)
Change:
# i686-apple-darwin configuration CC_i686-apple-darwin=$(CC) <del> LINK_i686-apple-darwin=cc </del> CXX_i686-apple-darwin=$(CXX) CPP_i686-apple-darwin=$(CPP) AR_i686-apple-darwin=$(AR)

Discussion:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.