| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Add direct accessors for memory addresses in `Machine` (for Miri)
The purpose of this PR is to enable direct (immutable) access to memory addresses in `Machine`, which will be needed for further extension of Miri.
This is done by adding (/completing missings pairs of) accessor functions, with the relevant signatures as follows:
```rust
/* rust/compiler/rustc_middle/src/mir/interpret/allocation.rs */
pub trait AllocBytes {
// ..
fn as_ptr(&self) -> *const u8;
/*fn as_mut_ptr(&mut self) -> *mut u8; -- Already in the compiler*/
}
impl<Prov: Provenance, Extra, Bytes: AllocBytes> Allocation<Prov, Extra, Bytes> {
// ..
pub fn get_bytes_unchecked_raw(&self) -> *const u8;
/*pub fn get_bytes_unchecked_raw_mut(&mut self) -> *mut u8; -- Already in the compiler*/
}
```
```rust
/* rust/compiler/rustc_const_eval/src/interpret/memory.rs */
impl<'tcx, M: Machine<'tcx>> InterpCx<'tcx, M> {
// ..
pub fn get_alloc_bytes_unchecked_raw(&self, id: AllocId) -> InterpResult<'tcx, *const u8>;
pub fn get_alloc_bytes_unchecked_raw_mut(&mut self, id: AllocId) -> InterpResult<'tcx, *mut u8>;
}
```
r? ``@RalfJung``
|
|
promote_consts: some clean-up after experimenting
This is some clean-up after experimenting in #125916,
Prefer to review commit-by-commit.
|
|
|
|
get_bytes_unchecked_raw in allocation.rs; add pub fn get_alloc_bytes_unchecked_raw[_mut] in memory.rs
|
|
`PtrMetadata` doesn't care about `*const`/`*mut`/`&`/`&mut`, so GVN away those casts in its argument.
This includes updating MIR to allow calling PtrMetadata on references too, not just raw pointers. That means that `[T]::len` can be just `_0 = PtrMetadata(_1)`, for example.
# Conflicts:
# tests/mir-opt/pre-codegen/slice_index.slice_get_unchecked_mut_range.PreCodegen.after.panic-abort.mir
# tests/mir-opt/pre-codegen/slice_index.slice_get_unchecked_mut_range.PreCodegen.after.panic-unwind.mir
|
|
|
|
StorageLive: refresh storage (instead of UB) when local is already live
Blocked on [this FCP](https://github.com/rust-lang/rust/issues/99160#issuecomment-2155924538), which also contains the motivation.
Fixes https://github.com/rust-lang/rust/issues/99160
Fixes https://github.com/rust-lang/rust/issues/98896 (by declaring it not-a-bug)
Fixes https://github.com/rust-lang/rust/issues/119366
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/129
|
|
safe transmute: support non-ZST, variantful, uninhabited enums
Previously, `Tree::from_enum`'s implementation branched into three disjoint cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple variants
This branching (incorrectly) did not differentiate between variantful and variantless uninhabited enums. In both cases, we assumed (and asserted) that uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts are described with `Variants::Single { index }`, are special in their layouts otherwise resemble the `!` type and cannot be descended into like typical enums. This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer their layout to one of their variants"; i.e., enums whose layouts are described with `Variants::Single { index }` and that do have a variant at `index`. This second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with multiple variants", which captures uninhabited enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by ````@RalfJung```` in his review of #126358 to `compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
r? ````@compiler-errors````
|
|
This paves the way for tracking more state (e.g. error tainting) in the diagnostic context handle
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #125829 (rustc_span: Add conveniences for working with span formats)
- #126361 (Unify intrinsics body handling in StableMIR)
- #126417 (Add `f16` and `f128` inline ASM support for `x86` and `x86-64`)
- #126424 ( Also sort `crt-static` in `--print target-features` output)
- #126428 (Polish `std::path::absolute` documentation.)
- #126429 (Add `f16` and `f128` const eval for binary and unary operationations)
- #126448 (End support for Python 3.8 in tidy)
- #126488 (Use `std::path::absolute` in bootstrap)
- #126511 (.mailmap: Associate both my work and my private email with me)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add `f16` and `f128` const eval for binary and unary operationations
Add const evaluation and Miri support for f16 and f128, including unary and binary operations. Casts are not yet included.
Fixes https://github.com/rust-lang/rust/issues/124583
r? ``@RalfJung``
|
|
MIR Shl/Shr: the offset can be computed with rem_euclid
r? ````@scottmcm````
|
|
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes #126460
|
|
Add a spot that was missed in
<https://github.com/rust-lang/rust/pull/121997>.
|
|
This excludes casting, which needs more tests.
|
|
const validation: fix ICE on dangling ZST reference
Fixes https://github.com/rust-lang/rust/issues/126393
I'm not super happy with this fix but I can't think of a better one.
r? `@oli-obk`
|
|
|
|
|
|
|
|
-> CompileTimeInterpCx
to match the terms used in the shared interpreter infrastructure
|
|
r=oli-obk
interpret: update doc comment for find_closest_untracked_caller_location
Also add a doc comment to cur_span.
r? `@compiler-errors`
|
|
|
|
safe transmute: support `Single` enums
Previously, the implementation of `Tree::from_enum` incorrectly treated enums with `Variants::Single` and `Variants::Multiple` identically. This is incorrect for `Variants::Single` enums, which delegate their layout to that of a variant with a particular index (or no variant at all if the enum is empty).
This flaw manifested first as an ICE. `Tree::from_enum` attempted to compute the tag of variants other than the one at `Variants::Single`'s `index`, and fell afoul of a sanity-checking assertion in `compiler/rustc_const_eval/src/interpret/discriminant.rs`. This assertion is non-load-bearing, and can be removed; the routine its in is well-behaved even without it.
With the assertion removed, the proximate issue becomes apparent: calling `Tree::from_variant` on a variant that does not exist is ill-defined. A sanity check the given variant has `FieldShapes::Arbitrary` fails, and the analysis is (correctly) aborted with `Err::NotYetSupported`.
This commit corrects this chain of failures by ensuring that `Tree::from_variant` is not called on variants that are, as far as layout is concerned, nonexistent. Specifically, the implementation of `Tree::from_enum` is now partitioned into three cases:
1. enums that are uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
`Tree::from_variant` is now only invoked in the third case. In the first case, `Tree::uninhabited()` is produced. In the second case, the layout is delegated to `Variants::Single`'s index.
Fixes #125811
|
|
Add Option::is_none_or
ACP: https://github.com/rust-lang/libs-team/issues/212
|
|
Previously, the implementation of `Tree::from_enum` incorrectly
treated enums with `Variants::Single` and `Variants::Multiple`
identically. This is incorrect for `Variants::Single` enums,
which delegate their layout to that of a variant with a particular
index (or no variant at all if the enum is empty).
This flaw manifested first as an ICE. `Tree::from_enum` attempted
to compute the tag of variants other than the one at
`Variants::Single`'s `index`, and fell afoul of a sanity-checking
assertion in `compiler/rustc_const_eval/src/interpret/discriminant.rs`.
This assertion is non-load-bearing, and can be removed; the routine
its in is well-behaved even without it.
With the assertion removed, the proximate issue becomes apparent:
calling `Tree::from_variant` on a variant that does not exist is
ill-defined. A sanity check the given variant has
`FieldShapes::Arbitrary` fails, and the analysis is (correctly)
aborted with `Err::NotYetSupported`.
This commit corrects this chain of failures by ensuring that
`Tree::from_variant` is not called on variants that are, as far as
layout is concerned, nonexistent. Specifically, the implementation
of `Tree::from_enum` is now partitioned into three cases:
1. enums that are uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
`Tree::from_variant` is now only invoked in the third case. In the
first case, `Tree::uninhabited()` is produced. In the second case,
the layout is delegated to `Variants::Single`'s index.
Fixes #125811
|
|
|
|
interpret: dyn trait metadata check: equate traits in a proper way
Hopefully fixes https://github.com/rust-lang/miri/issues/3541... unfortunately we don't have a testcase.
The first commit is just a refactor without functional change.
r? `@oli-obk`
|
|
|
|
|
|
|
|
interpret: do not ICE on padded non-pow2 SIMD vectors
Fixes https://github.com/rust-lang/miri/issues/3458
r? ``@oli-obk``
|
|
We can check that the vtable is for the right trait very early, and then just pass the type around.
|
|
|
|
|
|
|
|
|
|
Unsafe extern blocks
This implements RFC 3484.
Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484
This is better reviewed commit by commit.
|
|
|
|
|
|
|
|
miri: avoid making a full copy of all new allocations
Hopefully fixes https://github.com/rust-lang/miri/issues/3637
r? ``@saethlin``
|
|
|
|
|
|
|
