Question:
and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!
It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.

Prior to Rust 1.80 the `target_env = "p1"` key was not set. Currently the `target_feature = "atomics"` is Nightly-only. Note that the precise `#[cfg]` necessary to detect this target may change as the target becomes more stable. <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation includes two more features in addition to that which [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md) enables: * `bulk-memory` * `atomics` For more information about features see the documentation for [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md), but note that the `mvp` CPU in LLVM does not support this target as it's required that `bulk-memory`, `atomics`, and `mutable-globals` are all enabled. </ins>


Question:
and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!
It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.

Note that the `target_env = "p1"` condition first appeared in Rust 1.80. Prior to Rust 1.80 the `target_env` condition was not set. <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation is currently the same as [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md). See the documentation there for more information. </ins>


Question:
and WebAssembly book () In Rust some requirements for WebAssembly targets. This makes Wasm binaries compiled with Rust (at least with default options/out of the box std) incompatible with older runtime environments, in particular not-so-old iOS safari (). Here is for example the support for Safari iOS 15.5 simulator: ! I searched but did not find any place where these requirements are written down. I think that this is a problem.
In principle Rust can produce binaries that only target the core subset of wasm 1.0 just fine. You do need to set some additional options with and build your own standard libraries though. But point taken, is missing dedicated pages on the wasm target that could contain this information.
The 2nd sentence right after the one you quoted outlines exactly what you need to do to take advantage of rustc’s capability to emit outputs to the wasm 1.0 spec (or any superset of it:) Make sure to do this and report back if you're still seeing the unexpected instructions/types/other entities after rustc is told to produce wasm binaries the way you need them to be. AFAIK, not for WASM.
Sorry, I realized I misunderstood your answer and deleted my post while you were answering it. Do you know how to show which features are enabled by default for a given target? I searched and did not find. I'm trying to discover whether is enabled by default on nowadays. As it seems to be because I am seeing types in the emitted wasm, even though I disabled the feature by "" in an environment variable RUSTFLAGS. It would be surprising to me that is built with that feature by default on wasm32, but maybe it is.
Hm, I'm actually not sure why you might be seeing simd128 in your modules. As far as I can tell it is not enabled by default for any wasm target. In order to print out features used you should look for lines in: For what it is worth I’ve been using this exact target at my $DAYJOB with a pretty primitive runtime and it has been working largely OOB if my memory serves me right. So it indeed could have something to do with your dependencies possibly using something like ? Not sure!
It seems that the was built with as I see this WASM function: What I am not sure is whether 1. this was integrated with the standard library and then imported indirectly to my project, or 2. somehow one of the dependency managed to enable it by itself. I tend to favor 1 but I'm not sure. That is why it would be great for such things to be documented :-)
For reference, I asked on the about how the std lib is built.
I confirm that as of version 1.75, the standard library is not using any WebAssembly SIMD instructions. Here is my test: which shows nothing, so they get pulled in by the memchr package through some of my dependencies.
You yourself pointed out which crate produces the v128 types: . It uses to enable emission of these types, regardless of the global configuration it looks like. This is usually fine for other architectures, but rarely for wasm, so it might make sense to file an issue over there.
I fully agree and I just opened an issue there: BurntSushi/memchr
As a heads up I've proposed that close this issue with documentation of how to target MVP wasm.

```text #[cfg(all(target_os = "wasi", target_env = "p2"))] ``` <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation is currently the same as [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md). See the documentation there for more information. </ins>


Question:
Reading the compiler code (specifically the one responsible for mir output) I found these s where probably expected . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Have you actually encountered an ICE due to this?
No, I just happened to find that. It's not a ICE, just a typo in the code
claim

| ProjectionElem::Subtype(_) | ProjectionElem::Downcast(_, _) | ProjectionElem::Field(_, _) => { <del> write!(fmt, "(").unwrap(); </del> <ins> write!(fmt, "(")?; </ins> } ProjectionElem::Deref => { <del> write!(fmt, "(*").unwrap(); </del> <ins> write!(fmt, "(*")?; </ins> } ProjectionElem::Index(_) | ProjectionElem::ConstantIndex { .. }


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

// but there's already an item with the same namespace and same name. Rust gives // priority to the not-imported one, so we should, too. items.extend(doc.items.values().flat_map(|(item, renamed, import_id)| { <del> // First, lower everything other than imports. </del> <ins> // First, lower everything other than glob imports. </ins> if matches!(item.kind, hir::ItemKind::Use(_, hir::UseKind::Glob)) { return Vec::new(); }


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

use rustc_hir::HirId; use rustc_lint_defs::Applicability; use rustc_resolve::rustdoc::source_span_for_markdown_range; <ins> use rustc_span::def_id::DefId; </ins> use rustc_span::Symbol; use crate::clean::utils::find_nearest_parent_module;


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

