Revert "Port `#[allow_internal_unsafe]` to the new attribute system"
This reverts commit 4f7a6ace9e2f2192af7b5d32f4b1664189e0e143 (PR: https://github.com/rust-lang/rust/pull/144857)
r? `@Kobzol`
cc: `@scrabsha`
clean revert it seems :3
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
Enable f16 and f128 on targets that were fixed in LLVM21
LLVM21 fixed the new float types on a number of targets:
* SystemZ gained f16 support https://github.com/llvm/llvm-project/pull/109164
* Hexagon now uses soft f16 to avoid recursion bugs https://github.com/llvm/llvm-project/pull/130977
* Mips now correctly handles f128 (actually since LLVM20) https://github.com/llvm/llvm-project/pull/117525
* f128 is now correctly aligned when passing the stack on x86 https://github.com/llvm/llvm-project/pull/138092
Thus, enable the types on relevant targets for LLVM > 21.0.0.
NVPTX also gained handling of f128 as a storage type, but it lacks support for basic math operations so is still disabled here.
try-job: dist-i586-gnu-i586-i686-musl
try-job: dist-i686-linux
try-job: dist-i686-msvc
try-job: dist-s390x-linux
try-job: dist-various-1
try-job: dist-various-2
try-job: dist-x86_64-linux
try-job: i686-gnu-1
try-job: i686-gnu-2
try-job: i686-msvc-1
try-job: i686-msvc-2
try-job: test-various
more strongly dissuade use of `skip_binder`
People unfortunately encounter `Binder` and `EarlyBinder` very early on when starting out. In these cases its often very easy to use `skip_binder` incorrectly. This makes it more explicit that it should generally not be used and points to the relevant `rustc-dev-guide` chapters.
r? `@BoxyUwU`
Account for bare tuples and `Pin` methods in field searching logic
When looking for the field names and types of a given type, account for tuples. This allows suggestions for incorrectly nested field accesses and field name typos to trigger as intended. Previously these suggestions only worked on `ty::Adt`, including tuple structs which are no different to tuples, so they should behave the same in suggestions.
When suggesting field access which would encounter a method not found, do not suggest pinning when those methods are on `impl Pin` itself.
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: one of the expressions' fields has a method of the same name
|
LL | let x = f.0.get_ref();
| ++
```
instead of
```
error[E0599]: no method named `get_ref` found for tuple `(BufReader<File>,)` in the current scope
--> $DIR/missing-field-access.rs:11:15
|
LL | let x = f.get_ref();
| ^^^^^^^ method not found in `(BufReader<File>,)`
|
help: consider pinning the expression
|
LL ~ let mut pinned = std::pin::pin!(f);
LL ~ let x = pinned.as_ref().get_ref();
|
```
Fixrust-lang/rust#144602.
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.
In rustc_pattern_analysis, put `true` witnesses before `false` witnesses
In rustc it doesn't really matter what the order of the witnesses is, but I'm planning to use the witnesses for implementing the "add missing match arms" assist in rust-analyzer, and there `true` before `false` is the natural order (like `Some` before `None`), and also what the current assist does.
The current order doesn't seem to be intentional; the code was created when bool ctors became their own thing, not just int ctors, but for integer, 0 before 1 is indeed the natural order.
r? `@Nadrieril`
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
Use `tcx.short_string()` in more diagnostics
`TyCtxt::short_string` ensures that user visible type paths aren't overwhelming on the terminal output, and properly saves the long name to disk as a side-channel. We already use these throughout the compiler and have been using them as needed when users find cases where the output is verbose. This is a proactive search of some cases to use `short_string`.
We add support for shortening the path of "trait path only".
Every manual use of `short_string` is a bright marker that that error should be using structured diagnostics instead (as they have proper handling of long types without the maintainer having to think abou tthem).
Add `target_env = "macabi"` and `target_env = "sim"`
[RFC 2992](https://github.com/rust-lang/rfcs/pull/2992) ([tracking issue](https://github.com/rust-lang/rust/issues/80970)) introduced `cfg(target_abi = ...)` with the original motivation being Mac Catalyst and Apple Simulator targets. These do not actually have a changed calling convention in the same sense that e.g. `cfg(target_abi = "eabihf")` or pointer authentication (`arm64e`) does, see https://github.com/rust-lang/rust/issues/133331.
Specifically, for Apple Simulator targets, the binary runs under the following conditions:
- Runs with the host macOS kernel (but in a mode configured for iOS/tvOS/...).
- Uses frameworks for the specific simulator version being targetted.
- System file accesses need to be made relative to the `IPHONE_SIMULATOR_ROOT` environment variable.
- Uses host GPUs directly.
And for Mac Catalyst:
- Runs with the host macOS kernel (but in a mode configured for iOS).
- Uses mostly host macOS frameworks (though with a few things changed, e.g. the [`NSImageResizingModeStretch`](https://developer.apple.com/documentation/appkit/nsimage/resizingmode-swift.enum/stretch?language=objc) enum has a different value).
- Uses host GPUs, camera and other peripherals directly.
As can be seen, these seem better suited as `target_env`s, since it really is the environment that the binary is running under that's changed (regardless of the Mac Catalyst "macabi" having "abi" in the name). So this PR adds `target_env = "sim"` and `target_env = "macabi"`, with the idea of possibly deprecating `target_abi = "sim"` and `target_abi = "macabi"` in the far future.
This affects iOS Tier 2 targets (`aarch64-apple-ios-sim`, `x86_64-apple-ios`, `aarch64-apple-ios-macabi` and `x86_64-apple-ios-macabi`), and probably needs a compiler FCP.
Fixes https://github.com/rust-lang/rust/issues/133331.
Reference PR: https://github.com/rust-lang/reference/pull/1781.
Cargo doc PR: https://github.com/rust-lang/cargo/pull/15404.
r? compiler
CC `@workingjubilee`
CC target maintainers `@deg4uss3r` `@thomcc` `@badboy` `@BlackHoleFox` `@madsmtm` `@agg23`
Teach the resolver to consider `macro_rules` macros when looking for a
local attribute. When looking for an attribute and considering a
`macro_rules` macro, load the macro in order to see if it has attribute
rules.
Include a FIXME about tracking multiple macro kinds for a Def instead.
Add infrastructure to apply an attribute macro given argument tokens and
body tokens.
Teach the resolver to consider `macro_rules` macros when looking for an
attribute via a path.
This does not yet handle local `macro_rules` attributes.
- linked-list cursor-like patterns
- issue-46589
These are known-bugs for the polonius alpha, where they show the same
imprecision as NLLs, but are supported by the old datalog
implementation.
This is an example similar to the linked-list cursor examples
where the alpha shows the same imprecision as NLLs, but that can work due to
the loans not being live after the loop, or the constraint graph being
simple enough that the cfg/subset relationships are the same for
reachability and liveness.
These are just some sanity checks to ensure NLLs, the polonius alpha
analysis, and the datalog implementation behave the same on these common
examples.
