Question: } } <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]>,

<!-- 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.


Question: <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>

<!-- 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.


Question: // 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 -----------------------------------------------------

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:


Question: <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>

<!-- 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


Question: spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,

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


Question: spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,

<!-- 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.


Question: spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,

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


Question: <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>

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.


Question: 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(),

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


Question: * `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

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.


Question: 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),

From Given the following Rust code with in-line annotations of the expected behaviour: On: does not seem to be able to generate feature requirement labels on types in private modules () that are publicly reexported (). The labels do not show up on the module overview nor page, but do propagate into items like functions for the given type. This renders the type without any feature requirement, neither in the module overview: ! Nor on the page: ! Note that the label is propagated onto (does not have an explicit ), at least understood that! It is supposed to render the feature requirement for like , both in the module overview above as on the page: ! It seems tricky to combine feature requirements on the and reexport. In the case above they are the same, but what if: The type is only publicly available when and are specified. Specifying is fine but makes the contents of unreachable through the current module, specifying only should result in a "module not found" error. CC
This also affects re-exports of entire crates. Unfortunately there the fix is not clear at all, since the "parent" crate is obviously not guaranteed to have the same features as the crate being re-exported.
Within the same crate as well; it's not about the features that are enabled (though it is relevant which are available) but about the combined restrictions that are placed on the definition and reexport. Simplest I can think of is a union of all features (but gets complicated quick when inversions and vs is used) and later perhaps simplifying based on feature relations (if implies there is no need to display as requirement, if either definition or reexport requires ). That's necessary to cleanly solve crate reexports, since you effectively want to ensure that the top-level crate feature implies feature and hide it. If the whole resolver is made smart enough (perhaps this already exists, I'm not too familiar with Cargo) it could even throw warnings when there exist feature combinations that would lead to a compiler error (ie. explicitly reexporting a symbol that is not available for a certain set of features).
I wonder if this is just an ordering issue of the passes: The private modules have disappeared by the point where we pass all the data down so we don't see them.


Question: 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),

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.


Question: <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>

The .exe installer tries to install to "C:Program Files (x86)Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error. The .msi installer correctly defaults to "C:Program FilesRust <channel<version", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.
Rust should install to , just like Ant, Python, and many others. is the place for developer tools that have a known folder. is badly named (compare to ), poorly suited for command line tools, and clutters the already hideous PATH more than .
/cc
Neither Ant nor Python install to C:tools by default, and searching I can't find any reference to C:tools even being a thing? Both Python and Ant install to C:Python<Versionand C:ant, which is incredibly annoying, so please don't do that!
I might be mistaken, but installing both through stuck them in for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to when they aren't self-contained enough for .
For an OS without much filesystem hierarchy, is a decent place for developer and command-line packages, similar to on some unices. But I'd much rather see a that actually obeyed chocolatey's conventions and extracted an archive to , with no installer/registry involvement. But Rust only and installers for windows. : And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into .
The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.
Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.
We do produce tarballs for windows.
Seems like we should probably just stop producing the .exe's. That fix would go in
I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.
triage: We do not link to the .exe installer anymore, but we still produce them.


Question: <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>

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.


Question: /// 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.

<!-- 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


Question: <del> Subproject commit 5cb983338e924ec85898880d60e65f2a1291b7be </del> <ins> Subproject commit 52cebb1f8f8789b97d243c07bf4c961ca0017f7b </ins>

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


Question: if (splitAt !== -1) { const implId = savedHash.slice(0, splitAt); const assocId = savedHash.slice(splitAt + 1); <del> const implElem = document.getElementById(implId); if (implElem && implElem.parentElement.tagName === "SUMMARY" && implElem.parentElement.parentElement.tagName === "DETAILS") { onEachLazy(implElem.parentElement.parentElement.querySelectorAll( </del> <ins> const implElems = document.querySelectorAll( `details > summary > section[id^="${implId}"]`, ); onEachLazy(implElems, implElem => { const numbered = /^(.+?)-([0-9]+)$/.exec(implElem.id); if (implElem.id !== implId && (!numbered || numbered[1] !== implId)) { return false; } return onEachLazy(implElem.parentElement.parentElement.querySelectorAll( </ins> `[id^="${assocId}"]`), item => { <del> const numbered = /([^-]+)-([0-9]+)/.exec(item.id); </del> <ins> const numbered = /^(.+?)-([0-9]+)$/.exec(item.id); </ins> if (item.id === assocId || (numbered && numbered[1] === assocId)) { openParentDetails(item); item.scrollIntoView();

I spotted this in : the result links to ' which is not a valid link. Cc
cc -- I think these are supposed to be autoredirected in JS?
Okay... This happens because there's more than one and the one we want is currently named . The URL escaping is fine; the -35 is the problem.


Question: <del> // Regression test for an ICE: https://github.com/rust-lang/rust/issues/120884 </del> <ins> // Test that we don't ICE for coercions with type errors. </ins> // We still need to properly go through coercions between types with errors instead of // shortcutting and returning success, because we need the adjustments for building the MIR. pub fn has_error() -> TypeError {} //~^ ERROR cannot find type `TypeError` in this scope <ins> // https://github.com/rust-lang/rust/issues/120884 // Casting a function item to a data pointer in valid in HIR, but invalid in MIR. // We need an adjustment (ReifyFnPointer) to insert a cast from the function item // to a function pointer as a separate MIR statement. </ins> pub fn cast() -> *const u8 { <del> // Casting a function item to a data pointer in valid in HIR, but invalid in MIR. // We need an adjustment (ReifyFnPointer) to insert a cast from the function item // to a function pointer as a separate MIR statement. </del> has_error as *const u8 } <ins> // https://github.com/rust-lang/rust/issues/120945 // This one ICEd, because we skipped the builtin deref from `&TypeError` to `TypeError`. pub fn autoderef_source(e: &TypeError) { //~^ ERROR cannot find type `TypeError` in this scope autoderef_target(e) } pub fn autoderef_target(_: &TypeError) {} //~^ ERROR cannot find type `TypeError` in this scope </ins> fn main() {}

<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'', 'thread 'rustc' panicked at 'coerceborrowedpointer had no error'' File: --auto-reduced (treereduce-rust): <details<summary<strongoriginal code</strong</summary<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 --
Regression in there are no individual builds of the commits yet tho :sweat_smile:
I would guess cc


Question: use rustc_infer::infer::{self, InferCtxt, TyCtxtInferExt}; use rustc_infer::traits::util; use rustc_middle::ty::error::{ExpectedFound, TypeError}; <ins> use rustc_middle::ty::fold::BottomUpFolder; </ins> use rustc_middle::ty::util::ExplicitSelf; use rustc_middle::ty::{ self, GenericArgs, Ty, TypeFoldable, TypeFolder, TypeSuperFoldable, TypeVisitableExt,

This is a use-after-free that compiles with 1.74.0-nightly (2023-09-13 ): cc


Question: let lifetime_params: Vec<(Span, ParamName)> = this.in_scope_lifetimes .iter().cloned() <del> .map(|ident| (ident.span, ParamName::Plain(ident))) </del> <ins> .map(|name| (name.ident().span, name)) </ins> .chain(this.lifetimes_to_define.iter().cloned()) .collect(); <ins> debug!("lower_async_fn_ret_ty: in_scope_lifetimes={:#?}", this.in_scope_lifetimes); debug!("lower_async_fn_ret_ty: lifetimes_to_define={:#?}", this.lifetimes_to_define); debug!("lower_async_fn_ret_ty: lifetime_params={:#?}", lifetime_params); </ins> let generic_params = lifetime_params .iter().cloned()

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


Question: plug_infer_with_placeholders(infcx, universe, (impl1_header.impl_args, impl2_header.impl_args)); <ins> // FIXME(with_negative_coherence): the infcx has constraints from equating // the impl headers. We should use these constraints as assumptions, not as // requirements, when proving the negated where clauses below. drop(equate_obligations); drop(infcx.take_registered_region_obligations()); drop(infcx.take_and_reset_region_constraints()); </ins> util::elaborate(tcx, tcx.predicates_of(impl2_def_id).instantiate(tcx, impl2_header.impl_args)) .any(|(clause, _)| try_prove_negated_where_clause(infcx, clause, param_env)) }

<!-- 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 expected to see this happen: Compiles successfully Instead, this happened: <!-- 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. --: label A-coherence F-negative_impls requires-nightly T-compiler
I'll look into it


Question: // @has impl_trait/fn.func2.html // @has - '//pre[@class="rust item-decl"]' "func2<T>(" // @has - '//pre[@class="rust item-decl"]' "_x: impl Deref<Target = Option<T>> + Iterator<Item = T>," <del> // @has - '//pre[@class="rust item-decl"]' "_y: impl Iterator<Item = u8> )" </del> <ins> // @has - '//pre[@class="rust item-decl"]' "_y: impl Iterator<Item = u8>, )" </ins> // @!has - '//pre[@class="rust item-decl"]' 'where' pub use impl_trait_aux::func2;

Take a look at the docs for : Rustdoc is making good choices for whether to wrap the declarations ! But when it wraps, it doesn't include a trailing comma on the last parameter. I think it should, because the default style guide wants a comma there. (And rustdoc should continue not putting a trailing comma when the declaration is shown as a single line.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim


Question: return; } <del> let is_error = match self.level { </del> <ins> self.handler.emit_db(&self); self.cancel(); } pub fn is_error(&self) -> bool { match self.level { </ins> Level::Bug | Level::Fatal | Level::PhaseFatal |

Minimal example: Error message (ran in playground): Tested on nightly as well ()
Related:
twice without checking the return value. Modify it to return and check where it is being called ether both calls have returned an (cancel one, emit the other, return ), wether only one was created (emit it, return ) or none has (return ).
I'll fix this, thanks for the instruction!
I would happily have a go at this, if that's ok with
Sure go for it!
have you had time to work on this? If not could I give it a go? :)
I totally thought I was going to have time, but I had a crazy week at work this week. Go ahead and give it a go :) I'll find another bug to work on when I definitely have time
It looks like the PR to fix this was merged but has a few dangling threads. There seems to be some confusion about short-circuiting functionality and the necessity of the patch and also the error count still reads 2 rather than 1. Should a new issue be opened with those issues and this issue closed?


Question: <ins> error[E0451]: field `0` of struct `Box` is private --> $DIR/issue-82772.rs:5:15 | LL |     let Box { 0: _, .. }: Box<()>; |               ^^^^ private field error[E0451]: field `1` of struct `Box` is private --> $DIR/issue-82772.rs:6:15 | LL |     let Box { 1: _, .. }: Box<()>; |               ^^^^ private field error[E0451]: field `1` of struct `ModPrivateStruct` is private --> $DIR/issue-82772.rs:7:28 | LL |     let ModPrivateStruct { 1: _, .. } = ModPrivateStruct::default(); |                            ^^^^ private field error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0451`. </ins>

