jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0605]: non-primitive cast: `NotUnitOnlyOrFieldless` as `isize` --> $DIR/enum-to-numeric-cast.rs:42:13 | LL |     let _ = not_unit_only_or_fieldless as isize; |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ an `as` expression can be used to convert enum types to numeric types only if the enum type is unit-only or field-less | = note: see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information error[E0605]: non-primitive cast: `NotUnitOnlyOrFieldless` as `i32` --> $DIR/enum-to-numeric-cast.rs:43:13 | LL |     let _ = not_unit_only_or_fieldless as i32; |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ an `as` expression can be used to convert enum types to numeric types only if the enum type is unit-only or field-less | = note: see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information error[E0605]: non-primitive cast: `NotUnitOnlyOrFieldless` as `usize` --> $DIR/enum-to-numeric-cast.rs:44:13 | LL |     let _ = not_unit_only_or_fieldless as usize; |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ an `as` expression can be used to convert enum types to numeric types only if the enum type is unit-only or field-less | = note: see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information error[E0605]: non-primitive cast: `NotUnitOnlyOrFieldless` as `u32` --> $DIR/enum-to-numeric-cast.rs:45:13 | LL |     let _ = not_unit_only_or_fieldless as u32; |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ an `as` expression can be used to convert enum types to numeric types only if the enum type is unit-only or field-less | = note: see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0605`. </ins>

Discussion:
Possibly link to the Rust Reference where this is explained in detail. Casting an enum to an int is common for C developers. When I searched the internet for guides on how to do this in Rust, they all essentially said it just works like . E.g. , . These guides don't explicitly say that this only works if all of the enum variants are unit-like. The compiler message in this situation did not help me to understand what had gone wrong, and googling for it and "enum" returned the same sort of results as mentioned above. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-newcomer-roadblock D-confusing
claim
Change:
}) { debug!("found target, real_target: {:?} {:?}", target, real_target); <ins> if let Some(did) = target.def_id_full(cx.cache()) { if let Some(type_did) = impl_.inner_impl().for_.def_id_full(cx.cache()) { // `impl Deref<Target = S> for S` if did == type_did { // Avoid infinite cycles return; } } } </ins> let deref_mut = v .iter() .filter(|i| i.inner_impl().trait_.is_some())

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. --Original: Minimized: <!-- 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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
When running with , the last few lines before the panic are: seems relevant since it has a impl:
Minimized: rust pub struct Generic<T(T); impl<'astd::ops::Deref for Generic<&'a mut (){ type Target = Generic<&'a (); fn deref(&self) -&Self::Target { unimplemented!() } } impl<'aGeneric<&'a (){ pub fn some_method(&self) {} }
searched nightlies: from nightly-2020-11-12 to nightly-2021-01-17 regressed nightly: nightly-2021-01-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed in . label regression-from-stable-to-nightly
cc - do you have time to figure out what's going wrong here?
Yes, I believe so, I'll see what I can do here. claim
Please ping me once you open the PR ( is taking a break :) )
The core issue is the recursion cycle handling... It focuses only on s and wasn't anticipating targets that differ only in generic type args. I believe I see the tweak we'll need here, so I should have a PR in the next day or so.
Change:
} } <ins> const CONST_ITEM: usize = (10); //~ ERROR unnecessary parentheses around assigned value static STATIC_ITEM: usize = (10); //~ ERROR unnecessary parentheses around assigned value </ins> fn main() { foo(); bar((true)); //~ ERROR unnecessary parentheses around function argument

Discussion:
It doesn't give a warning for the unnecessary parentheses for N1: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
implemented for to check the .
claim
I've encountered an issue I'm not quite sure how to handle :( After getting what looks like a correct solution up with: I am met with the following after starting to build stage-1: Should I open a separate Issue & PR to deal with any errors generated by unused parens or is it within the scope of this issue (and PR coming soon once I write the UI tests) to deal with them?
should be fixed within this issue, and don' forget to add a testcase named into , then , git add the new and updated if any.
I resolved the issue with the submodule, is it alright if I claim this? It's a small patch to land. claim
Change:
<ins> macro_rules! foo { ($val:ident) => { true; }; } fn main() { #[expect(semicolon_in_expressions_from_macros)] //~^ ERROR the `#[expect]` attribute is an experimental feature let _ = foo!(x); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'assertion failed: matches!(, Error Allow)'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [earlylintchecks] perform lints prior to macro expansion [hircrate] getting the crate HIR -- label +F-stmtexpr_attributes
bisects to :thinking: cc edit: ah the assertion was there...
Change:
use crate::diagnostics::{import_candidates, Suggestion}; use crate::Determinacy::{self, *}; <del> use crate::Namespace::{self, *}; </del> <ins> use crate::Namespace::*; </ins> use crate::{module_to_string, names_to_string, ImportSuggestion}; use crate::{AmbiguityKind, BindingKey, ModuleKind, ResolutionError, Resolver, Segment}; use crate::{Finalize, Module, ModuleOrUniformRoot, ParentScope, PerNS, ScopeSet};

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see no output from the compiler. Instead, this happened: searched nightlies: from nightly-2022-09-22 to nightly-2022-09-27 regressed nightly: nightly-2022-09-25 searched commit range: regressed commit: This is a roll-up, seems the most likely culprit. cc <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: aarch64-apple-darwin Reproduce with: </details modify labels: +regression-from-stable-to-nightly -regression-untriaged
WG-prioritization assigning priority, probably a P-high since the lint malfunction is blocking valid code (iiuc) label -I-prioritize P-high T-compiler
any ideas how to address this or should I start digging in to it
In HIR desugars into two items (import in type namespace and import in value namespace). One of them is externally reachable and another is not (before both of them were incorrectly marked as externally reachable). Code in should somehow account for this desugaring and not report the as unnecessary if at least one of the imports is reachable.
I have been unable to fix this or apply a revert. can you look at implementing this before the beta cutoff?
Reverted in
Change:
d: u64, } <ins> // this exercises the try-fold codepath pub struct Baz { a: u64, b: u64, c: u64, d: u64, } </ins> // CHECK-LABEL: @vec_iterator_cast_primitive #[no_mangle] pub fn vec_iterator_cast_primitive(vec: Vec<i8>) -> Vec<u8> {

