Skip to content

Commit 42fdd7d

Browse files
authored
Rollup merge of rust-lang#139490 - RalfJung:unstable-intrinsics-docs, r=oli-obk
Update some comment/docs related to "extern intrinsic" removal Follow-up to rust-lang#139455. r? `@oli-obk`
2 parents 24369ad + 742b378 commit 42fdd7d

File tree

3 files changed

+14
-88
lines changed
  • library/core/src/intrinsics
  • src

3 files changed

+14
-88
lines changed

Diff for: library/core/src/intrinsics/mod.rs

+4-8
Original file line numberDiff line numberDiff line change
@@ -5,15 +5,11 @@
55
//!
66
//! # Const intrinsics
77
//!
8-
//! Note: any changes to the constness of intrinsics should be discussed with the language team.
9-
//! This includes changes in the stability of the constness.
10-
//!
11-
//! //FIXME(#132735) "old" style intrinsics support has been removed
12-
//! In order to make an intrinsic usable at compile-time, it needs to be declared in the "new"
13-
//! style, i.e. as a `#[rustc_intrinsic]` function, not inside an `extern` block. Then copy the
14-
//! implementation from <https://github.com/rust-lang/miri/blob/master/src/intrinsics> to
8+
//! In order to make an intrinsic unstable usable at compile-time, copy the implementation from
9+
//! <https://github.com/rust-lang/miri/blob/master/src/intrinsics> to
1510
//! <https://github.com/rust-lang/rust/blob/master/compiler/rustc_const_eval/src/interpret/intrinsics.rs>
16-
//! and make the intrinsic declaration a `const fn`.
11+
//! and make the intrinsic declaration below a `const fn`. This should be done in coordination with
12+
//! wg-const-eval.
1713
//!
1814
//! If an intrinsic is supposed to be used from a `const fn` with a `rustc_const_stable` attribute,
1915
//! `#[rustc_intrinsic_const_stable_indirect]` needs to be added to the intrinsic. Such a change requires

Diff for: src/doc/unstable-book/src/language-features/intrinsics.md

+2-1
Original file line numberDiff line numberDiff line change
@@ -53,7 +53,8 @@ Various intrinsics have native MIR operations that they correspond to. Instead o
5353
backends to implement both the intrinsic and the MIR operation, the `lower_intrinsics` pass
5454
will convert the calls to the MIR operation. Backends do not need to know about these intrinsics
5555
at all. These intrinsics only make sense without a body, and can be declared as a `#[rustc_intrinsic]`.
56-
The body is never used, as calls to the intrinsic do not exist anymore after MIR analyses.
56+
The body is never used as the lowering pass implements support for all backends, so we never have to
57+
use the fallback logic.
5758

5859
## Intrinsics without fallback logic
5960

Diff for: src/tools/rust-analyzer/crates/ide/src/hover/tests.rs

+8-79
Original file line numberDiff line numberDiff line change
@@ -6882,85 +6882,14 @@ pub fn foo() {}
68826882

68836883
#[test]
68846884
fn hover_feature() {
6885-
check(
6886-
r#"#![feature(intrinsics$0)]"#,
6887-
expect![[r#"
6888-
*intrinsics*
6889-
```
6890-
intrinsics
6891-
```
6892-
___
6893-
6894-
# `intrinsics`
6895-
6896-
The tracking issue for this feature is: None.
6897-
6898-
Intrinsics are rarely intended to be stable directly, but are usually
6899-
exported in some sort of stable manner. Prefer using the stable interfaces to
6900-
the intrinsic directly when you can.
6901-
6902-
------------------------
6903-
6904-
6905-
## Intrinsics with fallback logic
6906-
6907-
Many intrinsics can be written in pure rust, albeit inefficiently or without supporting
6908-
some features that only exist on some backends. Backends can simply not implement those
6909-
intrinsics without causing any code miscompilations or failures to compile.
6910-
All intrinsic fallback bodies are automatically made cross-crate inlineable (like `#[inline]`)
6911-
by the codegen backend, but not the MIR inliner.
6912-
6913-
```rust
6914-
#![feature(intrinsics)]
6915-
#![allow(internal_features)]
6916-
6917-
#[rustc_intrinsic]
6918-
const unsafe fn const_deallocate(_ptr: *mut u8, _size: usize, _align: usize) {}
6919-
```
6920-
6921-
Since these are just regular functions, it is perfectly ok to create the intrinsic twice:
6922-
6923-
```rust
6924-
#![feature(intrinsics)]
6925-
#![allow(internal_features)]
6926-
6927-
#[rustc_intrinsic]
6928-
const unsafe fn const_deallocate(_ptr: *mut u8, _size: usize, _align: usize) {}
6929-
6930-
mod foo {
6931-
#[rustc_intrinsic]
6932-
const unsafe fn const_deallocate(_ptr: *mut u8, _size: usize, _align: usize) {
6933-
panic!("noisy const dealloc")
6934-
}
6935-
}
6936-
6937-
```
6938-
6939-
The behaviour on backends that override the intrinsic is exactly the same. On other
6940-
backends, the intrinsic behaviour depends on which implementation is called, just like
6941-
with any regular function.
6942-
6943-
## Intrinsics lowered to MIR instructions
6944-
6945-
Various intrinsics have native MIR operations that they correspond to. Instead of requiring
6946-
backends to implement both the intrinsic and the MIR operation, the `lower_intrinsics` pass
6947-
will convert the calls to the MIR operation. Backends do not need to know about these intrinsics
6948-
at all. These intrinsics only make sense without a body, and can be as a `#[rustc_intrinsic]`.
6949-
The body is never used, as calls to the intrinsic do not exist anymore after MIR analyses.
6950-
6951-
## Intrinsics without fallback logic
6952-
6953-
These must be implemented by all backends.
6954-
6955-
### `#[rustc_intrinsic]` declarations
6956-
6957-
These are written like intrinsics with fallback bodies, but the body is irrelevant.
6958-
Use `loop {}` for the body or call the intrinsic recursively and add
6959-
`#[rustc_intrinsic_must_be_overridden]` to the function to ensure that backends don't
6960-
invoke the body.
6961-
6962-
"#]],
6963-
)
6885+
let (analysis, position) = fixture::position(r#"#![feature(intrinsics$0)]"#);
6886+
analysis
6887+
.hover(
6888+
&HoverConfig { links_in_hover: true, ..HOVER_BASE_CONFIG },
6889+
FileRange { file_id: position.file_id, range: TextRange::empty(position.offset) },
6890+
)
6891+
.unwrap()
6892+
.unwrap();
69646893
}
69656894

69666895
#[test]

0 commit comments

Comments
 (0)