<!-- 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
Seems to be the indicated function:
.
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Oh this is ugly x) Reading the PR, the problem is that there are two ways to match a Box: via a box-pattern or via . But we can't know which will be used based on the type only. Current code assumes box-patterns, hence the error. The PR works because luckily all the fields of are private. If you tried pattern-matching within the module that defines , you'd get crazy results like (actually wouldn't even typecheck): We'll need to figure out a real solution when we implement generalized Deref patterns...
in that case we should open a new ticket for that work, tagged something like or something.


Question: | LL |     semitransparent!; |                    + <ins> help: a unit struct with a similar name exists | LL |     SemiTransparent; |     ~~~~~~~~~~~~~~~ </ins> error[E0423]: expected value, found macro `opaque` --> $DIR/rustc-macro-transparency.rs:30:5 | <ins> LL |     struct Opaque; |     -------------- similarly named unit struct `Opaque` defined here ... </ins> LL |     opaque; |     ^^^^^^ not a value |

Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should include a note suggesting the variant with the same name (but different case):
label +C-enhancement +D-newcomer-roadblock
This only doesn't Just Work because the Levenshtein thing is case sensitive, right? There is some special-casing for case-insensitive suggestions but afaict it only applies if the case-sensitive Levenshtein distance is also already low, which seems wrong at first glance.
im working on this Edit: I'm not working on this anymore because I ran out of time getting past incremental compilation / llvm errors after a rebase.
Okay, judging by , this is explicitly not supposed to work. shrug emoji Edit: Okay, maybe that test case didn't really care. The use of case-insensitive match as tie breaker for equal levenshtein distance only was introduced with afaict.


Question: sig.decl.has_self(), sig.decl.inputs.iter().map(|Param { ty, .. }| (None, &**ty)), &sig.decl.output, <del> ) </del> <ins> ); this.record_lifetime_params_for_async( fn_id, sig.header.asyncness.opt_return_id(), ); </ins> }, ); return;

Example: yields <details<summaryBacktrace</summary</details
cc and
This has to do with late-bound regions and RPITITs. I have a fix, but it's probably not right nor is it cleaned up much. I'll put it up for scrutiny soon though.
Actually nvm, it was a silly little resolver bug.
label +I-ICE +C-bug


