diff options
| author | Trevor Gross <t.gross35@gmail.com> | 2024-09-30 19:18:51 -0400 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-09-30 19:18:51 -0400 |
| commit | a0637597b4fd169118bc794363474ef4d5d06e1d (patch) | |
| tree | 2d86795a8614bdfb1d64a2f3281d61669dad0d5a /compiler/rustc_codegen_gcc/src/errors.rs | |
| parent | 40d0ada90911b3cdfb3b55b19b08af60822511b7 (diff) | |
| parent | 7650307c0e9d10c6c0f5e1470629a23218fd7422 (diff) | |
| download | rust-a0637597b4fd169118bc794363474ef4d5d06e1d.tar.gz rust-a0637597b4fd169118bc794363474ef4d5d06e1d.zip | |
Rollup merge of #130966 - RalfJung:ptr-metadata-const-stable, r=scottmcm
make ptr metadata functions callable from stable const fn So far this was done with a bunch of `rustc_allow_const_fn_unstable`. But those should be the exception, not the norm. If we are confident we can expose the ptr metadata APIs *indirectly* in stable const fn, we should just mark them as `rustc_const_stable`. And we better be confident we can do that since it's already been done a while ago. ;) In particular this marks two intrinsics as const-stable: `aggregate_raw_ptr`, `ptr_metadata`. This should be uncontroversial, they are trivial to implement in the interpreter. Cc `@rust-lang/wg-const-eval` `@rust-lang/lang`
Diffstat (limited to 'compiler/rustc_codegen_gcc/src/errors.rs')
0 files changed, 0 insertions, 0 deletions