Fix ICE when passing DefId-creating args to legacy_const_generics. #130443
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
BoxyUwU
reviewed
Sep 16, 2024
veluca93
force-pushed
the
legacy-const-generics-fix
branch
from
a598998 to
77a3a5e
Compare
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 16, 2024
…r=<try> Fix ICE when passing DefId-creating args to legacy_const_generics. r? BoxyUwU Fixes rust-lang#123077
This comment has been minimized.
This comment has been minimized.
veluca93
force-pushed
the
legacy-const-generics-fix
branch
from
77a3a5e to
193df11
Compare
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 16, 2024
…r=<try> Fix ICE when passing DefId-creating args to legacy_const_generics. r? BoxyUwU Fixes rust-lang#123077 Fixes rust-lang#129150
This comment has been minimized.
This comment has been minimized.
klensy
reviewed
Sep 16, 2024
|
☀️ Try build successful - checks-actions |
|
@craterbot check |
|
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
craterbot
added
S-waiting-on-crater
veluca93
force-pushed
the
legacy-const-generics-fix
branch
from
193df11 to
5c5e12f
Compare
This comment has been minimized.
This comment has been minimized.
veluca93
force-pushed
the
legacy-const-generics-fix
branch
from
5c5e12f to
300d8f6
Compare
This comment has been minimized.
This comment has been minimized.
veluca93
force-pushed
the
legacy-const-generics-fix
branch
from
300d8f6 to
ee70cbf
Compare
|
☔ The latest upstream changes (presumably #130674) made this pull request unmergeable. Please resolve the merge conflicts. |
|
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
|
🎉 Experiment
|
craterbot
removed
the
S-waiting-on-crater
veluca93
force-pushed
the
legacy-const-generics-fix
branch
from
75552b3 to
b462c68
Compare
|
@bors r+ |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 16, 2024
…, r=BoxyUwU Fix ICE when passing DefId-creating args to legacy_const_generics. r? BoxyUwU Fixes rust-lang#123077 Fixes rust-lang#129150
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Nov 16, 2024
…, r=BoxyUwU Fix ICE when passing DefId-creating args to legacy_const_generics. r? BoxyUwU Fixes rust-lang#123077 Fixes rust-lang#129150
|
☀️ Test successful - checks-actions |
RalfJung
reviewed
Nov 16, 2024
| @@ -9,6 +9,7 @@ doctest = false | |||
| [dependencies] | |||
| # tidy-alphabetical-start | |||
| rustc_ast = { path = "../rustc_ast" } | |||
| rustc_ast_pretty = { path = "../rustc_ast_pretty" } | |||
There was a problem hiding this comment.
Was this already a transitive dep, or did this change reduce build parallelism?
There was a problem hiding this comment.
It was a dep through rustc_errors (and it also was a direct dep ~10 days ago: b480f0f)
|
Finished benchmarking commit (46e8d20): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -2.3%, secondary -3.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (secondary -10.3%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 791.497s -> 788.11s (-0.43%) |
tmeijn
pushed a commit
to tmeijn/dotfiles
that referenced
this pull request
Jan 22, 2025
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [rust](https://github.com/rust-lang/rust) | minor | `1.83.0` -> `1.84.0` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>rust-lang/rust (rust)</summary> ### [`v1.84.0`](https://github.com/rust-lang/rust/blob/HEAD/RELEASES.md#Version-1840-2025-01-09) [Compare Source](rust-lang/rust@1.83.0...1.84.0) \========================== <a id=" Language"></a> ## Language - [Allow `#[deny]` inside `#[forbid]` as a no-op](rust-lang/rust#121560) - [Show a warning when `-Ctarget-feature` is used to toggle features that can lead to unsoundness due to ABI mismatches](rust-lang/rust#129884) - [Use the next-generation trait solver in coherence](rust-lang/rust#130654) - [Allow coercions to drop the principal of trait objects](rust-lang/rust#131857) - [Support `/` as the path separator for `include!()` in all cases on Windows](rust-lang/rust#125205) - [Taking a raw ref (`raw (const|mut)`) of a deref of a pointer (`*ptr`) is now safe](rust-lang/rust#129248) - [Stabilize s390x inline assembly](rust-lang/rust#131258) - [Stabilize Arm64EC inline assembly](rust-lang/rust#131781) - [Lint against creating pointers to immediately dropped temporaries](rust-lang/rust#128985) - [Execute drop glue when unwinding in an `extern "C"` function](rust-lang/rust#129582) <a id="1.84.0-Compiler"></a> ## Compiler - [Add `--print host-tuple` flag to print the host target tuple and affirm the "target tuple" terminology over "target triple"](rust-lang/rust#125579) - [Declaring functions with a calling convention not supported on the current target now triggers a hard error](rust-lang/rust#129935) - [Set up indirect access to external data for `loongarch64-unknown-linux-{musl,ohos}`](rust-lang/rust#131583) - [Enable XRay instrumentation for LoongArch Linux targets](rust-lang/rust#131818) - [Extend the `unexpected_cfgs` lint to also warn in external macros](rust-lang/rust#132577) - [Stabilize WebAssembly `multivalue`, `reference-types`, and `tail-call` target features](rust-lang/rust#131080) - [Added Tier 2 support for the `wasm32v1-none` target](rust-lang/rust#131487) <a id="1.84.0-Libraries"></a> ## Libraries - [Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`](rust-lang/rust#129329) - [Move `<float>::copysign`, `<float>::abs`, `<float>::signum` to `core`](rust-lang/rust#131304) - [Add `LowerExp` and `UpperExp` implementations to `NonZero`](rust-lang/rust#131377) - [Implement `FromStr` for `CString` and `TryFrom<CString>` for `String`](rust-lang/rust#130608) - [`std::os::darwin` has been made public](rust-lang/rust#123723) <a id="1.84.0-Stabilized-APIs"></a> ## Stabilized APIs - [`Ipv6Addr::is_unique_local`](https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.is_unique_local) - [`Ipv6Addr::is_unicast_link_local`](https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.is_unicast_link_local) - [`core::ptr::with_exposed_provenance`](https://doc.rust-lang.org/stable/core/ptr/fn.with_exposed_provenance.html) - [`core::ptr::with_exposed_provenance_mut`](https://doc.rust-lang.org/stable/core/ptr/fn.with_exposed_provenance_mut.html) - [`<ptr>::addr`](https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.addr) - [`<ptr>::expose_provenance`](https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.expose_provenance) - [`<ptr>::with_addr`](https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.with_addr) - [`<ptr>::map_addr`](https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.map_addr) - [`<int>::isqrt`](https://doc.rust-lang.org/stable/core/primitive.i32.html#method.isqrt) - [`<int>::checked_isqrt`](https://doc.rust-lang.org/stable/core/primitive.i32.html#method.checked_isqrt) - [`<uint>::isqrt`](https://doc.rust-lang.org/stable/core/primitive.u32.html#method.isqrt) - [`NonZero::isqrt`](https://doc.rust-lang.org/stable/core/num/struct.NonZero.html#impl-NonZero%3Cu128%3E/method.isqrt) - [`core::ptr::without_provenance`](https://doc.rust-lang.org/stable/core/ptr/fn.without_provenance.html) - [`core::ptr::without_provenance_mut`](https://doc.rust-lang.org/stable/core/ptr/fn.without_provenance_mut.html) - [`core::ptr::dangling`](https://doc.rust-lang.org/stable/core/ptr/fn.dangling.html) - [`core::ptr::dangling_mut`](https://doc.rust-lang.org/stable/core/ptr/fn.dangling_mut.html) - [`Pin::as_deref_mut`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.as_deref_mut) These APIs are now stable in const contexts - [`AtomicBool::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicBool.html#method.from_ptr) - [`AtomicPtr::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicPtr.html#method.from_ptr) - [`AtomicU8::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU8.html#method.from_ptr) - [`AtomicU16::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU16.html#method.from_ptr) - [`AtomicU32::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU32.html#method.from_ptr) - [`AtomicU64::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU64.html#method.from_ptr) - [`AtomicUsize::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicUsize.html#method.from_ptr) - [`AtomicI8::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI8.html#method.from_ptr) - [`AtomicI16::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI16.html#method.from_ptr) - [`AtomicI32::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI32.html#method.from_ptr) - [`AtomicI64::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI64.html#method.from_ptr) - [`AtomicIsize::from_ptr`](https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicIsize.html#method.from_ptr) - [`<ptr>::is_null`](https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.is_null-1) - [`<ptr>::as_ref`](https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.as_ref-1) - [`<ptr>::as_mut`](https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.as_mut) - [`Pin::new`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.new) - [`Pin::new_unchecked`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.new_unchecked) - [`Pin::get_ref`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.get_ref) - [`Pin::into_ref`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.into_ref) - [`Pin::get_mut`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.get_mut) - [`Pin::get_unchecked_mut`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.get_unchecked_mut) - [`Pin::static_ref`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.static_ref) - [`Pin::static_mut`](https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.static_mut) <a id="1.84.0-Cargo"></a> ## Cargo - [Stabilize MSRV-aware resolver config](rust-lang/cargo#14639) - [Stabilize resolver v3](rust-lang/cargo#14754) <a id="1.84-Rustdoc"></a> ## Rustdoc - [rustdoc-search: improve type-driven search](rust-lang/rust#127589) <a id="1.84.0-Compatibility-Notes"></a> ## Compatibility Notes - [Enable by default the `LSX` target feature for LoongArch Linux targets](rust-lang/rust#132140) - [The unstable `-Zprofile` flag (“gcov-style” coverage instrumentation) has been removed.](rust-lang/rust#131829) This does not affect the stable flags for coverage instrumentation (`-Cinstrument-coverage`) and profile-guided optimization (`-Cprofile-generate`, `-Cprofile-use`), which are unrelated and remain available. - Support for the target named `wasm32-wasi` has been removed as the target is now named `wasm32-wasip1`. This completes the [transition](rust-lang/compiler-team#607) [plan](rust-lang/compiler-team#695) for this target following [the introduction of `wasm32-wasip1`](rust-lang/rust#120468) in Rust 1.78. Compiler warnings on [use of `wasm32-wasi`](rust-lang/rust#126662) introduced in Rust 1.81 are now gone as well as the target is removed. - [The syntax `&pin (mut|const) T` is now parsed as a type which in theory could affect macro expansion results in some edge cases](rust-lang/rust#130635 (comment)) - [Legacy syntax for calling `std::arch` functions is no longer permitted to declare items or bodies (such as closures, inline consts, or async blocks).](rust-lang/rust#130443 (comment)) - [Declaring functions with a calling convention not supported on the current target now triggers a hard error](rust-lang/rust#129935) - [The next-generation trait solver is now enabled for coherence, fixing multiple soundness issues](rust-lang/rust#130654) </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever MR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS45Ny4wIiwidXBkYXRlZEluVmVyIjoiMzkuMTAwLjEiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbIlJlbm92YXRlIEJvdCJdfQ==-->
wip-sync
pushed a commit
to NetBSD/pkgsrc-wip
that referenced
this pull request
Feb 2, 2025
Pkgsrc changes: * Adapt patches, one of the patched files were restructured upstream. * Checksum changes. Upstream changes: Version 1.84.1 (2025-01-30) ========================== - [Fix ICE 132920 in duplicate-crate diagnostics.] (rust-lang/rust#133304) - [Fix errors for overlapping impls in incremental rebuilds.] (rust-lang/rust#133828) - [Fix slow compilation related to the next-generation trait solver.] (rust-lang/rust#135618) - [Fix debuginfo when LLVM's location discriminator value limit is exceeded.] (rust-lang/rust#135643) - Fixes for building Rust from source: - [Only try to distribute `llvm-objcopy` if llvm tools are enabled.] (rust-lang/rust#134240) - [Add Profile Override for Non-Git Sources.] (rust-lang/rust#135433) - [Resolve symlinks of LLVM tool binaries before copying them.] (rust-lang/rust#135585) - [Make it possible to use ci-rustc on tarball sources.] (rust-lang/rust#135722) Version 1.84.0 (2025-01-09) ========================== Language -------- - [Allow `#[deny]` inside `#[forbid]` as a no-op] (rust-lang/rust#121560) - [Show a warning when `-Ctarget-feature` is used to toggle features that can lead to unsoundness due to ABI mismatches] (rust-lang/rust#129884) - [Use the next-generation trait solver in coherence] (rust-lang/rust#130654) - [Allow coercions to drop the principal of trait objects] (rust-lang/rust#131857) - [Support `/` as the path separator for `include!()` in all cases on Windows] (rust-lang/rust#125205) - [Taking a raw ref (`raw (const|mut)`) of a deref of a pointer (`*ptr`) is now safe] (rust-lang/rust#129248) - [Stabilize s390x inline assembly] (rust-lang/rust#131258) - [Stabilize Arm64EC inline assembly] (rust-lang/rust#131781) - [Lint against creating pointers to immediately dropped temporaries] (rust-lang/rust#128985) - [Execute drop glue when unwinding in an `extern "C"` function] (rust-lang/rust#129582) Compiler -------- - [Add `--print host-tuple` flag to print the host target tuple and affirm the "target tuple" terminology over "target triple"] (rust-lang/rust#125579) - [Declaring functions with a calling convention not supported on the current target now triggers a hard error] (rust-lang/rust#129935) - [Set up indirect access to external data for `loongarch64-unknown-linux-{musl,ohos}`] (rust-lang/rust#131583) - [Enable XRay instrumentation for LoongArch Linux targets] (rust-lang/rust#131818) - [Extend the `unexpected_cfgs` lint to also warn in external macros] (rust-lang/rust#132577) - [Stabilize WebAssembly `multivalue`, `reference-types`, and `tail-call` target features] (rust-lang/rust#131080) - [Added Tier 2 support for the `wasm32v1-none` target] (rust-lang/rust#131487) Libraries --------- - [Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`] (rust-lang/rust#129329) - [Move `<float>::copysign`, `<float>::abs`, `<float>::signum` to `core`] (rust-lang/rust#131304) - [Add `LowerExp` and `UpperExp` implementations to `NonZero`] (rust-lang/rust#131377) - [Implement `FromStr` for `CString` and `TryFrom<CString>` for `String`] (rust-lang/rust#130608) - [`std::os::darwin` has been made public] (rust-lang/rust#130635) Stabilized APIs --------------- - [`Ipv6Addr::is_unique_local`] (https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.is_unique_local) - [`Ipv6Addr::is_unicast_link_local`] (https://doc.rust-lang.org/stable/core/net/struct.Ipv6Addr.html#method.is_unicast_link_local) - [`core::ptr::with_exposed_provenance`] (https://doc.rust-lang.org/stable/core/ptr/fn.with_exposed_provenance.html) - [`core::ptr::with_exposed_provenance_mut`] (https://doc.rust-lang.org/stable/core/ptr/fn.with_exposed_provenance_mut.html) - [`<ptr>::addr`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.addr) - [`<ptr>::expose_provenance`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.expose_provenance) - [`<ptr>::with_addr`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.with_addr) - [`<ptr>::map_addr`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.map_addr) - [`<int>::isqrt`] (https://doc.rust-lang.org/stable/core/primitive.i32.html#method.isqrt) - [`<int>::checked_isqrt`] (https://doc.rust-lang.org/stable/core/primitive.i32.html#method.checked_isqrt) - [`<uint>::isqrt`] (https://doc.rust-lang.org/stable/core/primitive.u32.html#method.isqrt) - [`NonZero::isqrt`] (https://doc.rust-lang.org/stable/core/num/struct.NonZero.html#impl-NonZero%3Cu128%3E/method.isqrt) - [`core::ptr::without_provenance`] (https://doc.rust-lang.org/stable/core/ptr/fn.without_provenance.html) - [`core::ptr::without_provenance_mut`] (https://doc.rust-lang.org/stable/core/ptr/fn.without_provenance_mut.html) - [`core::ptr::dangling`] (https://doc.rust-lang.org/stable/core/ptr/fn.dangling.html) - [`core::ptr::dangling_mut`] (https://doc.rust-lang.org/stable/core/ptr/fn.dangling_mut.html) These APIs are now stable in const contexts - [`AtomicBool::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicBool.html#method.from_ptr) - [`AtomicPtr::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicPtr.html#method.from_ptr) - [`AtomicU8::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU8.html#method.from_ptr) - [`AtomicU16::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU16.html#method.from_ptr) - [`AtomicU32::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU32.html#method.from_ptr) - [`AtomicU64::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicU64.html#method.from_ptr) - [`AtomicUsize::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicUsize.html#method.from_ptr) - [`AtomicI8::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI8.html#method.from_ptr) - [`AtomicI16::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI16.html#method.from_ptr) - [`AtomicI32::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI32.html#method.from_ptr) - [`AtomicI64::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicI64.html#method.from_ptr) - [`AtomicIsize::from_ptr`] (https://doc.rust-lang.org/stable/core/sync/atomic/struct.AtomicIsize.html#method.from_ptr) - [`<ptr>::is_null`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.is_null-1) - [`<ptr>::as_ref`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.as_ref-1) - [`<ptr>::as_mut`] (https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.as_mut) - [`Pin::new`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.new) - [`Pin::new_unchecked`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.new_unchecked) - [`Pin::get_ref`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.get_ref) - [`Pin::into_ref`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.into_ref) - [`Pin::get_mut`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.get_mut) - [`Pin::get_unchecked_mut`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.get_unchecked_mut) - [`Pin::static_ref`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.static_ref) - [`Pin::static_mut`] (https://doc.rust-lang.org/stable/core/pin/struct.Pin.html#method.static_mut) Cargo ----- - [Stabilize MSRV-aware resolver config] (rust-lang/cargo#14639) - [Stabilize resolver v3] (rust-lang/cargo#14754) Rustdoc ------- - [rustdoc-search: improve type-driven search] (rust-lang/rust#127589) Compatibility Notes ------------------- - [Enable by default the `LSX` target feature for LoongArch Linux targets] (rust-lang/rust#132140) - [The unstable `-Zprofile` flag ("gcov-style" coverage instrumentation) has been removed.](rust-lang/rust#131829) This does not affect the stable flags for coverage instrumentation (`-Cinstrument-coverage`) and profile-guided optimization (`-Cprofile-generate`, `-Cprofile-use`), which are unrelated and remain available. - Support for the target named `wasm32-wasi` has been removed as the target is now named `wasm32-wasip1`. This completes the [transition] (rust-lang/compiler-team#607) [plan](rust-lang/compiler-team#695) for this target following [the introduction of `wasm32-wasip1`] (rust-lang/rust#120468) in Rust 1.78. Compiler warnings on [use of `wasm32-wasi`] (rust-lang/rust#126662) introduced in Rust 1.81 are now gone as well as the target is removed. - [The syntax `&pin (mut|const) T` is now parsed as a type which in theory could affect macro expansion results in some edge cases] (rust-lang/rust#130635 (comment)) - [Legacy syntax for calling `std::arch` functions is no longer permitted to declare items or bodies (such as closures, inline consts, or async blocks).] (rust-lang/rust#130443 (comment)) - The `wasm32-unknown-emscripten` target's binary release of the standard library is now [built with the latest emsdk 3.1.68] (rust-lang/rust#131533), which fixes an ABI-incompatibility with Emscripten >= 3.1.42. If you are locally using a version of emsdk with an incompatible ABI (e.g. before 3.1.42 or a future one), you should build your code with `-Zbuild-std` to ensure that `std` uses the correct ABI. - [Declaring functions with a calling convention not supported on the current target now triggers a hard error] (rust-lang/rust#129935) - [The next-generation trait solver is now enabled for coherence, fixing multiple soundness issues] (rust-lang/rust#130654)
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 21, 2025
…-obk
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In rust-lang#116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes rust-lang#111709
Fixes rust-lang#96304
Fixes rust-lang#137179
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 21, 2025
…-obk
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In rust-lang#116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes rust-lang#111709
Fixes rust-lang#96304
Fixes rust-lang#137179
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 22, 2025
…-obk
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In rust-lang#116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes rust-lang#111709
Fixes rust-lang#96304
Fixes rust-lang#137179
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 22, 2025
…-obk
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In rust-lang#116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes rust-lang#111709
Fixes rust-lang#96304
Fixes rust-lang#137179
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 22, 2025
…-obk
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In rust-lang#116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes rust-lang#111709
Fixes rust-lang#96304
Fixes rust-lang#137179
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 22, 2025
…-obk
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In rust-lang#116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes rust-lang#111709
Fixes rust-lang#96304
Fixes rust-lang#137179
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 23, 2025
Rollup merge of rust-lang#137180 - compiler-errors:sym-regions, r=oli-obk Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes There are a few intertwined problems with `sym fn` operands in both inline and global asm macros. Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length). Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions: ```rust fn foo<'a>() { asm!("/* ... */", sym bar::<&'a ()>); } ``` The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In rust-lang#116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication. In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands. I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue. As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts). r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this. Fixes rust-lang#111709 Fixes rust-lang#96304 Fixes rust-lang#137179
RalfJung
pushed a commit
to RalfJung/miri
that referenced
this pull request
Feb 24, 2025
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang/rust#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang/rust#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes #111709
Fixes #96304
Fixes #137179
bjorn3
pushed a commit
to rust-lang/rustc_codegen_cranelift
that referenced
this pull request
Feb 24, 2025
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang/rust#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang/rust#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes #111709
Fixes #96304
Fixes #137179
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Feb 26, 2025
Give `global_asm` a fake body to store typeck results, represent `sym fn` as a hir expr to fix `sym fn` operands with lifetimes
There are a few intertwined problems with `sym fn` operands in both inline and global asm macros.
Specifically, unlike other anon consts, they may evaluate to a type with free regions in them without actually having an item-level type annotation to give them a "proper" type. This is in contrast to named constants, which always have an item-level type annotation, or unnamed constants which are constrained by their position (e.g. a const arg in a turbofish, or a const array length).
Today, we infer the type of the operand by looking at the HIR typeck results; however, those results are region-erased, so during borrowck we ICE since we don't expect to encounter erased regions. We can't just fill this type with something like `'static`, since we may want to use real (free) regions:
```rust
fn foo<'a>() {
asm!("/* ... */", sym bar::<&'a ()>);
}
```
The first idea may be to represent `sym fn` operands using *inline* consts instead of anon consts. This makes sense, since inline consts can reference regions from the parent body (like the `'a` in the example above). However, this introduces a problem with `global_asm!`, which doesn't *have* a parent body; inline consts *must* be associated with a parent body since they are not a body owner of their own. In #116087, I attempted to fix this by using two separate `sym` operands for global and inline asm. However, this led to a lot of confusion and also some unattractive code duplication.
In this PR, I adjust the lowering of `global_asm!` so that it's lowered in a "fake" HIR body. This body contains a single expression which is `ExprKind::InlineAsm`; we don't *use* this HIR body, but it's used in typeck and borrowck so that we can properly infer and validate the the lifetimes of `sym fn` operands.
I then adjust the lowering of `sym fn` to instead be represented with a HIR expression. This is both because it's no longer necessary to represent this operand as an anon const, since it's *just* a path expression, and also more importantly to sidestep yet another ICE (rust-lang/rust#137179), which has to do with the existing code breaking an invariant of def-id creation and anon consts. Specifically, we are not allowed to synthesize a def-id for an anon const when that anon const contains expressions with def-ids whose parent is *not* that anon const. This is somewhat related to rust-lang/rust#130443 (comment), which is also a place in the compiler where synthesizing anon consts leads to def-id parenting issue.
As a side-effect, this consolidates the type checking for inline and global asm, so it allows us to simplify `InlineAsmCtxt` a bit. It also allows us to delete a bit of hacky code from anon const `type_of` which was there to detect `sym fn` operands specifically. This also could be generalized to support `const` asm operands with types with lifetimes in them. Since we specifically reject these consts today, I'm not going to change the representation of those consts (but they'd just be turned into inline consts).
r? oli-obk -- mostly b/c you're patient and also understand the breadth of the code that this touches, please reassign if you don't want to review this.
Fixes #111709
Fixes #96304
Fixes #137179
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
r? BoxyUwU
Fixes #123077
Fixes #129150