Question: sig.decl.has_self(), sig.decl.inputs.iter().map(|Param { ty, .. }| (None, &**ty)), &sig.decl.output, <del> ) </del> <ins> ); this.record_lifetime_params_for_async( fn_id, sig.header.asyncness.opt_return_id(), ); </ins> }, ); return;

I'm seeing an internal compiler error on the following input (found by ):
Report from : regressed nightly: nightly-2020-02-07
It looks like caused the regression. (The error happens at but not at .) cc
The specific commit where the error starts happening is .
triage: P-high. Removing nomination. Added regression stable-to-nightly tag.
Fixed by


Question: <ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

root: updns-0.0.6: v.
triage: P-high. Nominating for discussion.
self-assigned for investigation in short term (as in, next two or three days). However I suspect someone from will be a better choice to investigate this.
We should try to bisect this
used . Determined: searched nightlies: from nightly-2019-11-26 to nightly-2020-01-03 regressed nightly: nightly-2019-12-01 searched commits: from to  regressed commit:
is a rollup commit of the following PR's: I'm guessing this is due to PR
I'm still working on reducing this down to something that I could put into the playpen. However, one interesting thing I've found locally during my reduction: This version of the will signal an analogous compilation error: but if I lift the first argument out to a separate -binding (i.e. change it to use above, or the sub-expression out to a separate -binding (i.e. change the argument expression to use above), then the error goes away. I'll admit that I don't know all the details of how the fn-transformation works to support , but I strongly suspect that if this kind of local code change can make an error go away, then that represents a weakness somewhere (either in the fn-transformation, or in the borrowck).
Okay in the details block is a standalone version suitable for the : <details</detailsand the error it generates:
So this does seem like somewhat clear (expected?) fallout from PR : a use of a in a generator witness will be recorded as a unsafe pointer , and then is never , but the method requires that the task you give it is . I believe we can readily update the crate in question to avoid using the in the expression under the RHS of . But I do wonder whether we can/should improve the diagnostics here to try to guide the user towards such a solution ...?
I might have worded this too strongly, and/or over-reduced my example. In particular, its easy to move around the access to . But the borrow of may be trickier to deal with.
I'll have a look at addressing this with another approach I considered for . If that doesn't work out then I'll have a look at the error message.


Question: <ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

The patch linked is enough to fix the crate in question, but I'm all for finding an in-compiler solution if we can do it soundly.
OK. I'm going to write some things up because I've changed my mind a bunch of times about how/if this can be fixed in MIR building and I don't want to keep forgetting things. Generators store values that if their value needs to be preserved across a yield. These values need to be visible for auto-traits, for example a generator may be resumed on a different thread after it yields, and so cannot be if any of theses values isn't . There are two passes that determine which values can be included in the generator: A pass that runs as part of typeck that walks the HIR to find the types of expressions and then checks for yields in the values scope (as determined by the RegionScopeTree). The types recorded here are stored in the GeneratorWitnesss type contained in the generator, which is then used for auto trait checking. This notably uses the types of expressions that HIR sees. The MIR transform that lowers the generator to a state machine. This determines the values that the generator actually stores. As a check for the compiler, we assert that any types that we capture here are included in the witness type (we don't know all auto traits, so can't check only for them). After statics no longer have a special representation in MIR. They are instead lowered to a dereference of a pointer to the given static: is lowered as if it were: Which becomes: The example above is somewhat deceptive in that the temporary that holds the pointer is used immediately after it's assigned. In this case it cannot end up in the generator since it's not live across any user code. However this isn't true in all cases, index and match expressions allow running user code while the pointer is live: In these cases MIR has to put the temporary pointer into the generator state and promptly ICEs. The obvious solution now is make type checking record the new pointer types in the generator witness in these cases. Unfortunately HIR is not a great tool for specifying "these cases". The methods that the region scope tree provides in HIR are either usually far too large (the "temporary scope") or occasionally too small (the "enclosing scope"). went for the sound but rather approximate approach, leaving us here.


Question: <ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

One idea might be to try changing MIR building so that the temporary is never live across user code. For example, one might change the lowering as follows However working out how to do this for in a reasonable to implement way is harder. MIR actually already contains an escape hatch for values that are in the MIR but aren't in the HIR in the form of a flag (called ) on the variable. We currently use it for drop flags and boxes created by expressions. It's unclear what exactly the difference is between is. I guess one could argue that auto traits are for layout introspection and this would be further breaking that. I think that's everything for now.
Visiting from triage. were you planning to work on this further?
It's definitely tempting to take advantage of the constraints around statics to just declare these equivalent, and use the flag to get out of this. While I don't see any soundness issues around that, I also don't quite trust myself to get this right :) Can you expand on this? I'm not sure I follow.
Another solution that comes to mind relies on the fact that these pointers never need to be stored in a generator. They are consts, and the temporaries containing them shouldn't ever be mutated. We could add semantics for "const temporaries" to MIR, and never store them inside generators. The semantics would (hopefully) be simple: defined once and assigned a value that doesn't depend on any other temporaries; never mutated or borrowed mutably. We can move the statements defining them to the top of the function inside the generator transform. But that would be adding more semantics and special casing to MIR to fix a change which removed extra semantics and special casing, so I'm not sure if that's what we want :)
The argument is that the given the following auto trait we guarantee that if then there are no raw pointers directly stored in an instance of . If we make that guarantee then using internal in generators would not be OK. I would argue that we're not making such (or really any) guarantees with user defined auto traits.
Yeah, I don't think auto traits should expose layout implementation details of generators. And this really does seem like a pure implementation detail -- it doesn't have any bearing on what kinds of (unsafe) operations are allowed on a generator, like a self-reference would.


Question: <ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

cc
So, I've been putting off commenting here to let these ideas sit, but let me leave a comment. I think I've reached a conclusion. TL;DR. I think we should mark these types as internal, but I think there are some better options for fixing this in the medium term, and this interaction should be taken into account as part of the "MIR 2.0" effort to rework places. Auto traits weren't really intended as a tool for probing layout, but rather semantic considerations. This is why traits like can be implemented by users. So I don't really think that auto traits give any sort of guarantee about their layout. Rather, this question is about is simply "what are the constituent types exposed by a generator", and this should correspond to the types that user code can directly access. The raw pointers here are not directly accessible. The values that are accessible are the "live values" that the user's code may later use -- and of course the code currently makes the constituent types be a superset of those, based on the AST structure. Of course, the real root cause of this error is a simplifying change to the definition of in MIR. It used to be that a Place had this grammar: but now we changed to just , which is why we are required to introduce the new temporary (and that holds the address of the ). As we've been talking about this change, I've been saying that we should be considering the older definition of as the one that is used by various analyses (and in particular by borrow check). This particular transformation of removing statics doesn't affect borrow check, but we failed to take into account the fact that the set of live variables can effect the definition of what is live in a generator. In particular, compiling for some expression requires a temporary unless corresponds to a place -- those places used to include statics like , but they no longer do. But I think that for analysis purposes, it should appear as if they do. We could fix this in two ways. We could write some code motion / duplication that takes temporaries like that are live across a yield and creates a fresh variable after the yield. The idea would be to make them never* live across a yield.


