| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
The fallback is to just ignore the arguments. That is a valid implementation because this intrinsic is just a hint.
I also added `miri::intrinsic_fallback_is_spec` annotation, so that miri now supports these operations. A prefetch intrinsic call is valid on any pointer.
|
|
Miri: fix handling of in-place argument and return place handling
This fixes two separate bugs (in two separate commits):
- If the return place is `_local` and not `*ptr`, we didn't always properly protect it if there were other pointers pointing to that return place.
- If two in-place arguments are *the same* local variable, we didn't always detect that aliasing.
|
|
|
|
expression is a local variable
|
|
const-eval: full support for pointer fragments
This fixes https://github.com/rust-lang/const-eval/issues/72 and makes `swap_nonoverlapping` fully work in const-eval by enhancing per-byte provenance tracking with tracking of *which* of the bytes of the pointer this one is. Later, if we see all the same bytes in the exact same order, we can treat it like a whole pointer again without ever risking a leak of the data bytes (that encode the offset into the allocation). This lifts the limitation that was discussed quite a bit in https://github.com/rust-lang/rust/pull/137280.
For a concrete piece of code that used to fail and now works properly consider this example doing a byte-for-byte memcpy in const without using intrinsics:
```rust
use std::{mem::{self, MaybeUninit}, ptr};
type Byte = MaybeUninit<u8>;
const unsafe fn memcpy(dst: *mut Byte, src: *const Byte, n: usize) {
let mut i = 0;
while i < n {
*dst.add(i) = *src.add(i);
i += 1;
}
}
const _MEMCPY: () = unsafe {
let ptr = &42;
let mut ptr2 = ptr::null::<i32>();
// Copy from ptr to ptr2.
memcpy(&mut ptr2 as *mut _ as *mut _, &ptr as *const _ as *const _, mem::size_of::<&i32>());
assert!(*ptr2 == 42);
};
```
What makes this code tricky is that pointers are "opaque blobs" in const-eval, we cannot just let people look at the individual bytes since *we don't know what those bytes look like* -- that depends on the absolute address the pointed-to object will be placed at. The code above "breaks apart" a pointer into individual bytes, and then puts them back together in the same order elsewhere. This PR implements the logic to properly track how those individual bytes relate to the original pointer, and to recognize when they are in the right order again.
We still reject constants where the final value contains a not-fully-put-together pointer: I have no idea how one could construct an LLVM global where one byte is defined as "the 3rd byte of a pointer to that other global over there" -- and even if LLVM supports this somehow, we can leave implementing that to a future PR. It seems unlikely to me anyone would even want this, but who knows.^^
This also changes the behavior of Miri, by tracking the order of bytes with provenance and only considering a pointer to have valid provenance if all bytes are in the original order again. This is related to https://github.com/rust-lang/unsafe-code-guidelines/issues/558. It means one cannot implement XOR linked lists with strict provenance any more, which is however only of theoretical interest. Practically I am curious if anyone will show up with any code that Miri now complains about - that would be interesting data. Cc `@rust-lang/opsem`
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#139451 (Add `target_env = "macabi"` and `target_env = "sim"`)
- rust-lang/rust#144039 (Use `tcx.short_string()` in more diagnostics)
- rust-lang/rust#144192 (atomicrmw on pointers: move integer-pointer cast hacks into backend)
- rust-lang/rust#144545 (In rustc_pattern_analysis, put `true` witnesses before `false` witnesses)
- rust-lang/rust#144579 (Implement declarative (`macro_rules!`) attribute macros (RFC 3697))
- rust-lang/rust#144649 (Account for bare tuples and `Pin` methods in field searching logic)
- rust-lang/rust#144775 (more strongly dissuade use of `skip_binder`)
- rust-lang/rust#144987 (Enable f16 and f128 on targets that were fixed in LLVM21)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Implement declarative (`macro_rules!`) attribute macros (RFC 3697)
This implements [RFC 3697](https://github.com/rust-lang/rust/issues/143547), "Declarative (`macro_rules!`) attribute macros".
I would suggest reading this commit-by-commit. This first introduces the
feature gate, then adds parsing for attribute rules (doing nothing with them),
then adds the ability to look up and apply `macro_rules!` attributes by path,
then adds support for local attributes, then adds a test, and finally makes
various improvements to errors.
|
|
Now that `macro_rules` macros can define attribute rules, make sure
error messages account for that.
|
|
LorrensP-2158466:miri-float-nondet-foreign-items, r=RalfJung"
This reverts commit 71f04692c32e181ab566c01942f1418dec8662d4, reversing
changes made to 995ca3e532b48b689567533e6b736675e38b741e.
|
|
Rename `begin_panic_handler` to `panic_handler`
Part of https://github.com/rust-lang/rust/issues/116005
|
|
r=RalfJung
Miri: non-deterministic floating point operations in `foreign_items`
Part of [rust-lang/miri/#3555](https://github.com/rust-lang/miri/issues/3555#issue-2278914000), this pr does the `foreign_items` work.
Some things have changed since rust-lang/rust#138062 and rust-lang/rust#142514. I moved the "helpers" used for creating fixed outputs and clamping operations to their defined ranges to `math.rs`. These are now also extended to handle the floating-point operations in `foreign_items`. Tests in `miri/tests/float.rs` were changed/added.
Failing tests in `std` were extracted, run under miri with `-Zmiri-many-seeds=0..1000` and changed accordingly. Double checked with `-Zmiri-many-seeds`.
I noticed that the C standard doesn't specify the output ranges for all of its mathematical operations; it just specifies them as:
```
Returns
The sinh functions return sinh x.
```
So I used [Wolfram|Alpha](https://www.wolframalpha.com/).
|
|
`panic!` does not print any identifying information for threads that are
unnamed. However, in many cases, the thread ID can be determined.
This changes the panic message from something like this:
thread '<unnamed>' panicked at src/main.rs:3:5:
explicit panic
To something like this:
thread '<unnamed>' (0xff9bf) panicked at src/main.rs:3:5:
explicit panic
Stack overflow messages are updated as well.
This change applies to both named and unnamed threads. The ID printed is
the OS integer thread ID rather than the Rust thread ID, which should
also be what debuggers print.
|
|
So we don't need to add normalization to every test that includes a
panic message, add a global normalization to compiletest.
|
|
|
|
Remove unnecessary `rust_` prefixes
part of https://github.com/rust-lang/rust/issues/116005
Honestly, not sure if this can affect linking somehow, also I didn't touched things like `__rust_panic_cleanup` and `__rust_start_panic` which very likely will break something, so just small cleanup here
also didn't changed `rust_panic_without_hook` because it was renamed here https://github.com/rust-lang/rust/pull/144852
r? libs
|
|
Do not give function allocations alignment in consteval and Miri.
We do not yet have a (clear and T-lang approved) design for how `#[align(N)]` on functions should affect function pointers' addresses on various platforms, so for now do not give function pointers alignment in consteval and Miri.
----
Old summary:
Not a full solution to <https://github.com/rust-lang/rust/issues/144661>, but fixes the immediate issue by making function allocations all have alignment 1 in consteval, ignoring `#[rustc_align(N)]`, so the compiler doesn't know if any offset other than 0 is non-null.
A more "principlied" solution would probably be to make function pointers to `#[instruction_set(arm::t32)]` functions be at offset 1 of an align-`max(2, align attribute)` allocation instead of at offset 0 of their allocation during consteval, and on wasm to either disallow `#[align(N)]` where N > 1, or to pad the function table such that the function pointer of a `#[align(N)]` function is a multiple of `N` at runtime.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add support for building and linking against genmc
|
|
|
|
|
|
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: b56aaec52bc0fa35591a872fb4aac81f606e265c
Filtered ref: 12f5e3255df658296af9fc953d8c1ab79ba91ea3
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
|
|
|
|
|
|
Mitigate `#[align]` name resolution ambiguity regression with a rename
Mitigates beta regression rust-lang/rust#143834 after a beta backport.
### Background on the beta regression
The name resolution regression arises due to rust-lang/rust#142507 adding a new feature-gated built-in attribute named `#[align]`. However, unfortunately even [introducing new feature-gated unstable built-in attributes can break user code](https://www.github.com/rust-lang/rust/issues/134963) such as
```rs
macro_rules! align {
() => {
/* .. */
};
}
pub(crate) use align; // `use` here becomes ambiguous
```
### Mitigation approach
This PR renames `#[align]` to `#[rustc_align]` to mitigate the beta regression by:
1. Undoing the introduction of a new built-in attribute with a common name, i.e. `#[align]`.
2. Renaming `#[align]` to `#[rustc_align]`. The renamed attribute being `rustc_align` will not introduce new stable breakages, as attributes beginning with `rustc` are reserved and perma-unstable. This does mean existing nightly code using `fn_align` feature will additionally need to specify `#![feature(rustc_attrs)]`.
This PR is very much a short-term mitigation to alleviate time pressure from having to fully fix the current limitation of inevitable name resolution regressions that would arise from adding any built-in attributes. Long-term solutions are discussed in [#t-lang > namespacing macro attrs to reduce conflicts with new adds](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/namespacing.20macro.20attrs.20to.20reduce.20conflicts.20with.20new.20adds/with/529249622).
### Alternative mitigation options
[Various mitigation options were considered during the compiler triage meeting](https://github.com/rust-lang/rust/issues/143834#issuecomment-3084415277), and those consideration are partly reproduced here:
- Reverting the PR doesn't seem very minimal/trivial, and carries risks of its own.
- Rename to a less-common but aim-to-stabilization name is itself not safe nor convenient, because (1) that risks introducing new regressions (i.e. ambiguity against the new name), and (2) lang would have to FCP the new name hastily for the mitigation to land timely and have a chance to be backported. This also makes the path towards stabilization annoying.
- Rename the attribute to a rustc attribute, which will be perma-unstable and does not cause new ambiguities in stable code.
- This alleviates the time pressure to address *this* regression, or for lang to have to rush an FCP for some new name that can still break user code.
- This avoids backing out a whole implementation.
### Review advice
This PR is best reviewed commit-by-commit.
- Commit 1 adds a test `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` which demonstrates the current name resolution regression re. `align`. This test fails against current master.
- Commit 2 carries out the renames and test reblesses. Notably, commit 2 will cause `tests/ui/attributes/fn-align-nameres-ambiguity-143834.rs` to change from fail (nameres regression) to pass.
This PR, if the approach still seems acceptable, will need a beta-backport to address the beta regression.
|
|
non-deterministically truncate reads/writes
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#144144 (tests: Skip supported-crate-types test on musl hosts)
- rust-lang/rust#144159 (opt-dist: change build_dir field to be an actual build dir)
- rust-lang/rust#144162 (Debug impls for DropElaborators)
- rust-lang/rust#144189 (Add non-regression test for rust-lang/rust#144168)
- rust-lang/rust#144216 (Don't consider unstable fields always-inhabited)
- rust-lang/rust#144229 (Miri subtree update)
- rust-lang/rust#144230 (Option::as_slice: fix comment)
- rust-lang/rust#144235 (Fix run-make tests on musl hosts)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
Give a message with a span on MIR validation error
It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement.
r? mir
|
|
interpret: fix TypeId pointers being considered data pointers
Fixes https://github.com/rust-lang/miri/issues/4477
r? ````@oli-obk````
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#141076 (fix Zip unsoundness (again))
- rust-lang/rust#142444 (adding run-make test to autodiff)
- rust-lang/rust#143704 (Be a bit more careful around exotic cycles in in the inliner)
- rust-lang/rust#144073 (Don't test panic=unwind in panic_main.rs on Fuchsia)
- rust-lang/rust#144083 (miri sleep tests: increase slack)
- rust-lang/rust#144092 (bootstrap: Detect musl hosts)
- rust-lang/rust#144098 (Do not lint private-in-public for RPITIT)
- rust-lang/rust#144103 (Rename `emit_unless` to `emit_unless_delay`)
- rust-lang/rust#144108 (Ignore tests/run-make/link-eh-frame-terminator/rmake.rs when cross-compiling)
- rust-lang/rust#144115 (fix outdated comment)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