return; } <del> if item.link_names(&cx.cache).is_empty() { // If there's no link names in this item, // then we skip resolution querying to // avoid from panicking. return; </del> <ins> if let Some(item_id) = item.def_id() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); </ins> } <ins> if let Some(item_id) = item.inline_stmt_id { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } } </ins> <del> let Some(item_id) = item.def_id() else { return; }; let Some(local_item_id) = item_id.as_local() else { </del> <ins> fn check_redundant_explicit_link_for_did<'md>( cx: &DocContext<'_>, item: &Item, did: DefId, hir_id: HirId, doc: &'md str, ) { let Some(local_item_id) = did.as_local() else { </ins> return; };


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

return; } let is_private = !cx.render_options.document_private <del> && !cx.cache.effective_visibilities.is_directly_public(cx.tcx, item_id); </del> <ins> && !cx.cache.effective_visibilities.is_directly_public(cx.tcx, did); </ins> if is_private { return; } <del> check_redundant_explicit_link(cx, item, hir_id, &doc); </del> <ins> let module_id = match cx.tcx.def_kind(did) { DefKind::Mod if item.inner_docs(cx.tcx) => did, _ => find_nearest_parent_module(cx.tcx, did).unwrap(), }; let Some(resolutions) = cx.tcx.resolutions(()).doc_link_resolutions.get(&module_id.expect_local()) else { // If there's no resolutions in this module, // then we skip resolution querying to // avoid from panicking. return; }; check_redundant_explicit_link(cx, item, hir_id, &doc, &resolutions); </ins> } fn check_redundant_explicit_link<'md>(


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

item: &Item, hir_id: HirId, doc: &'md str, <ins> resolutions: &DocLinkResMap, </ins> ) -> Option<()> { let mut broken_line_callback = |link: BrokenLink<'md>| Some((link.reference, "".into())); let mut offset_iter = Parser::new_with_broken_link_callback(


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

Some(&mut broken_line_callback), ) .into_offset_iter(); <del> let item_id = item.def_id()?; let module_id = match cx.tcx.def_kind(item_id) { DefKind::Mod if item.inner_docs(cx.tcx) => item_id, _ => find_nearest_parent_module(cx.tcx, item_id).unwrap(), }; let resolutions = cx.tcx.doc_link_resolutions(module_id); </del> while let Some((event, link_range)) = offset_iter.next() { match event {


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

<ins> // compile-flags: --document-private-items #![deny(rustdoc::redundant_explicit_links)] mod webdavfs { pub struct A; pub struct B; } /// [`Vfs`][crate::Vfs] pub use webdavfs::A; //~^^ error: redundant explicit link target /// [`Vfs`] pub use webdavfs::B; pub struct Vfs; </ins>


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

<ins> error: redundant explicit link target --> $DIR/issue-120444-1.rs:10:13 | LL | /// [`Vfs`][crate::Vfs] |      -----  ^^^^^^^^^^ explicit target is redundant |      | |      because label contains path that resolves to same destination | = note: when a link's destination is not specified, the label is used to resolve intra-doc links note: the lint level is defined here --> $DIR/issue-120444-1.rs:3:9 | LL | #![deny(rustdoc::redundant_explicit_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove explicit link target | LL | /// [`Vfs`] |     ~~~~~~~ error: aborting due to 1 previous error </ins>


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

<ins> // compile-flags: --document-private-items #![deny(rustdoc::redundant_explicit_links)] pub mod webdavfs { pub struct A; pub struct B; } /// [`Vfs`][crate::Vfs] pub use webdavfs::A; //~^^ error: redundant explicit link target /// [`Vfs`] pub use webdavfs::B; pub struct Vfs; </ins>


Question:
<!-- 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. --Basically this is the module where it fails, right now I can't create a minimized example, I'll try to later: on: branch: Bug also exists on nightly, and also on Linux: : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I can confirm this bug on
minimized repro: label T-rustdoc A-intra-doc-links A-resolve S-has-mcve -needs-triage

<ins> error: redundant explicit link target --> $DIR/issue-120444-2.rs:10:13 | LL | /// [`Vfs`][crate::Vfs] |      -----  ^^^^^^^^^^ explicit target is redundant |      | |      because label contains path that resolves to same destination | = note: when a link's destination is not specified, the label is used to resolve intra-doc links note: the lint level is defined here --> $DIR/issue-120444-2.rs:3:9 | LL | #![deny(rustdoc::redundant_explicit_links)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove explicit link target | LL | /// [`Vfs`] |     ~~~~~~~ error: aborting due to 1 previous error </ins>


Question:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

"arch": "x86_64", "cpu": "x86-64", "crt-static-respected": true, <del> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", </del> <ins> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", </ins> "dynamic-linking": true, "env": "gnu", "has-rpath": true,


Question:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

"arch": "x86_64", "cpu": "x86-64", "crt-static-respected": true, <del> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", </del> <ins> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", </ins> "dynamic-linking": true, "env": "gnu", "executables": true,


Question:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

{ <del> "data-layout": "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-f64:32:64-f80:32-n8:16:32-S128", </del> <ins> "data-layout": "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-i128:128-f64:32:64-f80:32-n8:16:32-S128", </ins> "linker-flavor": "gcc", "llvm-target": "i686-unknown-linux-gnu", "target-endian": "little",


Question:
The commit a check that stars firing due to the changes to the default target layouts in LLVM 18 ():
Having this issue on as well: Why it's trying to compile for a 32-bit target is clearly beyond me because I'm using an entirely 64-bit host ― since happens to be the author of the crate this is failing on (namely, the 32-bit BIOS version of the bootloader crate which I explicitly avoid depending on for my intendedly UEFI-only kernel), pinging him for assistance.
I think this issue thread is about some failing tests in the Rust repo. Your issue seems to be specific to the crate, which required some updates to the custom targets it is using. I published a new version already, which should fix the issue. If you still have issues with the crate after a , please open an issue in the repository.

{ "pre-link-args": {"gcc": ["-m64"]}, <del> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128", </del> <ins> "data-layout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128", </ins> "linker-flavor": "gcc", "llvm-target": "x86_64-unknown-linux-gnu", "target-endian": "little",


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

} } <del> fn install_llvm_file(builder: &Builder<'_>, source: &Path, destination: &Path) { </del> <ins> fn install_llvm_file( builder: &Builder<'_>, source: &Path, destination: &Path, install_symlink: bool, ) { </ins> if builder.config.dry_run() { return; } <del> builder.install(source, destination, 0o644); </del> <ins> if source.is_symlink() { // If we have a symlink like libLLVM-18.so -> libLLVM.so.18.1, install the target of the // symlink, which is what will actually get loaded at runtime. builder.install(&t!(fs::canonicalize(source)), destination, 0o644); if install_symlink { // If requested, also install the symlink. This is used by download-ci-llvm. let full_dest = destination.join(source.file_name().unwrap()); builder.copy(&source, &full_dest); } } else { builder.install(&source, destination, 0o644); } </ins> } /// Maybe add LLVM object files to the given destination lib-dir. Allows either static or dynamic linking. /// /// Returns whether the files were actually copied. <del> fn maybe_install_llvm(builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path) -> bool { </del> <ins> fn maybe_install_llvm( builder: &Builder<'_>, target: TargetSelection, dst_libdir: &Path, install_symlink: bool, ) -> bool { </ins> // If the LLVM was externally provided, then we don't currently copy // artifacts into the sysroot. This is not necessarily the right // choice (in particular, it will require the LLVM dylib to be in


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

} else { PathBuf::from(file) }; <del> install_llvm_file(builder, &file, dst_libdir); </del> <ins> install_llvm_file(builder, &file, dst_libdir, install_symlink); </ins> } !builder.config.dry_run() } else {


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

// dynamically linked; it is already included into librustc_llvm // statically. if builder.llvm_link_shared() { <del> maybe_install_llvm(builder, target, &dst_libdir); </del> <ins> maybe_install_llvm(builder, target, &dst_libdir, false); </ins> } }


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

let mut tarball = Tarball::new(builder, "rust-dev", &target.triple); tarball.set_overlay(OverlayKind::LLVM); <ins> // LLVM requires a shared object symlink to exist on some platforms. tarball.permit_symlinks(true); </ins> builder.ensure(crate::core::build_steps::llvm::Llvm { target });


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

// of `rustc-dev` to support the inherited `-lLLVM` when using the // compiler libraries. let dst_libdir = tarball.image_dir().join("lib"); <del> maybe_install_llvm(builder, target, &dst_libdir); </del> <ins> maybe_install_llvm(builder, target, &dst_libdir, true); </ins> let link_type = if builder.llvm_link_shared() { "dynamic" } else { "static" }; t!(std::fs::write(tarball.image_dir().join("link-type.txt"), link_type), dst_libdir);


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

let out_dir = builder.llvm_out(target); let mut llvm_config_ret_dir = builder.llvm_out(builder.config.build); <del> if (!builder.config.build.is_msvc() || builder.ninja()) && !builder.config.llvm_from_ci { llvm_config_ret_dir.push("build"); } </del> llvm_config_ret_dir.push("bin"); let build_llvm_config = llvm_config_ret_dir.join(exe("llvm-config", builder.config.build)); let llvm_cmake_dir = out_dir.join("lib/cmake/llvm");


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

<del> Subproject commit 9ea7f739f257b049a65deeb1f2455bb2ea021cfa </del> <ins> Subproject commit 7973f3560287d750500718314a0fd4025bd8ac0e </ins>


Question:
Reproduction: Miri and prints But prints I reported this to LLVM but was told that the IR generated from MIR has alignment issues. I really don't know much about LLVM IR but I suspect the problem is The second element of () is not guaranteed to be 16-byte aligned cc
Can you reproduce this without using u128/i128? And/or does this reproduce with LLVM 18?
It's still reproducible on nikic's llvm-18 branch. If i replace all with then it no longer reproduces, but of course I don't know if there are other examples out there that triggers the same bug without i128
Ah; what I meant is can you reproduce this issue using a type which in Rust has the same layout as , but which is not ? Perhaps ?
Yes, still reproducible after replacing it with a struct (both zero-sized and with members)
WG-prioritization assigning priority (). label -I-prioritize +P-high

})?; let libdir = env.build_artifacts().join("stage2").join("lib"); <del> let llvm_lib = io::find_file_in_dir(&libdir, "libLLVM", ".so")?; </del> <ins> // The actual name will be something like libLLVM.so.18.1-rust-dev. let llvm_lib = io::find_file_in_dir(&libdir, "libLLVM.so", "")?; </ins> log::info!("Optimizing {llvm_lib} with BOLT");


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

resolve_consider_marking_as_pub = consider marking `{$ident}` as `pub` in the imported module <ins> resolve_consider_move_macro_position = consider moving the definition of `{$ident}` before this call </ins> resolve_const_not_member_of_trait = const `{$const_}` is not a member of trait `{$trait_}` .label = not a member of trait `{$trait_}`


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

attempt to use a non-constant value in a constant .suggestion = try using `Self` <ins> resolve_macro_defined_later = a macro with the same name exists, but it appears later at here </ins> resolve_macro_expected_found = expected {$expected}, found {$found} `{$macro_path}`


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

use thin_vec::{thin_vec, ThinVec}; use crate::errors::{AddedMacroUse, ChangeImportBinding, ChangeImportBindingSuggestion}; <del> use crate::errors::{ConsiderAddingADerive, ExplicitUnsafeTraits, MaybeMissingMacroRulesName}; </del> <ins> use crate::errors::{ ConsiderAddingADerive, ExplicitUnsafeTraits, MacroDefinedLater, MacroSuggMovePosition, MaybeMissingMacroRulesName, }; </ins> use crate::imports::{Import, ImportKind}; use crate::late::{PatternSource, Rib}; use crate::{errors as errs, BindingKey};


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

return; } <ins> let unused_macro = self.unused_macros.iter().find_map(|(def_id, (_, unused_ident))| { if unused_ident.name == ident.name { Some((def_id.clone(), unused_ident.clone())) } else { None } }); if let Some((def_id, unused_ident)) = unused_macro { let scope = self.local_macro_def_scopes[&def_id]; let parent_nearest = parent_scope.module.nearest_parent_mod(); if Some(parent_nearest) == scope.opt_def_id() { err.subdiagnostic(self.dcx(), MacroDefinedLater { span: unused_ident.span }); err.subdiagnostic(self.dcx(), MacroSuggMovePosition { span: ident.span, ident }); return; } } </ins> if self.macro_names.contains(&ident.normalize_to_macros_2_0()) { err.subdiagnostic(self.dcx(), AddedMacroUse); return;


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

} #[derive(Subdiagnostic)] <ins> #[note(resolve_macro_defined_later)] pub(crate) struct MacroDefinedLater { #[primary_span] pub(crate) span: Span, } #[derive(Subdiagnostic)] #[label(resolve_consider_move_macro_position)] pub(crate) struct MacroSuggMovePosition { #[primary_span] pub(crate) span: Span, pub(crate) ident: Ident, } #[derive(Subdiagnostic)] </ins> #[note(resolve_missing_macro_rules_name)] pub(crate) struct MaybeMissingMacroRulesName { #[primary_span]


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