Question: <ins> // build-pass #![feature(generators)] static mut A: [i32; 5] = [1, 2, 3, 4, 5]; fn is_send_sync<T: Send + Sync>(_: T) {} fn main() { unsafe { let gen_index = static || { let u = A[{ yield; 1 }]; }; let gen_match = static || match A { i if { yield; true } => { () } _ => (), }; is_send_sync(gen_index); is_send_sync(gen_match); } } </ins>

We can do this because that operation is a compile-time constant, really, and thus the value doesn't need to be live across a yield. This might be worth doing as a size optimization regardless. Secondly, some of the proposals we've been kicking around for going further with simplifying include the idea of a distinct sort of temporaries that explicitly represent a "partially constructed that hasn't been used by the user". The idea was to allow borrowck (and other analyses) to trivially reconstruct the . We might want to add this interaction with auto-traits into the consideration for that design, and maybe it takes us some place (e.g., these special temporaries are not considered live for the purposes of auto traits). Having written out both of those options, though, I sort of lean towards the first, at least for this specific issue.
I think these references and raw pointers created by MIR construction should be marked as . They are not visible at the language level. They can be viewed as just prefetching the address of a static, so the compiler could pick any type it likes for it (, , , some compiler internal type) so it must not affect auto trait inference. Drop flags are ignored for similar reasons. You cannot use an auto trait like this to detect them: So I think that should be reverted and the temporary static references should be marked as .
Note: opened instituting this change and I r+'d it, since fixing the regression seems pretty important and time is of the essence; there is general consensus here on the thread; this is only restoring older behavior. In particular, there were some suggestions that this might be a lang team issue; I think there is some 'intersection' and I don't want the perception that I'm trying to shortcircuit discussion. That said, I also think this is primarily a compiler team matter, since it's a deviation from the old behavior, and further this deviation was caused by altering the MIR away from the "natural, Rust-based" definition and towards a lower-level definition.


Question: <ins> // Copyright 2015 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. macro_rules! invalid { _ => (); //~^ ERROR Invalid macro matcher } fn main() { } </ins>

A simple malformed macro makes the compiler crash. Code: Playpen error: Playpen:
Another case: Playpen:
I had a crash in a bad macro which hits the same bug as Note that his/her error has the following which is a different stack trace: I'm on the latest beta; not nightly.
I think you and I are getting a different panic from this bug. I've opened since the panic is in a different location in the code.


Question: <ins> // build-pass #![feature(dyn_star)] //~^ WARN the feature `dyn_star` is incomplete and may not be safe to use and/or cause compiler crashes fn main() { let x: dyn* Send = &(); let x = Box::new(x) as Box<dyn Send>; } </ins>

<!-- 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
label +F-dyn_star
:laughing: the code thinks that this is a upcast, I think, rather than an unsize coercion. shouldn't be too hard to fix, but I may leave it for someone else. edit: nvm I'll just fix it.


Question: <ins> // build-pass // compile-flags: --crate-type lib // Regression test for ICE which occurred when const propagating an enum with three variants // one of which is uninhabited. pub enum ApiError {} #[allow(dead_code)] pub struct TokioError { b: bool, } pub enum Error { Api { source: ApiError, }, Ethereum, Tokio { source: TokioError, }, } struct Api; impl IntoError<Error> for Api { type Source = ApiError; fn into_error(self, error: Self::Source) -> Error { Error::Api { source: (|v| v)(error), } } } pub trait IntoError<E> { /// The underlying error type Source; /// Combine the information to produce the error fn into_error(self, source: Self::Source) -> E; } </ins>

I'm trying to build my crate on nightly, and I'm getting a compiler panic. I bisected several nightly builds to try and narrow down when the problem started. The last known good nightly was , and the first failing was The panic also occurs in . The crates causing the panic are available here:
cc
triage: P-high, removing nomination label.
Minimal repro:
As some info, I've narrowed down the offending commit to –– most likely the changes in .


Question: use core::intrinsics::abort; use core::iter; use core::marker::{PhantomData, Unpin, Unsize}; <del> use core::mem::{self, align_of_val, size_of_val}; </del> <ins> use core::mem::{self, align_of_val_raw, size_of_val}; </ins> use core::ops::{CoerceUnsized, Deref, DispatchFromDyn, Receiver}; use core::pin::Pin; use core::ptr::{self, NonNull};

I tried this code: When I run it under , I get this: Creating a reference from such pointer looks suspicious indeed. I could send a pull request that adds a condition there, but I want to ask first if this is being done because „we are , we can“, or if this is something that really should be fixed. : (but I've looked at the git sources and the thing is still there) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think it should only be UB to dereference the pointer you get from , so I'm not sure why Miri thinks there's UB happening. Just in case, prioritize
Because that pointer is being turned into a reference to feed to internally. And references are supposed to be always valid.
Looks like fixed this for but missed it in .
Yes, seems this needs to use .
I renamed the issue to reflect that the bug is actually in (which calls).
Cc
Assuming you use the default flags for Miri, that change should not be required to make Miri pass, so I'd be surprised if doing the same change for would make any difference here. If it does, that seems like a bug in Miri that I should investigate.
Ah, but the in is indeed a problem (the PR was mostly about so I got side-tracked; the is what should not have any effect here). Miri ensures that references are at least dereferencable, so yeah that would explain the problem here. Good catch!
Yep, I apparently missed this somehow in . Fixing the indicated line to use should be enough to fix it; I'm preparing the patch currently. claim
Hm, Miri still complains, even after the fix landed... it seems Miri doesn't like being called with dangling pointers. I'll have to look into this.
IIRC, when , I changed the type of the intrinsic to take a raw pointer rather than a reference, but miri wasn't touched, so that would make sense miri's still expecting a proper reference.
Patch arrived really fast, we are assigning "post-mortem" a priority of as discussed as part of the and removing .


Question: } } } <ins> declare_lint! { pub UNNECESSARY_EXTERN_CRATE, Allow, "suggest removing `extern crate` for the 2018 edition" } pub struct ExternCrate(/* depth */ u32); impl ExternCrate { pub fn new() -> Self { ExternCrate(0) } } impl LintPass for ExternCrate { fn get_lints(&self) -> LintArray { lint_array!(UNNECESSARY_EXTERN_CRATE) } } impl<'a, 'tcx> LateLintPass<'a, 'tcx> for ExternCrate { fn check_item(&mut self, cx: &LateContext, it: &hir::Item) { if let hir::ItemExternCrate(ref orig) =  it.node { if it.attrs.iter().any(|a| a.check_name("macro_use")) { return } let mut err = cx.struct_span_lint(UNNECESSARY_EXTERN_CRATE, it.span, "`extern crate` is unnecessary in the new edition"); if it.vis == hir::Visibility::Public || self.0 > 1 || orig.is_some() { let pub_ = if it.vis == hir::Visibility::Public { "pub " } else { "" }; let help = format!("use `{}use`", pub_); if let Some(orig) = orig { err.span_suggestion(it.span, &help, format!("{}use {} as {}", pub_, orig, it.name)); } else { err.span_suggestion(it.span, &help, format!("{}use {}", pub_, it.name)); } } else { err.span_suggestion(it.span, "remove it", "".into()); } err.emit(); } } fn check_mod(&mut self, _: &LateContext, _: &hir::Mod, _: Span, _: ast::NodeId) { self.0 += 1; } fn check_mod_post(&mut self, _: &LateContext, _: &hir::Mod, _: Span, _: ast::NodeId) { self.0 += 1; } } </ins>

