jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> fn compute_components_recursive<'tcx>( </del> <ins> /// Collect [Component]s for *all* the substs of `parent`. /// /// This should not be used to get the components of `parent` itself. /// Use [push_outlives_components] instead. pub(super) fn compute_components_recursive<'tcx>( </ins> tcx: TyCtxt<'tcx>, parent: GenericArg<'tcx>, out: &mut SmallVec<[Component<'tcx>; 4]>,

Related discussion:
text: <!-- 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: Both asserts don't pass. Adding bound on makes it compile. We are requiring all the for closures and generators to outlive here: This is wrong and inconsistent with the logic in <!-- 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. --Build using the Nightly version: 1.63.0-nightly (2022-05-24 ) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label T-compiler A-lifetimes A-closures A-generators claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
Code change:
<ins> // check-pass // aux-build:issue-112831-aux.rs mod zeroable { pub trait Zeroable {} } use zeroable::*; mod pod { use super::*; pub trait Pod: Zeroable {} } use pod::*; extern crate issue_112831_aux; use issue_112831_aux::Zeroable; fn main() {} </ins>

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --With the latest nightly, the bytemuck crate fails to compile. This was compiling yesterday and the issue seems to be traits are not imported with super::*. Please see the issue in the bytemuck repository: <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in searched nightlies: from nightly-2023-06-10 to nightly-2023-06-20 regressed nightly: nightly-2023-06-20 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: cc
<details<summaryi made a mistake making the example, see below </summaryThis should error in coherence, but instead errors with It looks like if there is a derive macro and trait with the same name, glob imports don't resolve the trait anymore. Note that works correctly </details
Maybe the reduced it incorrect? I found that it also throw an error for 1.70?
hm, maybe your change simply exposed an existing bug in more cases
I will check it later claim
ah no, I made a stupid mistake, i should have used :D, my example only got from the prelude which only contains the macro.
This is resolved, of course. Only tagging this with Nilstrieb's estimated priority for historical analysis later.
Now that this fix is merged, what time tonight should we expect a new nightly release?
0:00 according to a server somewhere. In practice, usually UTC 0:00. So it should be being cut sometime soon. Or 24 hours from now. Either one.
Code change:
// Change value between simple literals --------------------------------------- <del> #[cfg(cfail1)] static STATIC_CHANGE_VALUE_1: i16 = 1; #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_clean(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> static STATIC_CHANGE_VALUE_1: i16 = 2; </del> <ins> static STATIC_CHANGE_VALUE_1: i16 = { #[cfg(cfail1)] { 1 } #[cfg(not(cfail1))] { 2 } }; </ins> <del> // Change value between expressions ------------------------------------------- #[cfg(cfail1)] static STATIC_CHANGE_VALUE_2: i16 = 1 + 1; #[cfg(not(cfail1))] </del> <ins> // Change value between expressions ------------------------------------------- </ins> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_clean(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> static STATIC_CHANGE_VALUE_2: i16 = 1 + 2; </del> <ins> static STATIC_CHANGE_VALUE_2: i16 = { #[cfg(cfail1)] { 1 + 1 } </ins> <del> #[cfg(cfail1)] static STATIC_CHANGE_VALUE_3: i16 = 2 + 3; </del> <ins> #[cfg(not(cfail1))] { 1 + 2 } }; </ins> <del> #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_clean(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> static STATIC_CHANGE_VALUE_3: i16 = 2 * 3; </del> <ins> static STATIC_CHANGE_VALUE_3: i16 = { #[cfg(cfail1)] { 2 + 3 } </ins> <del> #[cfg(cfail1)] static STATIC_CHANGE_VALUE_4: i16 = 1 + 2 * 3; </del> <ins> #[cfg(not(cfail1))] { 2 * 3 } }; </ins> <del> #[cfg(not(cfail1))] </del> #[rustc_clean(cfg="cfail2", except="HirBody")] #[rustc_clean(cfg="cfail3")] #[rustc_metadata_clean(cfg="cfail2")] #[rustc_metadata_clean(cfg="cfail3")] <del> static STATIC_CHANGE_VALUE_4: i16 = 1 + 2 * 4; </del> <ins> static STATIC_CHANGE_VALUE_4: i16 = { #[cfg(cfail1)] { 1 + 2 * 3 } #[cfg(not(cfail1))] { 1 + 2 * 4 } }; </ins> // Change type indirectly -----------------------------------------------------

Related discussion:
text: Found via rust-icci: https://travis- The commit history of the regex crate contains on changeset that only adds a comment which in turn leads to the body of a function being moved. This results in the update of the source location pointed to by a potential overflow panic message. This message is not updated properly in incremental mode: I have not found out yet why the change is not detected. HIR fingerprinting has special treatment of operations that can trigger overflows: There must be some kind of mismatch between when HIR fingerprinting thinks that an operation can panic and when we actually emit panic messages. This is another span-related papercut cc
Full IR files for reference:
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-107775.rs:35:16 | LL |         map.insert(1, Struct::do_something); |                    -  -------------------- this is of type `fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}`, which causes `map` to be inferred as `HashMap<{integer}, fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}>` |                    | |                    this is of type `{integer}`, which causes `map` to be inferred as `HashMap<{integer}, fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}>` LL |         Self { map } |                ^^^ expected `HashMap<u16, fn(u8) -> Pin<...>>`, found `HashMap<{integer}, ...>` | = note: expected struct `HashMap<u16, fn(_) -> Pin<Box<(dyn Future<Output = ()> + Send + 'static)>>>` found struct `HashMap<{integer}, fn(_) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: <!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this related to ?
Nope
Ooh I misread the Typerror ice, my bad :upsidedownface:
No big deal, this has to do with a lock (well, refcell) being held in hir typeck, if you're curious
Code change:
spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,

Related discussion:
text: If you combine LTO, anything that uses alloc and debug compilation mode, the compiler fails. The minimum example to reproduce is this : With this : To reproduce, run (or just use ): You should see this error: The above error does not reproduce for other compiler versions or options, all of the below work: I found reporting something similar, but for them is throwing the error, so I opened a new issue instead. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Initial reduction for :
Filed
In , dblaikie suggests that ought to separate the type-method declaration from the function definition, and I think I have that working. It passes the reproducer here, at least... claim
Code change:
spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,

Related discussion:
text: <!-- 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. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet.
Code change:
spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,

Related discussion:
text: Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim
Code change:
<ins> // edition:2018 struct Ia<S>(S); impl<S> Ia<S> { fn partial(_: S) {} fn full(self) {} async fn crash(self) { Self::partial(self.0); Self::full(self); //~ ERROR use of moved value: `self` } } fn main() {} </ins>

Related discussion:
text: I encounter an ICE: with rustc 1.41.0-nightly ( 2019-11-29) running on x8664-apple-darwin when compiling The same code does not ICE when using nightly-2019-11-27-x8664-apple-darwin Sorry, I haven't taken the time to make a minimal reproduction example.
Can you post the ICE message and backtrace?
Certainly! Although it is not the best stacktrace I have ever seen. Backtrace:
Backtrace:
modify labels: A-mir
I think I have a clue here: First the code: The problem seems to be a partial move of together with async together with a generic type (if we replace by for example, rust will complain as well and no ICE). If we remove the rust will complain: modify labels: +A-async-await -E-needs-mcve +E-needs-bisection
Regression in cc modify labels: -E-needs-bisection
triage: has PR. P-high, removing nomination.
Code change:
linker_flavor: LinkerFlavor::Gcc, options: TargetOptions { <del> features: "+v6,+vfp2".to_string(), </del> <ins> features: "+v6,+vfp2,-d32".to_string(), </ins> max_atomic_width: Some(64), abi_blacklist: super::arm_base::abi_blacklist(), target_mcount: "u{1}__gnu_mcount_nc".to_string(),

Related discussion:
text: The support for ARMv6 architecture was broken somewhere between ...: compiles file while produces binary that crashes with . More specifically, this is a binary cross-compiled from for arch, linked with a . The hardware is part of Raspberry Pi Zero rev. 1.1, the processor information is as follows:
Presumably due to LLVM update. Can you determine what the illegal instruction is? (E.g. via gdb and .)
did you try compiling code on your raspberry pi 0 ? this might be issue with gcc cross compiler (code generator part)l/linker rather than Rust
Looks like even compilation directly on RPi0 is broken as the compiler/cargo crashes: Running under gdb: I'm not sure if this helpful at all, I can send (e-mail) you the coredump or do anything else you need, unfortunately I have basically no experience debugging low-level ASM issues.
The problematic instruction is , which vfp2 and dpvfp. The target builds with . There were some in LLVM 9 around the sp/dp handling on ARM ( became ), possibly we flipped a default there...
According to the ARM1176JZF-S Technical Reference Manual (which is the CPU used in Raspberry Pi Zero) it contains a VFP11 coprocessor (VFP2 implementation with full support for single-precision and double-precision math operations). Maybe VFP11 is somehow slightly different from what LLVM assumes? ARM refs: VFP11 VectorFloating-point Coprocessor Technical Reference Manual for ARM1136JF-S
Thanks for the references. So both vfp2 and fp64 should be supported. Something I missed before is that the instruction uses the register, while the VFP11 coprocessor only has 16 double-precision registers. To target this CPU needs to be to the target features. It looks like the corresponding does disable . Possibly the default flipped here, in which case we should just add to all the older ARM targets.
This issue might be related to this one - libc's CI is broken since the LLVM upgrade.
This is probably caused by EDIT: Ah nevermind, someone found this already
Reopening until there is confirmation that this is fixed...
Hi with the recent 1.38.0-nightly ( 2019-07-26) both local toolchain / cargo and the cross-compiled binary seem to work. Thanks.
Great, closing as fixed
Code change:
* `unboxed_closures` - Rust's new closure design, which is currently a work in progress feature with many known bugs. <del> * `unmarked_api` - Allows use of items within a `#![staged_api]` crate which have not been marked with a stability marker. Such items should not be allowed by the compiler to exist, so if you need this there probably is a compiler bug. </del> * `allow_internal_unstable` - Allows `macro_rules!` macros to be tagged with the `#[allow_internal_unstable]` attribute, designed to allow `std` macros to call

Related discussion:
text: According to and in , this feature-gate should not be used. It appears that earlier error checking in the compiler prevents it from ever mattering anyway.
Code change:
use std::sync::Arc; use crate::clean::cfg::Cfg; <ins> use crate::clean::inline::{load_attrs, merge_attrs}; </ins> use crate::clean::{Crate, Item}; use crate::core::DocContext; use crate::fold::DocFolder; use crate::passes::Pass; <ins> use rustc_hir::def_id::LocalDefId; </ins> pub(crate) const PROPAGATE_DOC_CFG: Pass = Pass { name: "propagate-doc-cfg", run: propagate_doc_cfg, description: "propagates `#[doc(cfg(...))]` to child items", }; <del> pub(crate) fn propagate_doc_cfg(cr: Crate, _: &mut DocContext<'_>) -> Crate { CfgPropagator { parent_cfg: None }.fold_crate(cr) </del> <ins> pub(crate) fn propagate_doc_cfg(cr: Crate, cx: &mut DocContext<'_>) -> Crate { CfgPropagator { parent_cfg: None, parent: None, cx }.fold_crate(cr) </ins> } <del> struct CfgPropagator { </del> <ins> struct CfgPropagator<'a, 'tcx> { </ins> parent_cfg: Option<Arc<Cfg>>, <ins> parent: Option<LocalDefId>, cx: &'a mut DocContext<'tcx>, </ins> } <del> impl DocFolder for CfgPropagator { </del> <ins> impl<'a, 'tcx> DocFolder for CfgPropagator<'a, 'tcx> { </ins> fn fold_item(&mut self, mut item: Item) -> Option<Item> { let old_parent_cfg = self.parent_cfg.clone(); <ins> if item.kind.is_non_assoc() && let Some(def_id) = item.item_id.as_def_id().and_then(|def_id| def_id.as_local()) { let hir = self.cx.tcx.hir(); let hir_id = hir.local_def_id_to_hir_id(def_id); let expected_parent = hir.get_parent_item(hir_id); // If parents are different, it means that `item` is a reexport and we need to compute // the actual `cfg` by iterating through its "real" parents. if self.parent != Some(expected_parent) { let mut attrs = Vec::new(); for (parent_hir_id, _) in hir.parent_iter(hir_id) { let def_id = hir.local_def_id(parent_hir_id).to_def_id(); attrs.extend_from_slice(load_attrs(self.cx, def_id)); } let (_, cfg) = merge_attrs(self.cx, None, item.attrs.other_attrs.as_slice(), Some(&attrs)); item.cfg = cfg; } } </ins> let new_cfg = match (self.parent_cfg.take(), item.cfg.take()) { (None, None) => None, (Some(rc), None) | (None, Some(rc)) => Some(rc),

Related discussion:
text: Thanks for the suggestion - I moved before and (I've never built rustc/rustdoc from source, pleasantly surprised that only took just under 7min on a ThreadRipper :partyingface:) but it doesn't change anything to the generated output unfortunately :(
I observe this on public items as well: Does not show the badge at re-exports.
So from the following code: is stripped and then inlined. The stripped version contains all the correct information but the inlined one doesn't. Checking what's the best course here: either cloning the stripped item or propagating when inlining.
Code change:
<del> // The following code taken from https://stackoverflow.com/questions/2000296/innosetup-how-to-automatically-uninstall-previous-installed-version // It performs upgrades by running the uninstaller before the install ///////////////////////////////////////////////////////////////////// function GetUninstallString(): String; var sUnInstPath: String; sUnInstallString: String; begin sUnInstPath := ExpandConstant('SoftwareMicrosoftWindowsCurrentVersionUninstallRust_is1'); sUnInstallString := ''; if not RegQueryStringValue(HKLM, sUnInstPath, 'UninstallString', sUnInstallString) then RegQueryStringValue(HKCU, sUnInstPath, 'UninstallString', sUnInstallString); Result := sUnInstallString; end; ///////////////////////////////////////////////////////////////////// function IsUpgrade(): Boolean; begin Result := (GetUninstallString() <> ''); end; ///////////////////////////////////////////////////////////////////// function UnInstallOldVersion(): Integer; var sUnInstallString: String; iResultCode: Integer; begin // Return Values: // 1 - uninstall string is empty // 2 - error executing the UnInstallString // 3 - successfully executed the UnInstallString // default return value Result := 0; // get the uninstall string of the old app sUnInstallString := GetUninstallString(); if sUnInstallString <> '' then begin sUnInstallString := RemoveQuotes(sUnInstallString); if Exec(sUnInstallString, '/SILENT /NORESTART /SUPPRESSMSGBOXES','', SW_HIDE, ewWaitUntilTerminated, iResultCode) then Result := 3 else Result := 2; end else Result := 1; end; ///////////////////////////////////////////////////////////////////// procedure UpgradeCurStepChanged(CurStep: TSetupStep); begin if (CurStep=ssInstall) then begin if (IsUpgrade()) then begin UnInstallOldVersion(); end; end; end; </del>

Related discussion:
text: I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...
Grabbing the Windows download link from and swapping the for yields a functional link to the , which is nice. Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was: This yields a Rust install rooted at . However now that exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for
Can someone with access to Windows check what happens here today?
The latest version installs to instead, which works, but is a terrible default.
Triage: ! This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.
Code change:
/// Used to detect possible new binding written without `let` and to provide structured suggestion. in_assignment: Option<&'ast Expr>, <ins> is_assign_rhs: bool, </ins> /// If we are currently in a trait object definition. Used to point at the bounds when /// encountering a struct or enum.

Related discussion:
text: <!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should first check the RHS, before suggest adding . It should also avoid suggesting when code is invalid. Thanks. Something like this should also not suggest adding : cc <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not convinced the second example should be something we need to fix, but the first example should be very easy to fix.
claim
Code change:
<del> Subproject commit 5cb983338e924ec85898880d60e65f2a1291b7be </del> <ins> Subproject commit 52cebb1f8f8789b97d243c07bf4c961ca0017f7b </ins>

Related discussion:
text: 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! cc the PR reviewer, and nominating for compiler team prioritization.
Fix is on the way at