<ins> mod demo { fn hello() { something_later!(); //~ ERROR cannot find macro `something_later` in this scope } macro_rules! something_later { () => { println!("successfully expanded!"); }; } } fn main() {} </ins>


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

<ins> error: cannot find macro `something_later` in this scope --> $DIR/defined-later-issue-121061-2.rs:3:9 | LL |         something_later!(); |         ^^^^^^^^^^^^^^^ consider moving the definition of `something_later` before this call | note: a macro with the same name exists, but it appears later at here --> $DIR/defined-later-issue-121061-2.rs:6:18 | LL |     macro_rules! something_later { |                  ^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

<ins> fn main() { something_later!(); //~ ERROR cannot find macro `something_later` in this scope } macro_rules! something_later { () => { println!("successfully expanded!"); }; } </ins>


Question:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!

<ins> error: cannot find macro `something_later` in this scope --> $DIR/defined-later-issue-121061.rs:2:5 | LL |     something_later!(); |     ^^^^^^^^^^^^^^^ consider moving the definition of `something_later` before this call | note: a macro with the same name exists, but it appears later at here --> $DIR/defined-later-issue-121061.rs:5:14 | LL | macro_rules! something_later { |              ^^^^^^^^^^^^^^^ error: aborting due to 1 previous error </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

ItemId { owner_id: self.owner_id } } <ins> /// Check if this is an [`ItemKind::Enum`], [`ItemKind::Struct`] or /// [`ItemKind::Union`]. pub fn is_adt(&self) -> bool { matches!(self.kind, ItemKind::Enum(..) | ItemKind::Struct(..) | ItemKind::Union(..)) } </ins> expect_methods_self_kind! { expect_extern_crate, Option<Symbol>, ItemKind::ExternCrate(s), *s;


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

hir_analysis_invalid_union_field_sugg = wrap the field type in `ManuallyDrop<...>` <ins> hir_analysis_invalid_unnamed_field_ty = unnamed fields can only have struct or union types </ins> hir_analysis_late_bound_const_in_apit = `impl Trait` can only mention const parameters from an fn or impl .label = const parameter declared here


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

for field in variant.fields.iter().filter(|f| f.is_unnamed()) { let field_ty = tcx.type_of(field.did).instantiate_identity(); if let Some(adt) = field_ty.ty_adt_def() <del> && !adt.is_anonymous() && !adt.repr().c() </del> <ins> && !adt.is_enum() </ins> { <del> let field_ty_span = tcx.def_span(adt.did()); tcx.dcx().emit_err(errors::UnnamedFieldsRepr::FieldMissingReprC { span: tcx.def_span(field.did), field_ty_span, field_ty, field_adt_kind: adt.descr(), sugg_span: field_ty_span.shrink_to_lo(), }); </del> <ins> if !adt.is_anonymous() && !adt.repr().c() { let field_ty_span = tcx.def_span(adt.did()); tcx.dcx().emit_err(errors::UnnamedFieldsRepr::FieldMissingReprC { span: tcx.def_span(field.did), field_ty_span, field_ty, field_adt_kind: adt.descr(), sugg_span: field_ty_span.shrink_to_lo(), }); } } else { tcx.dcx().emit_err(errors::InvalidUnnamedFieldTy { span: tcx.def_span(field.did) }); </ins> } } }


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

} } hir::TyKind::Path(hir::QPath::Resolved(_, hir::Path { res, .. })) => { <del> self.check_field_in_nested_adt(self.tcx.adt_def(res.def_id()), field.span); </del> <ins> // If this is a direct path to an ADT, we can check it // If this is a type alias or non-ADT, `check_unnamed_fields` should verify it if let Some(def_id) = res.opt_def_id() && let Some(local) = def_id.as_local() && let Node::Item(item) = self.tcx.hir_node_by_def_id(local) && item.is_adt() { self.check_field_in_nested_adt(self.tcx.adt_def(def_id), field.span); } </ins> } // Abort due to errors (there must be an error if an unnamed field //  has any type kind other than an anonymous adt or a named adt)


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

} #[derive(Diagnostic)] <ins> #[diag(hir_analysis_invalid_unnamed_field_ty)] pub struct InvalidUnnamedFieldTy { #[primary_span] pub span: Span, } #[derive(Diagnostic)] </ins> #[diag(hir_analysis_return_type_notation_on_non_rpitit)] pub(crate) struct ReturnTypeNotationOnNonRpitit<'tcx> { #[primary_span]


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

<ins> #[repr(C)] pub struct GoodStruct(()); pub struct BadStruct(()); pub enum BadEnum { A, B, } #[repr(C)] pub enum BadEnum2 { A, B, } pub type GoodAlias = GoodStruct; pub type BadAlias = i32; </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

<ins> //@ aux-build:dep.rs // test for #121151 #![allow(incomplete_features)] #![feature(unnamed_fields)] extern crate dep; #[repr(C)] struct A { a: u8, } enum BadEnum { A, B, } #[repr(C)] enum BadEnum2 { A, B, } type MyStruct = A; type MyI32 = i32; #[repr(C)] struct L { _: i32, //~ ERROR unnamed fields can only have struct or union types _: MyI32, //~ ERROR unnamed fields can only have struct or union types _: BadEnum, //~ ERROR unnamed fields can only have struct or union types _: BadEnum2, //~ ERROR unnamed fields can only have struct or union types _: MyStruct, _: dep::BadStruct, //~ ERROR named type of unnamed field must have `#[repr(C)]` representation _: dep::BadEnum, //~ ERROR unnamed fields can only have struct or union types _: dep::BadEnum2, //~ ERROR unnamed fields can only have struct or union types _: dep::BadAlias, //~ ERROR unnamed fields can only have struct or union types _: dep::GoodAlias, _: dep::GoodStruct, } fn main() {} </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an ADT', 'error: internal compiler error: DefId(0:9 ~ 2240CC2B11F85033EA5790516B40233B624A83EF815682C223C9D1B595151F87[d912]::Foo) is not an 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: [adtdef] computing ADT definition for [typeof] computing type of [collectmoditem_types] collecting item types in top-level module [analysis] running analysis passes on this crate --
Actually nvm, don't want to work on this. heads up that this code is broken. It does not verify that the unnamed field is an ADT:

<ins> error: unnamed fields can only have struct or union types --> $DIR/restrict_type_hir.rs:31:5 | LL |     _: i32, |     ^^^^^^ error: unnamed fields can only have struct or union types --> $DIR/restrict_type_hir.rs:32:5 | LL |     _: MyI32, |     ^^^^^^^^ error: unnamed fields can only have struct or union types --> $DIR/restrict_type_hir.rs:33:5 | LL |     _: BadEnum, |     ^^^^^^^^^^ error: unnamed fields can only have struct or union types --> $DIR/restrict_type_hir.rs:34:5 | LL |     _: BadEnum2, |     ^^^^^^^^^^^ error: named type of unnamed field must have `#[repr(C)]` representation --> $DIR/restrict_type_hir.rs:36:5 | LL |     _: dep::BadStruct, |     ^^^^^^^^^^^^^^^^^ unnamed field defined here | ::: $DIR/auxiliary/dep.rs:4:1 | LL | pub struct BadStruct(()); | -------------------- `BadStruct` defined here | help: add `#[repr(C)]` to this struct --> $DIR/auxiliary/dep.rs:4:1 | LL + #[repr(C)] LL | pub struct BadStruct(()); | error: unnamed fields can only have struct or union types --> $DIR/restrict_type_hir.rs:37:5 | LL |     _: dep::BadEnum, |     ^^^^^^^^^^^^^^^ error: unnamed fields can only have struct or union types --> $DIR/restrict_type_hir.rs:38:5 | LL |     _: dep::BadEnum2, |     ^^^^^^^^^^^^^^^^ error: unnamed fields can only have struct or union types --> $DIR/restrict_type_hir.rs:39:5 | LL |     _: dep::BadAlias, |     ^^^^^^^^^^^^^^^^ error: aborting due to 8 previous errors </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead' File: --snippet: 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking [analysis] running analysis passes on this crate --
cc

let func_ty = func.ty(body, tcx); if let ty::FnDef(callee, args) = *func_ty.kind() { <del> let normalized_args = tcx.normalize_erasing_regions(param_env, args); </del> <ins> let Ok(normalized_args) = tcx.try_normalize_erasing_regions(param_env, args) else { return false; }; </ins> let (callee, call_args) = if let Ok(Some(instance)) = Instance::resolve(tcx, param_env, callee, normalized_args) {


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead' File: --snippet: 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking [analysis] running analysis passes on this crate --
cc

<ins> fn problematic_function<Space>(material_surface_element: ()) where DefaultAllocator: FiniteElementAllocator<(), Space>, { let _: Point2<f64> = material_surface_element.map_reference_coords().into(); } impl<N, R> Allocator<N, R> for DefaultAllocator where R::Value: DimName, //~ ERROR: `Value` not found for `R` { type Buffer = (); } impl<N> Allocator<N, ()> for DefaultAllocator {} //~^ ERROR: conflicting implementations impl DimName for () {} impl DimName for u32 {} impl<N, D: DimName> From<VectorN<N, D>> for Point<N, D> { fn from(_: VectorN<N, D>) -> Self { todo!() } } impl FiniteElement<u32> for () {} type VectorN<N, D> = Matrix<<DefaultAllocator as Allocator<N, D>>::Buffer>; type Point2<N> = Point<N, u32>; struct DefaultAllocator; struct Matrix<S>(S); struct Point<N, D>(N, D); trait Allocator<Scalar, R> { type Buffer; } trait DimName {} trait FiniteElementAllocator<GeometryDim, NodalDim>: Allocator<f64, ()> + Allocator<f64, NodalDim> { } trait FiniteElement<GeometryDim> { fn map_reference_coords(&self) -> VectorN<f64, GeometryDim> { todo!() } } fn main() {} </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead', 'error: internal compiler error: Failed to normalize Matrix<f64, DimU2, DimU1, Alias(Projection, AliasTy { args: [DefaultAllocator, f64, DimU2, DimU1], defid: DefId(0:65 ~ 4[99cc]::Allocator::Buffer) }), maybe try to call instead' File: --snippet: 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: [mirbuilt] building MIR for [checkunsafety] unsafety-checking [analysis] running analysis passes on this crate --
cc

<ins> error[E0220]: associated type `Value` not found for `R` --> $DIR/normalize-conflicting-impls.rs:10:8 | LL |     R::Value: DimName, |        ^^^^^ associated type `Value` not found error[E0119]: conflicting implementations of trait `Allocator<_, ()>` for type `DefaultAllocator` --> $DIR/normalize-conflicting-impls.rs:14:1 | LL | / impl<N, R> Allocator<N, R> for DefaultAllocator LL | | where LL | |     R::Value: DimName, | |______________________- first implementation here ... LL |   impl<N> Allocator<N, ()> for DefaultAllocator {} |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `DefaultAllocator` error: aborting due to 2 previous errors Some errors have detailed explanations: E0119, E0220. For more information about an error, try `rustc --explain E0119`. </ins>


Question:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or

#![allow(rustc::untranslatable_diagnostic)] use either::Either; <ins> use hir::ClosureKind; </ins> use rustc_data_structures::captures::Captures; use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{codes::*, struct_span_code_err, Applicability, Diag, MultiSpan};


Question:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or

} else if let UseSpans::FnSelfUse { kind: CallKind::Normal { .. }, .. } = move_spans { // We already suggest cloning for these cases in `explain_captures`. <ins> } else if let UseSpans::ClosureUse { closure_kind: ClosureKind::Coroutine(CoroutineKind::Desugared(_, CoroutineSource::Block)), args_span: _, capture_kind_span: _, path_span, } = move_spans { self.suggest_cloning(err, ty, expr, path_span); </ins> } else if self.suggest_hoisting_call_outside_loop(err, expr) { // The place where the the type moves would be misleading to suggest clone. // #121466


Question:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or

} // FIXME: We make sure that this is a normal top-level binding, <del> // but we could suggest `todo!()` for all uninitalized bindings in the pattern pattern </del> <ins> // but we could suggest `todo!()` for all uninitialized bindings in the pattern pattern </ins> if let hir::StmtKind::Let(hir::LetStmt { span, ty, init: None, pat, .. }) = &ex.kind && let hir::PatKind::Binding(..) = pat.kind


Question:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or

true } <del> /// In a move error that occurs on a call wihtin a loop, we try to identify cases where cloning </del> <ins> /// In a move error that occurs on a call within a loop, we try to identify cases where cloning </ins> /// the value would lead to a logic error. We infer these cases by seeing if the moved value is /// part of the logic to break the loop, either through an explicit `break` or if the expression /// is part of a `while let`.


Question:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or

{ // FIXME: We could check that the call's *parent* takes `&mut val` to make the // suggestion more targeted to the `mk_iter(val).next()` case. Maybe do that only to <del> // check for wheter to suggest `let value` or `let mut value`. </del> <ins> // check for whether to suggest `let value` or `let mut value`. </ins> let span = in_loop.span; if !finder.found_breaks.is_empty()


Question:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or

<ins> //@ edition:2021 async fn clone_async_block(value: String) { for _ in 0..10 { async { //~ ERROR: use of moved value: `value` [E0382] drop(value); //~^ HELP: consider cloning the value if the performance cost is acceptable }.await } } fn main() {} </ins>


Question:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or

<ins> error[E0382]: use of moved value: `value` --> $DIR/cloning-in-async-block-121547.rs:5:9 | LL |   async fn clone_async_block(value: String) { |                              ----- move occurs because `value` has type `String`, which does not implement the `Copy` trait LL |       for _ in 0..10 { |       -------------- inside of this loop LL | /         async { LL | |             drop(value); | |                  ----- use occurs due to use in coroutine LL | | LL | |         }.await | |_________^ value moved here, in previous iteration of loop | help: consider cloning the value if the performance cost is acceptable | LL |             drop(value.clone()); |                       ++++++++ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0382`. </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc

} } } else { <del> if matches!(def_kind, DefKind::AnonConst) && tcx.features().generic_const_exprs { let hir_id = tcx.local_def_id_to_hir_id(def_id); let parent_def_id = tcx.hir().get_parent_item(hir_id); if let Some(defaulted_param_def_id) = tcx.hir().opt_const_param_default_param_def_id(hir_id) { // In `generics_of` we set the generics' parent to be our parent's parent which means that // we lose out on the predicates of our actual parent if we dont return those predicates here. // (See comment in `generics_of` for more information on why the parent shenanigans is necessary) // // struct Foo<T, const N: usize = { <T as Trait>::ASSOC }>(T) where T: Trait; //        ^^^                     ^^^^^^^^^^^^^^^^^^^^^^^ the def id we are calling //        ^^^                                             explicit_predicates_of on //        parent item we dont have set as the //        parent of generics returned by `generics_of` // // In the above code we want the anon const to have predicates in its param env for `T: Trait` // and we would be calling `explicit_predicates_of(Foo)` here let parent_preds = tcx.explicit_predicates_of(parent_def_id); // If we dont filter out `ConstArgHasType` predicates then every single defaulted const parameter // will ICE because of #106994. FIXME(generic_const_exprs): remove this when a more general solution // to #106994 is implemented. let filtered_predicates = parent_preds .predicates .into_iter() .filter(|(pred, _)| { if let ty::ClauseKind::ConstArgHasType(ct, _) = pred.kind().skip_binder() { match ct.kind() { ty::ConstKind::Param(param_const) => { let defaulted_param_idx = tcx .generics_of(parent_def_id) .param_def_id_to_index[&defaulted_param_def_id.to_def_id()]; param_const.index < defaulted_param_idx } _ => bug!( "`ConstArgHasType` in `predicates_of` that isn't a `Param` const" ), </del> <ins> if matches!(def_kind, DefKind::AnonConst) && tcx.features().generic_const_exprs && let Some(defaulted_param_def_id) = tcx.hir().opt_const_param_default_param_def_id(tcx.local_def_id_to_hir_id(def_id)) { // In `generics_of` we set the generics' parent to be our parent's parent which means that // we lose out on the predicates of our actual parent if we dont return those predicates here. // (See comment in `generics_of` for more information on why the parent shenanigans is necessary) // // struct Foo<T, const N: usize = { <T as Trait>::ASSOC }>(T) where T: Trait; //        ^^^                     ^^^^^^^^^^^^^^^^^^^^^^^ the def id we are calling //        ^^^                                             explicit_predicates_of on //        parent item we dont have set as the //        parent of generics returned by `generics_of` // // In the above code we want the anon const to have predicates in its param env for `T: Trait` // and we would be calling `explicit_predicates_of(Foo)` here let parent_def_id = tcx.local_parent(def_id); let parent_preds = tcx.explicit_predicates_of(parent_def_id); // If we dont filter out `ConstArgHasType` predicates then every single defaulted const parameter // will ICE because of #106994. FIXME(generic_const_exprs): remove this when a more general solution // to #106994 is implemented. let filtered_predicates = parent_preds .predicates .into_iter() .filter(|(pred, _)| { if let ty::ClauseKind::ConstArgHasType(ct, _) = pred.kind().skip_binder() { match ct.kind() { ty::ConstKind::Param(param_const) => { let defaulted_param_idx = tcx .generics_of(parent_def_id) .param_def_id_to_index[&defaulted_param_def_id.to_def_id()]; param_const.index < defaulted_param_idx </ins> } <del> } else { true </del> <ins> _ => bug!( "`ConstArgHasType` in `predicates_of` that isn't a `Param` const" ), </ins> } <del> }) .cloned(); return GenericPredicates { parent: parent_preds.parent, predicates: { tcx.arena.alloc_from_iter(filtered_predicates) }, }; } let parent_def_kind = tcx.def_kind(parent_def_id); if matches!(parent_def_kind, DefKind::OpaqueTy) { // In `instantiate_identity` we inherit the predicates of our parent. // However, opaque types do not have a parent (see `gather_explicit_predicates_of`), which means // that we lose out on the predicates of our actual parent if we dont return those predicates here. // // // fn foo<T: Trait>() -> impl Iterator<Output = Another<{ <T as Trait>::ASSOC }> > { todo!() } //                                                        ^^^^^^^^^^^^^^^^^^^ the def id we are calling //                                                                            explicit_predicates_of on // // In the above code we want the anon const to have predicates in its param env for `T: Trait`. // However, the anon const cannot inherit predicates from its parent since it's opaque. // // To fix this, we call `explicit_predicates_of` directly on `foo`, the parent's parent. // In the above example this is `foo::{opaque#0}` or `impl Iterator` let parent_hir_id = tcx.local_def_id_to_hir_id(parent_def_id.def_id); // In the above example this is the function `foo` let item_def_id = tcx.hir().get_parent_item(parent_hir_id); // In the above code example we would be calling `explicit_predicates_of(foo)` here return tcx.explicit_predicates_of(item_def_id); } </del> <ins> } else { true } }) .cloned(); return GenericPredicates { parent: parent_preds.parent, predicates: { tcx.arena.alloc_from_iter(filtered_predicates) }, }; </ins> } gather_explicit_predicates_of(tcx, def_id) }


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc

<del> //@ known-bug: #118403 #![feature(generic_const_exprs)] pub struct X<const N: usize> {} impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> { (0..1).map(move |_| (0..1).map(move |_| loop {})) } } </del>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc

<del> //@ known-bug: #121574 #![feature(generic_const_exprs)] pub struct DimName<const N: usize> {} impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> { "0".as_bytes(move |_| (0..1).map(move |_| loop {})) } } </del>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc

<del> //@ known-bug: #121574 #![feature(generic_const_exprs)] impl<const Z: usize> X<Z> { pub fn y<'a, U: 'a>(&'a self) -> impl Iterator<Item = impl Iterator<Item = [u8; Z]> + '_> {} } </del>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc

<ins> //@ check-pass #![feature(generic_const_exprs)] //~^ WARN the feature `generic_const_exprs` is incomplete and may not be safe to use pub fn y<'a, U: 'a>() -> impl IntoIterator<Item = impl IntoIterator<Item = [u8; { 1 + 2 }]> + 'a> { [[[1, 2, 3]]] } // Make sure that the `predicates_of` for `{ 1 + 2 }` don't mention the duplicated lifetimes of // the *outer* iterator. Whether they should mention the duplicated lifetimes of the *inner* // iterator are another question, but not really something we need to answer immediately. fn main() {} </ins>


Question:
<!-- ICE: Rustc '' 'error: internal compiler error: cannot convert to a region vid', 'error: internal compiler error: cannot convert to a region vid' 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc

<ins> warning: the feature `generic_const_exprs` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/double-opaque-parent-predicates.rs:3:12 | LL | #![feature(generic_const_exprs)] |            ^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>


Question:
I'm referring to this particular line Even though in environments Global as a structure exists and is defined, and it only shows up in PhantomData, the use of the structure is most likely undefined if attribute is never used. Yes, there will be no calls to Global as it's only a phantom, and execution will not be affected, but just seems ill-defined at least. For completeness: compilation of code that uses with custom allocator under is not affected, and there is no sign of runtime bugs.
Does this matter? It holds it directly:
My issue is the opposite - it should be in the PhantomData too, but not implicit
I understand, but it already includes for dropck, so why should it include it in the too?
To avoid inclusion of Global that has no logical relation to the BTreeMap instance with custom allocator
If it's accepted as a bug I can quickly fix it, at least it passes tests

/// `ManuallyDrop` to control drop order (needs to be dropped after all the nodes). pub(super) alloc: ManuallyDrop<A>, // For dropck; the `Box` avoids making the `Unpin` impl more strict than before <del> _marker: PhantomData<crate::boxed::Box<(K, V)>>, </del> <ins> _marker: PhantomData<crate::boxed::Box<(K, V), A>>, </ins> } #[stable(feature = "btree_drop", since = "1.7.0")]


Question:
Trying to build Miri against latest rustc artifacts fails: Regression range: Likely cause: Cc
How does miri link against rust?
Just a bunch of :
Given that rustc CI still works and only builds against the distributed rustc toolchain are affected, it seems likely that the issue is related to the rustc-dev component -- maybe that doesn't contain all the required files any more?
Reproducing instructions: checkout out to install the right toolchain (that branch uses ) -
The necessary symlink is indeed not part of rustc-dev (only rust-dev). We could add it, but it's not obvious to me why it is needed. I'm not familiar with how rustc generates that linker invocation, but the fact that it explicitly includes in it seems wrong to me ( is a dependency of and just linking against should be sufficient).
There is no component? At least doesn't list one and comes back empty. I don't know anything about this linking magic either.^^ Cc
But evidently the symlink is needed... so in the mean time it'd be good to unstuck this by adding the symlink I think. I expect this will break out-of-tree builds of Clippy as well, and rustfmt -- basically every tool that links against rustc.
Ah, it's not a real component, just the tarball that download-ci-llvm uses. Main problem is that we have checks against shipping symlinks, and I expect they exist for good reason...
Ah, yeah probably Windows doesn't like them. Why can't rustc_driver link against the correct .so file, i.e., why is a symlink needed in the first place?
I think this is the reason why it gets to the linker line: This is because llvm-config returns something like and the symlink is needed to resolve that to . And it seems like rustc just embeds the original name in the dylib, rather than the symlink-resolved variant, so the symlink is still needed. Possibly that's a bug? Similar to how shared objects embed the resolved name, maybe rustc should do the same for its own metadata. Though independent of general rustc behavior, I guess we could explicitly resolve the symlink in the for rustcllvm. That might be the most straightforward fix.
If llvm-config inherently relies on a symlink, how do they support Windows?
That would break compiling an rlib which states that it links against a certain dylib when said dylib is not available on the host, right? Currently you only need dylibs to be available when actually linking (that is using a crate type other than rlib or staticlib). It includes , not . Even if just was passed, has a for and thus needs to be present in . Edit: Forgot it is supposed to be in llvm-tools-preview, not in rustc-dev. By the way has never been a symlink afaik. Instead a separate copy was shipped in both the rustc and llvm-tools-preview components. The first for rustc itself to link against and the second for user code to link against. Just like we ship in both the rustc and rustc-dev components. Both copies just happened to be identical.
I just looked at the latest nightly and is present in both and as it should and has the correct filename for it. also has as .
I got confused about when got merged. I though it was already included in the latest nightly. I just looked at the llvm-preview component for that PR and it includes rather than the that is expected. Is it possible to rename it back and patch up the ? There is no way to link against with all linkers without a symlink, while for that is not a problem.
Why can't rustc_driver include ?
Because the linker will prefix the name with and postfix it with , so would cause the linker to look for rather than . (notice the different location of ) The only portable way to link against is to create a symlink from to , set the to and then tell the linker to link against . But on Windows we can't use symlinks. While on linux is possible, this is not the case on most other targets.
Windows doesn't have a concept of sonames, so I don't think a symlink would be used there. I don't know what the dylib is called there. We use static linking there anyway. So I think we wouldn't actually ship a symlink on anything but Linux. More problematic is the other part of this comment: If rustup-toolchain-install-master can't deal with symlinks, that's also a problem for Linux.
Any platform except Windows you mean?
As far as I can tell, dist-x86_64-linux is the only configuration where we link LLVM dynamically. (Well and the llvm-16/llvm-17 images, but that's non-dist and a different situation anyway.)
CI also starts with this exact same issue.
So to summarize, I see a few options here: Undo the library name change by carrying a patch in our LLVM fork. Implies carrying a long-term patch to LLVM, though a fairly small one. Undo the library name change after the fact. As pointed out, this isn't just a matter of moving the files, we also have to fix up the DTSONAME, which doesn't appear straightforward. Would require adding a dependency on patchelf? Ship the symlink in rustup components like rustc-dev, on Linux only. May require updates to tooling like rustup-toolchain-install-master. Change the way rustc links against upstream dylib dependencies, by resolving library names. Requires replicating linker search path logic and may break other other things. Not sure if this is possible. Same as 4, but only do this in rustllvms Again, not sure about the consequences, but at least this is more limited. I think 3 is probably ideal long term, but depends on just how broken symlink support is right now. Is this a matter of "we'll copy the file instead of symlinking" or "rustup-toolchain-install-master is going to abort"? Maybe knows. The easiest fix would be 1.
There's another fix, which is to ship a with content
Oooh, that's a great idea!
I got klint CI working with the fix:
Option 6, convince LLVM that this way of naming libraries is a bad idea and causes problems? I can't tell to what extent this is caused by Rust idiosyncrasies vs LLVM doing something strange. Wait, a .so file can be just a text file...?!?
Basically, LLVM used to do it's own thing here, and now follows the standard convention for shared object naming on Linux. This turns out to be quite inconvenient for us, but I don't think it would be reasonable to ask LLVM to undo the change. (Though, imho, this change really should not have been done in an rc3 release...) It can be a linker script. Somewhat unusual, but things like or are often linker scripts.
Well, if that linker script solution works that would be great. :)
This is now beginning to block Miri development. If someone reading along knows enough about linkers to approve that would be great. :)

// If we have a symlink like libLLVM-18.so -> libLLVM.so.18.1, install the target of the // symlink, which is what will actually get loaded at runtime. builder.install(&t!(fs::canonicalize(source)), destination, 0o644); <ins> let full_dest = destination.join(source.file_name().unwrap()); </ins> if install_symlink { <del> // If requested, also install the symlink. This is used by download-ci-llvm. let full_dest = destination.join(source.file_name().unwrap()); </del> <ins> // For download-ci-llvm, also install the symlink, to match what LLVM does. Using a // symlink is fine here, as this is not a rustup component. </ins> builder.copy(&source, &full_dest); <ins> } else { // Otherwise, replace the symlink with an equivalent linker script. This is used when // projects like miri link against librustc_driver.so. We don't use a symlink, as // these are not allowed inside rustup components. let link = t!(fs::read_link(source)); t!(std::fs::write(full_dest, format!("INPUT({})n", link.display()))); </ins> } } else { builder.install(&source, destination, 0o644);


Question:
Fuzzer generated custom MIR This code has UB under Stacked Borrows, but UB-free under Tree Borrows. Right: Wrong: While it looks like an LLVM issue, I couldn't get an IR-only reproduction. It's possible that rustc is producing IR with UBs On latest nightly cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I am only refraining from adding I-unsound so far because there's no surface Rust repro yet.
We should get , but we get .
claim
Upstream issue:
I do not have such qualms, especially because a fix is already on the way.
WG-prioritization assigning priority (). Keeping an eye on this issue to evaluate what to do when the LLVM fix lands label -I-prioritize +P-high

<del> Subproject commit 7973f3560287d750500718314a0fd4025bd8ac0e </del> <ins> Subproject commit 84f190a4abf58bbd5301c0fc831f7a96acea246f </ins>


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: --
cc

let suggest_eq = if self.token.kind == token::Dot && let _ = self.bump() && let mut snapshot = self.create_snapshot_for_diagnostic() <del> && let Ok(_) = snapshot.parse_dot_suffix_expr( colon_sp, self.mk_expr_err( </del> <ins> && let Ok(_) = snapshot .parse_dot_suffix_expr( </ins> colon_sp, <del> self.dcx().delayed_bug("error during `:` -> `=` recovery"), ), ) { </del> <ins> self.mk_expr_err( colon_sp, self.dcx() .delayed_bug("error during `:` -> `=` recovery"), ), ) .map_err(Diag::cancel) { </ins> true } else if let Some(op) = self.check_assoc_op() && op.node.can_continue_expr_unambiguously()


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: --
cc

<ins> #![allow(unused)] fn test_122112() { // Make sure we don't ICE if parsing in recovery fails let _: std::env::temp_dir().join(&self, push: Box<usize>);  //~ ERROR expected one of } </ins> fn main() { let _: std::env::temp_dir().join("foo"); //~ ERROR expected one of }


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: --
cc

error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` <del> --> $DIR/recover-colon-instead-of-eq-in-local.rs:2:32 </del> <ins> --> $DIR/recover-colon-instead-of-eq-in-local.rs:5:32 | LL |     let _: std::env::temp_dir().join(&self, push: Box<usize>); |          -                     ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=` |          | |          while parsing the type for `_` error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` --> $DIR/recover-colon-instead-of-eq-in-local.rs:9:32 </ins> | LL |     let _: std::env::temp_dir().join("foo"); |          -                     ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=`


Question:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: --
cc

|          while parsing the type for `_` |          help: use `=` if you meant to assign <del> error: aborting due to 1 previous error </del> <ins> error: aborting due to 2 previous errors </ins>


Question:
<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.

kind: hir::GenericParamKind::Type { default: Some(ty), .. }, .. }) => vec![*ty], <ins> hir::Node::AnonConst(_) if let Some(const_param_id) = tcx.hir().opt_const_param_default_param_def_id(hir_id) && let hir::Node::GenericParam(hir::GenericParam { kind: hir::GenericParamKind::Const { ty, .. }, .. }) = tcx.hir_node_by_def_id(const_param_id) => { vec![*ty] } </ins> ref node => bug!("Unexpected node {:?}", node), }, WellFormedLoc::Param { function: _, param_idx } => {


Question:
<!-- ICE: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })', 'error: internal compiler error: Unexpected node AnonConst(AnonConst { hirid: HirId(DefId(0:3 ~ [9608]::Trait).5), defid: DefId(0:5 ~ [9608]::Trait::{constant}), body: BodyId { hirid: HirId(DefId(0:3 ~ [9608]::Trait).6) } })' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [diagnostichirwfcheck] performing HIR wf-checking for predicate at item [typeck] type-checking [checkmatch] match-checking [mirbuilt] building MIR for [mirconst] preparing for borrow checking [mirconstqualif] const checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [mirdropselaboratedandconstchecked] elaborating drops for [mirforctfe] caching mir of for CTFE [evaltoallocationraw] const-evaluating + checking [evaltovaltree] evaluating type-level constant [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seeeems to bisect to :thinking: cc
Thanks Will take a look. claim
Reduced further:
the original (none reduced) one still ices :sweat_smile:
From what I can tell, it seems to have been fixed : Looks like I'm missing something
I have now opened PR to test the below original reproducer:
Sorry for causing the issue to be closed via the PR merge without asking you first. If you still believe the ICE is not fixed please reopen it.

<ins> trait Trait<const N: Trait = bar> { //~^ ERROR cannot find value `bar` in this scope //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR cycle detected when computing type of `Trait::N` //~| ERROR `(dyn Trait<{const error}> + 'static)` is forbidden as the type of a const generic parameter //~| WARN trait objects without an explicit `dyn` are deprecated //~| WARN this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2021! fn fnc(&self) { } } fn main() {} </ins>