We need to add an epoch lint for It will lint , suggesting removal in root mods, and replacement with in non-root mods. This is blocked on the ability to elide extern crate in the first place.
It is also blocked on a feature to force linkage of a crate, see this comment and the discussion afterwards:
cc
I think the lint should be by default off in cases with , such as: This is because of the ergonomics problems with macros and the new macro import system, expressed here: It's bewildering for the migrating users if a lint tells them not to use the syntax, but then finding out that many of the macros out there have downright bad ergonomics with the import syntax. (For clarification: I think this is an undesirable state of affairs, and we should be linting against all , but if we do that, the ergonomics problem with the macro import should be fixed somehow.)
I don't think we want at all, really. If we want to import macros, we should have another means of doing it. Otherwise we have an inconsistency. So yes, I think I agree with your last paragraph above all,
I've discussed this a bit in the tracking issue for the macros import system:
Thanks, you expressed the exact concern I had in a concise way.
Another thing this needs to lint is unlisted crates that are included in that clash with existing modules. I'm not quite sure on what the story needs to be here cc
Does it? I've thought one of the things the path clarity RFC was about was to have separate namespaces for top level modules and extern crates.
The current plan has changed a bit so I'm not sure if that is still true. (If stuff does change it will probably be RFCd again, there's a bit of experimentation going on)
Sigh I hope we won't discuss all of this crap all over again... I don't enjoy that but it is not me who wants to change things.
I've hidden your last comment, which I found hostile and unconstructive.
IDK what has been hearing, but for me, this is the latest state of consensus on that issue, and it seems to have separate namespaces: is that the case? You seem unresponsive on IRC that's why I'm using github.
That's mostly the latest state of consensus, yeah. Some tweaks have been made iirc. Everything has been implemented.


Question: fn hash_stable<W: StableHasherResult>(&self, hcx: &mut StableHashingContext<'gcx>, hasher: &mut StableHasher<W>) { <del> let hash_spans = match self.node { </del> <ins> let (is_const, hash_spans) = match self.node { </ins> hir::ItemStatic(..)      | <del> hir::ItemConst(..)       | hir::ItemFn(..)          => { hcx.hash_spans() </del> <ins> hir::ItemConst(..)       => { (true, hcx.hash_spans()) } hir::ItemFn(_, _, constness, ..) => { (constness == hir::Constness::Const, hcx.hash_spans()) </ins> } hir::ItemUse(..)         | hir::ItemExternCrate(..) |

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:


Question: } impl<T: ?Sized+Unsize<U>, U: ?Sized> CoerceUnsized<Box<U>> for Box<T> {} <ins> #[stable(feature = "box_slice_clone", since = "1.3.0")] impl<T: Clone> Clone for Box<[T]> { fn clone(&self) -> Self { let mut new = BoxBuilder { data: RawVec::with_capacity(self.len()), len: 0 }; let mut target = new.data.ptr(); for item in self.iter() { unsafe { ptr::write(target, item.clone()); target = target.offset(1); }; new.len += 1; } return unsafe { new.into_box() }; // Helper type for responding to panics correctly. struct BoxBuilder<T> { data: RawVec<T>, len: usize, } impl<T> BoxBuilder<T> { unsafe fn into_box(self) -> Box<[T]> { let raw = ptr::read(&self.data); mem::forget(self); raw.into_box() } } impl<T> Drop for BoxBuilder<T> { fn drop(&mut self) { let mut data = self.data.ptr(); let max = unsafe { data.offset(self.len as isize) }; while data != max { unsafe { ptr::read(data); data = data.offset(1); } } } } } } </ins>

We need to find a way to implement Clone for where . In user code, "cloning" such a box manually is simple: will do it with a short roundtrip through which should be unproblematic. In the rust distribution, we can't impl Clone easily since the tools to do so are in libcollections but the Box type lives in liballoc.
You do not need vec for the implementation. Something like the following would work: Note that because can panic it is required to keep track of the partial result so the correct stuff is dropped.
Yes, that's nice that it can be carefully solved by essentially extracting the needed parts from what Vec does. But the Box code is otherwise so clean, it doesn't feel like the right way to do it.
You're welcome to suggest an alternative but I doubt it can be done in a manner that is both correct and significantly cleaner :)
Your fundamental analysis is great: just isn't an exception safe representation while filling it with elements. It needs to keep track of the fill level, so a representation like Vec or BoxBuild is needed...
Clone is also wanted for , but that can be much simpler: There is no panic issue, and it can use a simple memcpy of the data.


Question: css_file_extension: css_file_extension.clone(), markdown_warnings: RefCell::new(vec![]), created_dirs: RefCell::new(FxHashSet()), <ins> sort_modules_alphabetically, </ins> }; // If user passed in `--playground-url` arg, we fill in crate name here