Discussion:
Adding the follow method as part of a benchmark to which exercises results in the following assembly (extracted with objdump): The ghidra decompile for the same function (comments are mine): Note the useless loop. The number of loop iterations (or rather the pointer increments) is needed to calculate the new length of the output . LLVM already manages to hoist but then it fails to eliminate the now-useless loop. The issue does not occur if one uses instead, which always results in length == 0. I tried several variations of the loop (e.g. replacing with a simple ) but it generally results in the same or worse assembly. Note: The assembly looks somewhat different if I but the decrementing loop without side-effect is still there. I assume the differences are due to LTO or some other compiler settings. Tested on commit 2020-11-21 22:46 modify labels: +I-slow
It looks like this can be solved with more ~dakka~ passes. On godbolt it can be made loop-free by adding And branchless with Using as starting point requires the same passes to be to achieve these results, i.e. it does not provide a better baseline. I failed to reproduce this improvement locally but that might be due to argument escaping issues when attempting to put the space-separated list into
Surprisingly targeting a current CPU results in only one extra pass needed to achieve the loop-free result:
Inserting one loop deletion pass directly into also results in the branchless version without having to change target-cpu or adding additional other passes. So I assume that the other passes are only needed due to the way that works.
It looks like that this removed on nightly now. On nightly: On stable:
That's only true for types because I implemented a specialization for that purpose. The suboptimal assembly still exists for types not implementing Copy, e.g. newtypes. I'll update my initial post.
Something that was is that this case also fails for - i.e. with the specialization - is when the wrapper type is
Seems to work in the other direction weirdly is optimised away, whilst is not
Is there a case here that still doesn't optimize? It looks like all the existing godbolt links do.
Looks good, I'll update the existing codegen test.
Change:
<ins> error[E0382]: use of moved value: `r` --> $DIR/pin-mut-reborrow-infer-var-issue-107419.rs:10:9 | LL |     let mut r = Pin::new(&mut uwu); |         ----- move occurs because `r` has type `Pin<&mut ()>`, which does not implement the `Copy` trait LL |     foo(r.get_mut()); |           --------- `r` moved due to this method call LL |     foo(r.get_mut()); |         ^ value used here after move | note: `Pin::<&'a mut T>::get_mut` takes ownership of the receiver `self`, which moves `r` --> $SRC_DIR/core/src/pin.rs:LL:COL help: consider reborrowing the `Pin` instead of moving it | LL |     foo(r.as_mut().get_mut()); |           +++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0382`. </ins>

Discussion:
searched nightlies: from nightly-2023-01-27 to nightly-2023-01-28 regressed nightly: nightly-2023-01-28 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details label +I-ICE +F-typealiasimpltrait
Minimized it further:
Change:
<ins> // edition:2018 #![feature(decl_macro)] #![crate_name = "external_crate"] pub mod some_module { /* == Make sure the logic is not affected by a re-export == */ mod private { pub macro external_macro() {} } pub use private::external_macro; } </ins>

Discussion:
rustdoc is showing the macro at the wrong path in libcore: says but really it is (and the same goes for ). Looks like is not handled correctly? Cc
cc
When a macro is marked as reexported, you can use it directly from the "top", so in this regard, isn't it the expected behavior?
AFAIK that is not true for macros, just for macros.
Note that there is no here. This macro is exported via , like normal items (functions, structs, ...).
Code example: So I think there is definitely a rustdoc bug here. The path it shows does not work.
Oh I see. Indeed, it's a bug.
Not sure if helpful, but the way we got public exports to work in rustdoc in was by creating a separate crate (), and then re-exporting from from the main crate. This enabled us to render  in rustdoc. This issue will also affect the upcoming  PR.
how hard is it to fix this problem, and what does the rustdoc team's prioritization for this look like? We'd like to stabilize , and I am not sure if we want to stabilize this while its docs are rendered incorrectly.
Sorry but no idea. I don't have much time lately so maybe someone else from the will give it a try? Otherwise I'll try to fix it as soon as I have time.
Yeah so the problem here is that we have TypeKind::Macro which forces all macros to live at the root. Given a Def or a Res, how do I tell if a macro is MBE or a newstyle macro? (There's a possibility that our current code actually handles this correctly already and we need to remove the special case for TypeKind::Macro)
Okay so here are the two offending bits of code: The latter is more about linking to these items rather than rendering them. So the problem is that by the time stuff gets to rustdoc, we're looking at the HIR and the two kinds of macros are squashed together on . The newstyle macros are not a variant of at all, they disappear from the HIR tree at that point and only exist as an array on the crate. It would be nice if MBEs stayed on and newstyle macros were actually Items or at least stored separately on the module.

We could handle these as we see their containing module, but that seems prone to issues when there are reexports and private modules in the mix. I think having newstyle macros live on rather than is a mistake.
An option to do this purely in rustdoc would be to check the and insert it in the appropriate modules after the fact, however this is kinda icky and i don't think this will be the last tooling problem encountered by newstyle macros living at the crate root in HIR.
will probably know best how to interpret this information; somehow macro name resolution also has to work with this, after all.
I don't think name resolution actually operates on the hir that way. But yeah, worth letting him answer.
I think you can recover the module they came from using the on it.
You can tell whether it's a macro or a by looking at .
Change:
<ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/cannot-convert-refree-ice-114463.rs:3:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default error: cannot capture late-bound lifetime in constant --> $DIR/cannot-convert-refree-ice-114463.rs:6:16 | LL | fn bug<'a>() { |        -- lifetime defined here LL |     [(); (|_: &'a u8| (), 0).1]; |                ^^ error: aborting due to 1 previous error; 1 warning emitted </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. --<!-- 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

<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(constrefstostatic) -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)', 'error: internal compiler error: expected wide pointer extra data (e.g. slice length or trait object vtable)' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [evaltoallocationraw] const-evaluating + checking [evaltoconstvalueraw] simplifying constant for the type system [analysis] running analysis passes on this crate --
cc
You can add to get this kind of stacktrace:
Change:
); aux_cx.build_all_auxiliary(of, &aux_dir, &mut aux_rustc); <ins> aux_rustc.envs(aux_props.rustc_env.clone()); </ins> for key in &aux_props.unset_rustc_env { aux_rustc.env_remove(key); } <del> aux_rustc.envs(aux_props.rustc_env.clone()); </del> let (aux_type, crate_type) = if is_bin { (AuxType::Bin, Some("bin"))

Discussion:
<!-- [31mICE[0m: Rustc '--edition=2021 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil', 'error: internal compiler error: relating different kinds: {const error}: &'static str KeyNil' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to
Minimized further:
Is related? Current ICE-loc: Issue-'s ICE-loc:
cc PR author
Change:
<ins> #![feature(min_type_alias_impl_trait)] #![feature(type_alias_impl_trait)] #![allow(incomplete_features)] trait MyTrait {} impl MyTrait for () {} type Bar = impl MyTrait; impl MyTrait for Bar {} //~^ ERROR: cannot implement trait on type alias impl trait fn bazr() -> Bar { } fn main() {} </ins>

Discussion:
As requested in , here's a follow up. The following code below implements the trait for an alias , which is an alias to . It doesnt really make sense to implement a that same trait. doesn't mention anything about this, however the previous notes: Im not sure this should be allowed. cc
This is fixed on master.
Change:
<del> Subproject commit e6a6470d1eb4c88fee4b1ea98cd8e0ac4a181c16 </del> <ins> Subproject commit c54cff0e6e4d1a0d0a2df7c1ce3d96cdd554763e </ins>

Discussion:
which is used to cast , or to two-element tuples with , , or types leads to incorrect code generation when located in unreachable code paths (and not supposed to be called). Replacing to fixes the issue. Making conditions more simple can also fix the issue. Building with debug profile fixes the issue. Regressed since 1.70.0 (see section below). This issue can lead to UB in creates which use with generics for runtime casting/specialization. Started with: Expected: no output Result: False conditions with which the issue is reproduced (failure): , , , (but generate less optimized assembly), False conditions with which the issue is NOT reproduced (ok): , , Сasts (actually unreachable) with which the issue is reproduced (failure): - Casts (actually unreachable) with which the issue is NOT reproduced (ok): - Cloned implementation of with removed will also lead to the error, i.e. it's the assert that helps to avoid the issue when using : 1.68.0 - not reproducible. 1.69.0 - not reproducible. 1.70.0 - reproducible. 1.71.0 - reproducible. Stable () - reproducible. Beta ()- reproducible. Nightly () - reproducible. Reproducible in Rust playground as well: Quick bisection between 1.69.0 and 1.70.0 with MRE: Casting some byte primitives to some two-element tuples unexpectedly succeeds on release builds and definitely leads to UB. These assertions will success on debug builds, but will fail on release builds: Castaway crate uses to transmute between types when type ids are matched. Unexpected cast success is reproduced for casts from to where is , or , is , , or , is , , or , or where is , , is , , or , is , , or but has different byte size than Check code:
From a brief glance, this looks like a SROA bug to me: We should not be folding to poison. (Alive2 doesn't flag this, but I believe that's a bug in alive2. Filed )
If this showed up in 1.70, it was probably exposed by since that changed from memcpy to a normal load. (EDIT: doh, you'd already bisected to the rollup with that PR.)
Upstream issue:
WG-prioritization assigning priority (). label -I-prioritize +P-high

I worked out this minimal reproducible example from some code I've been working on. Changing almost anything about this causes the compiler crash to go away, which probably makes it a little hard to figure out what's going on here. I've checked and performing a release build, or a debug build with an opt level = 1 will cause the compiler to SIGSEGV. Clearing the target dir, switching between stable/nightly, reinstalling toolchains, updating my system etc. didn't have an effect. Occurs in both Stable and Nightly. : : No backtrace was output. Also attempted to enable LLVM assertions and saw no change in output. Increasing stack size, as per advice, had no effect.
rustc 1.77.0 compiles OK. rustc 1.78.0+ crashes.
Crash in TwoAddressInstructionPass, appears to still occur on LLVM main.
Upstream issue:
Change:
} else { // It is guaranteed that any non-slice scalar pair is actually ByRef here. // When we come back from raw const eval, we are always by-ref. The only way our op here is <del> // by-val is if we are in const_field, i.e., if this is (a field of) something that we </del> <ins> // by-val is if we are in destructure_const, i.e., if this is (a field of) something that we </ins> // "tried to make immediate" before. We wouldn't do that for non-slice scalar pairs or // structs containing such. op.try_as_mplace(ecx)

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
} Some(_) => true, None => false, <del> }; </del> <ins> } </ins> } else { false }

Discussion:
() same code with an additional line of whitespace/comments where indicated: however, the playground seems to behave different from my local nightly here Tested on label T-compiler requires-nightly F-markertraitattr A-traits A-typesystem and someone please add “I-unsound ”
ACTUALLY… the error after adding the whitespace disappears again with . Which would explain why it isn’t reproducable in the playground. Might be related to label A-incr-comp.
This test doesn't seem to compile with the most recent nightly but I don't think the underlying issue has been fixed. Not sure how to retrigger this issue