jiebi/CodeConvo huggingface dataset:
Change:
{ return; } <ins> // if it's an inherent `self` method (not `&self` or `&mut self`), it will take // precedence over the `TryInto` impl, and thus won't break in 2021 edition if pick.autoderefs == 0 && pick.autoref_or_ptr_adjustment.is_none() { return; } </ins> // Inherent impls only require not relying on autoref and autoderef in order to // ensure that the trait implementation won't be used self.tcx.struct_span_lint_hir(

Discussion:
I tried this code: I expected to see this happen: No warning Instead, this happened: Got the warning: AFAIK, this should not be ambiguous, since it is an inherent method, which should take priority over the TryInto trait. Also, the suggestion doesn't make much sense, since it just surrounds the variable with parenthesis, which have no effect (and indeed, can be removed even on 2021). cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'll look into it, in some cases inherent methods do collide but this is definitely a false positive, might just be checking the number of derefs.
claim
label +A-diagnostics +A-edition-2021 +D-incorrect +T-compiler
Change:
stalled_on: &mut Vec<TyOrConstInferVar<'tcx>>, ) -> ProcessResult<PendingPredicateObligation<'tcx>, FulfillmentErrorCode<'tcx>> { let infcx = self.selcx.infcx; <del> if obligation.predicate.is_global() { </del> <ins> if obligation.predicate.is_global() && !self.selcx.is_intercrate() { </ins> // no type variables present, can use evaluation for better caching. // FIXME: consider caching errors too. if infcx.predicate_must_hold_considering_regions(obligation) {

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc you this assertion
Regression in nightly-2023-07-06 Regression in
so this was clearly buggy before and I expect it to be an issue limited to specialization. Going to not look into this further myself for now.
Change:
<ins> error[E0507]: cannot move out of `*u.a` which is behind a shared reference --> $DIR/move-from-union-field-issue-66500.rs:14:5 | LL |     *u.a |     ^^^^ move occurs because `*u.a` has type `std::string::String`, which does not implement the `Copy` trait error[E0507]: cannot move out of `*u.b` which is behind a mutable reference --> $DIR/move-from-union-field-issue-66500.rs:18:5 | LL |     *u.b |     ^^^^ move occurs because `*u.b` has type `std::string::String`, which does not implement the `Copy` trait error[E0507]: cannot move out of `*u.c` which is behind a raw pointer --> $DIR/move-from-union-field-issue-66500.rs:22:5 | LL |     *u.c |     ^^^^ move occurs because `*u.c` has type `std::string::String`, which does not implement the `Copy` trait error[E0507]: cannot move out of `*u.d` which is behind a raw pointer --> $DIR/move-from-union-field-issue-66500.rs:26:5 | LL |     *u.d |     ^^^^ move occurs because `*u.d` has type `std::string::String`, which does not implement the `Copy` trait error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0507`. </ins>

Discussion:
The following code ICEs, when it should produce a cannot move error
Worse, the following compiles:
regression from stable-to-beta and stable-to-nightly
triage: P-high
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> #![feature(rustc_attrs)] </del> <ins> #![feature(asm, rustc_attrs)] #![allow(unused)] </ins> #[macro_use] mod foo; m!(); <ins> fn f() { n!(); } </ins> #[rustc_error] fn main() {} //~ ERROR compilation successful

Discussion:
For example, invocation in should search in but instead searches in .
cc
It looks like this is a problem with .
Change:
format!("Deprecating in {version}") } } <del> DeprecatedSince::Future => String::from("Deprecating in a future Rust version"), </del> <ins> DeprecatedSince::Future => String::from("Deprecating in a future version"), </ins> DeprecatedSince::NonStandard(since) => { format!("Deprecated since {}", Escape(since.as_str())) }

Discussion:
says "Deprecating in a future Rust version" ! but it will not be deprecated in a future Rust version, it will be deprecated in a future crate version. An easy fix would be just always saying "version" instead of "Rust version", alternatively special casing the standard library.
Change:
<ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>

Discussion:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

() Errors:
/cc Related to but different from
This can be avoided by expressly allowing the type to be inferred:
: (as compared to )
After , this isn't fixed, but commenting out the call will cause it to error without ICEing (at the moment, it ICEs even without that line).
I configure struct by complicated const value and get this ICE. My code does something like this: Error: Note that type erase (as proposed does not help in my case. Until I found a way around this ICE.
Same error on:
I tried to port 's from to . Some of code is commented because of this bug and several other. I think this is good test for
Cannot reproduce the ICE with the above playground link.
It should be noted that while this no longer ICEs, this is because rustc no longer attempts to infer the type parameter causing it to fail to compile.

A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .
Change:
<ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>

Discussion:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.
Change:
<del> Subproject commit e24a1a025a1f214e40eedafe3b9c7b1d69937922 </del> <ins> Subproject commit aab1c0a0e0b39825b16673128729ef46310a5da8 </ins>

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
// except according to those terms. fn main() { <del> 0 as &std::any::Any; //~ ERROR non-scalar cast: `i32` as `&core::any::Any` </del> <ins> 0 as &std::any::Any; //~ ERROR illegal cast </ins> }

Discussion:
This is done when compiling repository. Use on either the entire handmadehero crate, or handmadelibsdl. Warning: Ugly, code ahead! Cleaned up repo: It does need to be across crate lines, and needs to be returned in a result, afaict.
The issue is that I should not be able to write because is a [T]. Same with .
Actually, to that end, why is bigger than a anything? Why is a a fat pointer at all?
Very similar to , , .
Yes it is, pretty much the same. A should not be differently sized from a , at least IMHO, so why is it?
is a with fewer guarantees; one can convert between them freely (if you ensure the guarantees are maintained for -). In particular, this means is a fat pointer to match .
That is weird...
NVM, I now understand why it is a fat pointer. However, this should be an easy fix, right? Why is a mut [T] seen as the same size as a mut T in rustc? Well, now it isn't, so is fixed, but it still panics at .
Change:
] [[package]] <ins> name = "itertools" version = "0.9.0" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "284f18f85651fe11e8a991b2adb42cb078325c996ed026d994719efcfca1d54b" dependencies = [ "either", ] [[package]] </ins> name = "itoa" version = "0.4.4" source = "registry+https://github.com/rust-lang/crates.io-index"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Change:
... LL | impl MyTrait for (MyType,) { } | ^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `(MyType,)` <ins> | = note: upstream crates may add new impl of trait `lib::MyCopy` for type `(MyType,)` in future versions </ins> error: aborting due to previous error

Discussion:
PR had removed the notes from the tests for the upstream/downstream printing logic, so now that logic is not tested: Plus, the new error messages are worse: an upstream impl can indeed be , even if the crate is private. I think that even in the OP case, some sort of note should be , unless we change coherence. Again, the test case: There, the error message is a coherence conflict for , where this impl conflicts with the libcore impl, because the compiler can't prove that . Now, the error message says that the reason that the compiler can't prove is because of a possible downstream impl. Of course, no downstream impl can exist as the trait is private, however, I don't think we want to change coherence to account for that, especially not without an RFC. Maybe a wording change is in order? I don't think the "upstream" message needs to change any (see the test diff), it's still good in the private case. Maybe it should try to mention a non-private trait, but that would be some work. Say, for non-exported trait, change the note to say: I'm not even sure the note is a problem, I personally like the state before the PR the best. cc
Actually, I think the version of the note I came up with is even more confusing than the "downstream crate" note, and the current version is worse than both.
That PR was also submitted with no "positive" test to see that it fixes the error message it is purported to fix. That feels clearly wrong to me.
Change:
<ins> // aux-build:issue-75982.rs // check-pass // Regression test for issue #75982 // Tests that don't ICE when invoking a foreign macro // that occurs inside a module with a weird parent. extern crate issue_75982; fn main() { issue_75982::first_macro!(); issue_75982::second_macro!(); } </ins>

Discussion:
Found in the crater run: ICEs: ` This ICE happens on: but only shows a compiler error.
Assigning as and removing .
This is because an integration gets checked, which relies on the feature to be enabled. Once it is enabled, does not fail anymore, and yet the ICE persists . I'll thus kindly ask for this to be "re-prioritized", if possible, thanks. modify labels: +I-prioritize
Assigning and removing as in the prioritization working group.
ping cleanup This needs mcve and bisection
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
searched nightlies: from nightly-2020-07-20 to nightly-2020-08-25 regressed nightly: nightly-2020-07-28 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summary
Minimized:
Change:
| ty::Str | ty::Projection(_) | ty::Param(_) => format!("{deref_ty}"), <ins> // we need to test something like  <&[_]>::len // and Vec::function(); // <&[_]>::len doesn't need an extra "<>" between // but for Adt type like Vec::function() // we would suggest <[_]>::function(); _ if self.tcx.sess.source_map().span_wrapped_by_angle_bracket(ty.span)  => format!("{deref_ty}"), </ins> _ => format!("<{deref_ty}>"), }; err.span_suggestion_verbose(