Instead it should use the order that appear in the crate file. Even better, it should allow adding section headers (with a description) between them. Hypothetically: And get something like this: This would make both the source code and the documentation more accessible as the modules would be presented in a comprehensible order, with some description of each related group of modules. Edit: Rename issue to reflect that this isn't an either-or. Alphabetical order is useful, but so is programmer-specified order (to make the code accessible for newcomers) and Rustdoc should support both - see the thread below.
Shouldn't related modules be nested in submodules rather than logically ordered in the source? Finding things in long non-ordered lists is a real pain.
Yeah, I'm going to vote "alphabetical".
Hmmm. I pretty sure I put a comment here, and now its gone. Strange. Anyway. Here it goes again. Alphabetical order == random order. That's great when you know what you are looking for and just want to find it. When coming to a new non-trivial code base, being presented the content in random order is just about the worst possible way to access it. Nested modules allow us to group related modules together, and that's a good thing. If you have a long list of modules, certainly, group them. But this doesn't solve the problem. You now have a TOC where each level is randomized, which is still inaccessible. Searching for a function or module by name is an important use case, sure. But being able to access a new code base is as important, if not more so. Looking up a name in a short non-alphabetized list (at each level) isn't too hard, and one can always compensate for the lack of an alphabetical index by using ^F. Trying to understand a system presented in random order is next to impossible, and one can not compensate for the lack of a comprehensible order in a large system. If there was a way to specify the order of the entries in each level, which we agree should only contain "a few" entries, then the TOC would become accessible. If one could even add a bit of annotation for each level, so much the better.


Question: css_file_extension: css_file_extension.clone(), markdown_warnings: RefCell::new(vec![]), created_dirs: RefCell::new(FxHashSet()), <ins> sort_modules_alphabetically, </ins> }; // If user passed in `--playground-url` arg, we fill in crate name here

The annotated TOC would serve as a very accessible way for a newcomer to understand the code base. And, this doesn't rule out also generating an alphabetically sorted reference index, beside the TOC. All good books do both - a TOC in reasonable order and an index for looking up data by name. We shouldn't have to choose, we should be able to get both. So, I misnamed the issue. It should be "Rustdoc shouldn't list modules only alphabetically".
Agreed. Can someone rename the title?
Rename done.
Visiting for triage. Minor, but still an issue.
Triage, still listed alphabetically. Here's a sample source file: !


Question: /// of each element in the array. /// /// On arithmetic overflow, returns `None`. <ins> #[inline] </ins> pub fn repeat(&self, n: usize) -> Option<(Self, usize)> { let padded_size = match self.size.checked_add(self.padding_needed_for(self.align)) { None => return None,

Rustc used to be able to replace with a constant when optimizing, not at the moment. It simply looks like a Layout method that is not inlinable. (This is a regression strictly speaking — stable & beta can do this optimization, but not nightly.) Code to reproduce:
Are there any ways to write automated tests to check for "regressions" like this? Assertions against LLVM bitcode?
Yes can be used for this, e.g. Assuming this is run against the bitcode after optimization, that is.
cc -- seems LLVM related
Nope. Just () that is not marked as inline.
cc
I didn't confirm that making Layout::repeat as inline fixes this, so please confirm that/add a test before closing.


Question: false } }; if !eligible { return Ok(None); } <ins> // HACK: We may have overlapping `dyn Trait` built-in impls and // user-provided blanket impls. Detect that case here, and return // ambiguity. // // This should not affect totally monomorphized contexts, only // resolve calls that happen polymorphically, such as the mir-inliner // and const-prop (and also some lints). let self_ty = rcvr_args.type_at(0); if !self_ty.is_known_rigid() { let predicates = tcx .predicates_of(impl_data.impl_def_id) .instantiate(tcx, impl_data.args) .predicates; let sized_def_id = tcx.lang_items().sized_trait(); // If we find a `Self: Sized` bound on the item, then we know // that `dyn Trait` can certainly never apply here. if !predicates.into_iter().filter_map(ty::Clause::as_trait_clause).any(|clause| { Some(clause.def_id()) == sized_def_id && clause.skip_binder().self_ty() == self_ty }) { return Ok(None); } } </ins> // Any final impl is required to define all associated items. if !leaf_def.item.defaultness(tcx).has_value() { let guard = tcx.sess.delay_span_bug(

<!-- 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: I expected to see this happen: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high


Question: // For LTO purposes, the bytecode of this library is also inserted // into the archive. let bc = obj_filename.with_extension("bc"); <ins> let bc_deflated = obj_filename.with_extension("bc.deflate"); </ins> match fs::File::open(&bc).read_to_end().and_then(|data| { <del> fs::File::create(&bc).write(flate::deflate_bytes(data).as_slice()) </del> <ins> fs::File::create(&bc_deflated).write(flate::deflate_bytes(data).as_slice()) </ins> }) { Ok(()) => {} Err(e) => {

Passing rustc the flag and passing may produce different files (that is, outputs). This is true of rust-core (see below), though was not the case for a simpler ("Hello, world!") test file. Test script: Diff output indicates binary files differ. Tested with , rust-core on . rustc compiled from master on Arch Linux. If this is, in fact, expected behavior- sorry for the trouble, unexpected to me.
Can you provide a diff between the outputs? This is likely a known issue, but I would like to be sure.
.bc is a binary format, so just gives "Binary files and differ" as its output. On my machine, is 19K and is 62K. I'm not familiar enough with the format to extract much more data.
I note the difference persists when the second line is (two separate flags), though both produce both artifacts.
Can you pass and diff those outputs?
With emit flags as and respectively, there is no difference in and (according to diff.)
It seems that every bytecode is invalid only when a rlib is produced. It stopped working between rust-git-0.9.1301 and 1362 (shortly before 2014-02-23 15:37:05 -0800). Going back thorugh the log, I found I believe that creates deflated bytecode. Perhaps should be stored with extension or .


Question: /// # Examples /// /// ```no_run <del> /// #![feature(rw_exact_all_at)] </del> /// use std::io; /// use std::fs::File; /// use std::os::unix::prelude::FileExt;

The and traits contain convenience methods and wrapping and . This issue tracks addition of similar methods to trait's and . This is implemented in .
if this is a tracking issue, maybe it should have the label
We should eventually add similar methods to .
I know nothing about developing on Windows so I can't do it myself but I guess a PR would be accepted. Can we stabilize this? Is there anything that still needs to be done?
Seems reasonable to me! fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
What's the next step? Should I make a PR to stabilize? Sorry but I don't fully understand how things work yet.
indeed that should be all that's necessary! If you'd like to make the PR you're also more than welcome to do so!


Question: <ins> error: expected one of `.`, `?`, `]`, or an operator, found `:` --> $DIR/range-index-instead-of-colon.rs:4:17 | LL |     &[1, 2, 3][1:2]; |                 ^ expected one of `.`, `?`, `]`, or an operator | help: you might have meant a range expression | LL |     &[1, 2, 3][1..2]; |                 ~~ error: aborting due to 1 previous error </ins>

