| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
|
|
From `#[align]` -> `#[rustc_align]`. Attributes starting with `rustc`
are always perma-unstable and feature-gated by `feature(rustc_attrs)`.
See regression RUST-143834.
For the underlying problem where even introducing new feature-gated
unstable built-in attributes can break user code such as
```rs
macro_rules! align {
() => {
/* .. */
};
}
pub(crate) use align; // `use` here becomes ambiguous
```
refer to RUST-134963.
Since the `#[align]` attribute is still feature-gated by
`feature(fn_align)`, we can rename it as a mitigation. Note that
`#[rustc_align]` will obviously mean that current unstable user code
using `feature(fn_aling)` will need additionally `feature(rustc_attrs)`,
but this is a short-term mitigation to buy time, and is expected to be
changed to a better name with less collision potential.
See
<https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202025-07-17/near/529290371>
where mitigation options were considered.
|
|
|
|
|
|
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
miri: fix out-of-bounds error for ptrs with negative offsets
r? ```````@oli-obk```````
|