Discussion:
Given the following code (): The current output is: This suggestion is on the right track, but unfortunately it introduces a parse error. It should be: This suggestion is in . It suggests adding around the type because the type is a slice, but I already have in my program (and the span doesn't include the existing ). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
} } <ins> // Initialize the llvm submodule if not initialized already. builder.update_submodule(&Path::new("src").join("llvm-project")); </ins> let root = "src/llvm-project/llvm"; let out_dir = builder.llvm_out(target);

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
<ins> #![feature(min_specialization)] use std::fmt::{self, Display}; pub enum Cow<'a, B: ?Sized + 'a, O = <B as ToOwned>::Owned> where B: ToOwned, { Borrowed(&'a B), Owned(O), } impl ToString for Cow<'_, str> { fn to_string(&self) -> String { String::new() } } impl<B: ?Sized> Display for Cow<'_, B> { //~ ERROR: the trait bound `B: Clone` is not satisfied [E0277] fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { //~ ERROR: the trait bound `B: Clone` is not satisfied [E0277] write!(f, "foo") } } fn main() {} </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. --I wanted to change to use the pattern in the code below (which changes variance w.r.t to ), but got an ICE. I managed to reduce it the code below. The same code with the current definition of works (same as ): <!-- 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<details<summary<stronglog with RUSTCLOG=rustctrait_selection::traits::specialize</strong</summary<p</p</details
This ICEs since modify labels: +regression-from-stable-to-stable
Assigning as discussed as part of the and removing .
No longer appears to ICE since
Change:
} } <del> // Ensure the `IsNotPromotable` qualification is preserved. </del> <ins> // Ensure the `IsNotConst` qualification is preserved. </ins> // NOTE(eddyb) this is actually unnecessary right now, as // we never replace the local's qualif, but we might in // the future, and so it serves to catch changes that unset

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
exit(101); } <del> extern "C" void LLVMRustInstallFatalErrorHandler() { </del> <ins> // Custom error handler for bad-alloc LLVM errors. // // It aborts the process without any further allocations, similar to LLVM's // default except that may be configured to `throw std::bad_alloc()` instead. static void BadAllocErrorHandler(void *UserData, const char* Reason, bool GenCrashDiag) { const char *OOM = "rustc-LLVM ERROR: out of memoryn"; (void)!::write(2, OOM, strlen(OOM)); (void)!::write(2, Reason, strlen(Reason)); (void)!::write(2, "n", 1); abort(); } extern "C" void LLVMRustInstallErrorHandlers() { install_bad_alloc_error_handler(BadAllocErrorHandler); </ins> install_fatal_error_handler(FatalErrorHandler); <ins> install_out_of_memory_new_handler(); </ins> } extern "C" void LLVMRustDisableSystemDialogsOnCrash() {

Discussion:
Running a build of , as part of a Koiji (Fedora Build System) job, I get the following for the target: Also see:
To my understanding this should be Rust
I think this is "just" an OOM situation. Fedora builds with full debuginfo by default, and this package is configured for fat LTO as well, which will all get quite heavy. When I tried to reproduce this with the stable toolchain, I got: It completed when I turned off debuginfo though. With Fedora's toolchain, I can reproduce your SIGSEGV in LLVM, but it also completes the build when debuginfo is off. My guess is that it is also hitting an allocation failure, but perhaps in a place that doesn't properly check the pointer before trying to use it.
With the rustup toolchain, it's running out of memory in LLVM's , which calls allocation methods that abort on failure. That's where we get the "LLVM ERROR: out of memory", "Allocation failed". With the Fedora toolchain, it's running out of memory in LLVM's , which calls to plain , throwing . Rust runs its own destructors during that unwind, in particular dropping that calls , and this segfaults in a (presumably the same one).
I encontered this when compiling a big proprietary project to --target=i686-unknown-linux-musl using nightly-2024-03-01 on a x86_64 host
with an x86_64 host and a different backtrace, I doubt that yours has the same root cause. I suggest filing a separate issue -- but it's going to be hard for anyone to help if they can't reproduce it, since your code is proprietary.