Having written Python for several hours, I made this mistake and couldn't realize what was wrong for a while. No response claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm not sure whether it's worth to fix this right now. will significantly change this code, basically requiring a rewrite of this diagnostic.
Agreed, it's reasonable to wait for type ascription removal. Thanks for the info!
Now we should fix this error message: is not OK, we'd better suggest to use . I think you need to add proper logic for this part of code:


Question: self.insert_def_id(def.non_enum_variant().fields[index].did); } ty::Tuple(..) => {} <del> _ => span_bug!(lhs.span, "named field access on non-ADT"), </del> <ins> ty::Error(_) => {} kind => span_bug!(lhs.span, "named field access on non-ADT: {kind:?}"), </ins> } }

<!-- ICE: Rustc '' 'error: internal compiler error: named field access on non-ADT', 'error: internal compiler error: named field access on non-ADT' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: 22 | let buf: &mut [*const dyn Foo] = &mut [&u8, &u8.0, &u32, &u32.0]; [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
mmh this bisects to cc


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> pub use self::sub::{Bar, Baz}; pub trait Trait { fn foo(&self); <ins> type Assoc; const CONST: u32; </ins> } struct Foo; impl Foo { pub fn new() {} <ins> pub const C: u32 = 0; </ins> } mod sub {

with rustc 1.0.0-nightly ( 2015-03-01) (built 2015-03-01)
This is still an issue
Still an issue in 1.0.0.
This is still an issue in 1.3.0-nightly: $ rustc error: internal compiler error: unexpected panic thread 'rustc' panicked at 'assertion failed: <= ()', stack backtrace: 1: 0x7fd6c19bd5ee - sys::backtrace::write::h04a6ced565b26815Lqs 2: 0x7fd6c19c5214 - panicking::onpanic::h521f84b604e22dfel8w 3: 0x7fd6c198804e - rt::unwind::beginunwindinner::hd3dee614a0e1c16cZNw 4: 0x7fd6c1988d7c - rt::unwind::beginunwindfmt::ha4ce6704c81423045Mw 5: 0x7fd6c19c4dd6 - rustbeginunwind 6: 0x7fd6c1a15bb4 - panicking::panicfmt::he89ea3094b3178e919B 7: 0x7fd6c1a0f9dd - panicking::panic::h9e565ee21070221by8B 8: 0x7fd6c11f8271 - astconv::finishresolvingdeftoty::h03670159ac2fefe7aTv 9: 0x7fd6c11b6340 - astconv::asttytoty::hb2c49d2cf31c029bYUv 10: 0x7fd6c1189eed - check::closure::checkexprclosure::hbce85e7beaf0ebd52zl 11: 0x7fd6c11d360b - check::checkexprwithunifier::h16314096699859592584 12: 0x7fd6c11f998b - check::checkdeclinitializer::h491ede37e45bce9e84r 13:


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> pub use self::sub::{Bar, Baz}; pub trait Trait { fn foo(&self); <ins> type Assoc; const CONST: u32; </ins> } struct Foo; impl Foo { pub fn new() {} <ins> pub const C: u32 = 0; </ins> } mod sub {

0x7fd6c11f9a4d - check::checkdecllocal::h1c782249285c9ae3m6r 14: 0x7fd6c11f9c79 - check::checkstmt::h48bf6ea3f412b86bf8r 15: 0x7fd6c11a91b3 - check::checkblockwithexpected::h072b2c4702c43b1cjcs 16: 0x7fd6c118bef4 - check::checkfn::h8218f9adb3734183iQn 17: 0x7fd6c11a35ca - check::checkbarefn::h3c567a2d1339f838RFn 18: 0x7fd6c11a1523 - check::checkitembody::h8e17e6521c30131ay6n 19: 0x7fd6c11a31e4 - check::checkitemtypes::h62e908b1d9f74b39oDn 20: 0x7fd6c12609b8 - checkcrate::h594ee0148d251222uZC 21: 0x7fd6c1f1dc69 - driver::phase3runanalysispasses::closure.


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> pub use self::sub::{Bar, Baz}; pub trait Trait { fn foo(&self); <ins> type Assoc; const CONST: u32; </ins> } struct Foo; impl Foo { pub fn new() {} <ins> pub const C: u32 = 0; </ins> } mod sub {

22: 0x7fd6c1f1c633 - middle::ty::ctxt<'tcx::createandenter::h349256048753845929 23: 0x7fd6c1f17a17 - driver::phase3runanalysispasses::h15521018079403107052 24: 0x7fd6c1efa266 - driver::compileinput::hbf698b02349f7ce3Tba 25: 0x7fd6c1fd3ed3 - runcompiler::hd724b5fef3441688y7b 26: 0x7fd6c1fd18ae - boxed::F.FnBox<A::callbox::h6609070342514802751 27: 0x7fd6c1fd10f9 - rt::unwind::try::tryfn::h10774555836369096370 28: 0x7fd6c1a3ed48 - rusttryinner 29: 0x7fd6c1a3ed35 - rusttry 30: 0x7fd6c19b08a7 - rt::unwind::try::innertry::hb0d7a3eb324339ceSJw 31: 0x7fd6c1fd130b - boxed::F.FnBox<A::callbox::h18179817771297192954 32: 0x7fd6c19c3e71 - sys::thread::Thread::new::threadstart::hf8c7448e27294ed0PTv 33: 0x7fd6bb60f353 - startthread 34: 0x7fd6c161ebfc - _clone 35: 0x0 - <unknown
$ rustc --version rustc 1.3.0-nightly ( 2015-06-30)
This problem has gone away for me now. It may have been from mixing versions? It may have gone away after a .
It is still an issue on nightly according to the playpen:
You're right. I must have been in the wrong project.
I just ran into the same assertion (with both stable 1.1 and nightly 1.3), but with different code.


Question: // option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(associated_consts)] </ins> pub use self::sub::{Bar, Baz}; pub trait Trait { fn foo(&self); <ins> type Assoc; const CONST: u32; </ins> } struct Foo; impl Foo { pub fn new() {} <ins> pub const C: u32 = 0; </ins> } mod sub {

Would it help if I try to create another minimal working example and post it here or a new bug report? This is my backtrace: didn't help.
Okay here it is: Unfortunately it has something to do with glium, so I guess this doesn't help much :/
May be related, not sure: (rustc 1.2.0 ( 2015-08-03))
minimized:


Question: <ins> # ignore-cross-compile include ../tools.mk # With the upgrade to LLVM 16, this was getting: # #   error: Cannot represent a difference across sections # # The error stemmed from DI function definitions under type scopes, fixed by # only declaring in type scope and defining the subprogram elsewhere. all: $(RUSTC) lib.rs --test -C lto=fat -C debuginfo=2 -C incremental=$(TMPDIR)/inc-fat </ins>

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


Question: <ins> # ignore-cross-compile include ../tools.mk # With the upgrade to LLVM 16, this was getting: # #   error: Cannot represent a difference across sections # # The error stemmed from DI function definitions under type scopes, fixed by # only declaring in type scope and defining the subprogram elsewhere. all: $(RUSTC) lib.rs --test -C lto=fat -C debuginfo=2 -C incremental=$(TMPDIR)/inc-fat </ins>

<!-- 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.


Question: <ins> # ignore-cross-compile include ../tools.mk # With the upgrade to LLVM 16, this was getting: # #   error: Cannot represent a difference across sections # # The error stemmed from DI function definitions under type scopes, fixed by # only declaring in type scope and defining the subprogram elsewhere. all: $(RUSTC) lib.rs --test -C lto=fat -C debuginfo=2 -C incremental=$(TMPDIR)/inc-fat </ins>

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


Question: |             ^^^^^^^ value used here after move | = note: this error originates in the macro `dbg` (in Nightly builds, run with -Z macro-backtrace for more info) <ins> help: consider borrowing instead of transferring ownership | LL |     let _ = dbg!(&a); |                  + </ins> error: aborting due to 1 previous error

No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.


Question: match module.inner { ModuleItem(ref module) => { for it in &module.items { <del> if it.is_extern_crate() && it.attrs.has_doc_flag("masked") { </del> <ins> // `compiler_builtins` should be masked too, but we can't apply // `#[doc(masked)]` to the injected `extern crate` because it's unstable. if it.is_extern_crate() && (it.attrs.has_doc_flag("masked") || self.cx.tcx.is_compiler_builtins(it.def_id.krate)) { </ins> masked_crates.insert(it.def_id.krate); } }

, and a few others have summaries as given in the source code, but , and a few others somehow don't. This is perplexing when we recall the method impls are generated by macros
cc I'll try to take a look in the next days.


Question: } // We probe again, taking all traits into account (not only those in scope). <del> let mut candidates = </del> <ins> let candidates = </ins> match self.lookup_probe(segment.ident, self_ty, call_expr, ProbeScope::AllTraits) { // If we find a different result the caller probably forgot to import a trait. Ok(ref new_pick) if pick.differs_from(new_pick) => {

<!-- 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: <!-- Please provide a link to --The current output is: <!-- The following is not always necessary. --Ideally the output should suggest -ing the out-of-scope trait, similar to E0599: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --Someone tried to do dynamic dispatch between two underlying used a boxed trait object (with the type spelled , so wasn't in scope) and call the method on the boxed reader, and it was unclear from the error why the method wasn't accessible: <!-- 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. --This is reproducible on nightly (rustc 1.67.0-nightly ( 2022-12-01)).
Note: A sign there may be a problem worth fixing here is the code I wrote is a near copypaste of a top stack overflow answer for a :)
So, after some investigating, this appears to be a regression of , which essentially the same suggestion I proposed here: adding a for the trait object's trait. When generating the error when the lookup fails, the trait is initially included in the list of candidates, but it's filtered out by this (because the callee is the trait method, and so the parent of the callee is the trait, which is the candidate): This was introduced in by which also removed the corresponding suggestion from the test's expected output. It's not immediately clear to me from the PR () why this change was necessary. If the call is removed, the only UI test that fails is the one. Reverting that change would fix this issue, but I'm not sure if there are other cases I'm missing.


Question: } // We probe again, taking all traits into account (not only those in scope). <del> let mut candidates = </del> <ins> let candidates = </ins> match self.lookup_probe(segment.ident, self_ty, call_expr, ProbeScope::AllTraits) { // If we find a different result the caller probably forgot to import a trait. Ok(ref new_pick) if pick.differs_from(new_pick) => {

(cc with whom I was discussing this on Mastodon)
Haven't look at this yet, maybe I misinterpreted what was achieving, and that commit just needs a revert -- can't recall why I did that.
Yeah, lol, I totally overlooked that the would be load-bearing due to the way we treat trait methods on as inherent. I'll revert , modify the test, etc.


Question: } } <ins> #[rustfmt::skip] fn baw<>(constraints: impl Iterator) { for constraint in constraints { qux(constraint); //~^ ERROR `<impl Iterator as Iterator>::Item` doesn't implement `Debug` } } </ins> fn qux(_: impl std::fmt::Debug) {} fn main() {}

(Edit: Actually, being an inherent fn doesn't matter. It happens with top-level fns too.) This prints the diagnostic: The suggestion in the last line is not valid syntax (). It also emits malformed syntax if the first parameter is a or parameter. The diagnostic becomes well-formed if any of the following is done: The first parameter is changed to instead ofThe fn is not an async fn. In either case, the diagnostic correctly says: Happens on both nightly: ... and stable:
This should hopefully be a fairly straightforward patch to the diagnostics code that generates the suggestion.


Question: } let (ours, theirs) = self.setup_io(default, needs_stdin)?; <ins> if let Some(ret) = self.posix_spawn(&theirs, envp.as_ref())? { return Ok((ret, ours)) } </ins> let (input, output) = sys::pipe::anon_pipe()?; let pid = unsafe {

When confusing a Fn-like struct with a regular struct in an pattern, the output leaves a lot to be desired: <details<summary<a href=""Current output</a</summary</detailsWe should probably collect all these errors into a single diagnostic error: Even better if there was only one diagnostic.


Question: impl FileAttr { pub fn size(&self) -> u64 { self.stat.st_size as u64 } pub fn perm(&self) -> FilePermissions { <del> FilePermissions { mode: (self.stat.st_mode as mode_t) & 0o777 } </del> <ins> FilePermissions { mode: (self.stat.st_mode as mode_t) } </ins> } pub fn file_type(&self) -> FileType {

On linux, , then run: This changes the permissions of to . Is this expected? masks away everything other than the lower 3 triads when it calls out to this code: Then sends these mode bits into into chmod which considers four triads, not three. Possibly useful references: and Should we change Metadata.permissions to preserve that triad, maybe by masking with instead of ?
I guess the solution depends on whether Unix's std::fs::Permissions is supposed to care about 9 bits or 12 (this is not an implementation detail since it's exposed to the programmer via of PermissionsExt). any thoughts on this?
It seems to me like we should extend the mask to the full 12 bits.
Seems reasonable to me to avoid masking where it makes sense!