stabilize c-style varargs for sysv64, win64, efiapi, aapcs
This has been split up so the PR now only contains the extended_varargs_abi_support stabilization; "system" has been moved to https://github.com/rust-lang/rust/pull/145954.
**Previous (combined) PR description:**
This stabilizes extern block declarations of variadic functions with the system, sysv64, win64, efiapi, aapcs ABIs. This corresponds to the extended_varargs_abi_support and extern_system_varargs feature gates.
The feature gates were split up since it seemed like there might be further discussion needed for what exactly "system" ABI variadic functions should do, but a [consensus](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553) has meanwhile been reached: they shall behave like "C" functions. IOW, the ABI of a "system" function is (bold part is new in this PR):
- "stdcall" for win32 targets **for non-variadic functions**
- "C" for everything else
This had been previously stabilized *without FCP* in https://github.com/rust-lang/rust/pull/116161, which got reverted in https://github.com/rust-lang/rust/pull/136897. There was also a "fun" race condition involved with the system ABI being [added](https://github.com/rust-lang/rust/pull/119587) to the list of variadic-supporting ABIs between the creation and merge of rust-lang/rust#116161.
There was a question raised [here](https://github.com/rust-lang/rust/pull/116161#issuecomment-1983829513) whether t-lang even needs to be involved for a change like this. Not sure if that has meanwhile been clarified? The behavior of the "system" ABI (a Rust-specific ABI) definitely feels like t-lang territory to me.
Fixesrust-lang/rust#100189
Cc `@rust-lang/lang`
# Stabilization report
> ## General design
> ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
AFAIK there is no RFC. The tracking issues are
- https://github.com/rust-lang/rust/issues/100189
- https://github.com/rust-lang/rust/issues/136946
> ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
The only controversial point is whether "system" ABI functions should support variadics.
- Pro: This allows crates like windows-rs to consistently use "system", see e.g. https://github.com/microsoft/windows-rs/issues/3626.
- Cons: `@workingjubilee` had some implementation concerns, but I think those have been [resolved](https://github.com/rust-lang/rust/issues/136946#issuecomment-2967847553). EDIT: turns out Jubilee still has concerns (she mentioned that in a DM); I'll let her express those.
Note that "system" is already a magic ABI we introduced to "do the right thing". This just makes it do the right thing in more cases. In particular, it means that on Windows one can almost always just do
```rust
extern "system" {
// put all the things here
}
```
and it'll do the right thing, rather than having to split imports into non-varargs and varargs, with the varargs in a separate `extern "C"` block (and risking accidentally putting a non-vararg there).
(I am saying "almost" always because some Windows API functions actually use cdecl, not stdcall, on x86. Those of course need to go in `extern "C"` blocks.)
> ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
Actually defining variadic functions in Rust remains unstable, under the [c_variadic feature gate](https://github.com/rust-lang/rust/issues/44930).
> ## Has a Call for Testing period been conducted? If so, what feedback was received?
>
> Does any OSS nightly users use this feature? For instance, a useful indication might be "search <grep.app> for `#![feature(FEATURE_NAME)]` and had `N` results".
There was no call for testing.
A search brings up https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/table/boot.rs using this for "efiapi". This doesn't seem widely used, but it is an "obvious" gap in our support for c-variadics.
> ## Implementation quality
All rustc does here is forward the ABI to LLVM so there's lot a lot to say here...
> ### Summarize the major parts of the implementation and provide links into the code (or to PRs)
>
> An example for async closures: <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>.
The check for allowed variadic ABIs is [here](9c870d30e2/compiler/rustc_hir_analysis/src/lib.rs (L109-L126)).
The special handling of "system" is [here](c24914ec83/compiler/rustc_target/src/spec/abi_map.rs (L82-L85)).
> ### Summarize existing test coverage of this feature
>
> Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing.
>
> Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to those reviewing the tests at stabilization time.
>
> - What does the test coverage landscape for this feature look like?
> - Tests for compiler errors when you use the feature wrongly or make mistakes?
> - Tests for the feature itself:
> - Limits of the feature (so failing compilation)
> - Exercises of edge cases of the feature
> - Tests that checks the feature works as expected (where applicable, `//@ run-pass`).
> - Are there any intentional gaps in test coverage?
>
> Link to test folders or individual tests (ui/codegen/assembly/run-make tests, etc.).
Prior PRs add a codegen test for all ABIs and tests actually calling extern variadic functions for sysv64 and win64:
- https://github.com/rust-lang/rust/pull/144359
- https://github.com/rust-lang/rust/pull/144379
We don't have a way of executing uefi target code in the test suite, so it's unclear how to fully test efiapi. aapcs could probably be done? (But note that we have hardly an such actually-calling-functions tests for ABI things, we almost entirely rely on codegen tests.)
The test ensuring that we do *not* stabilize *defining* c-variadic functions is `tests/ui/feature-gates/feature-gate-c_variadic.rs`.
> ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
None that I am aware of.
> ### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
None that I am aware of.
> ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
`@Soveu` added sysv64, win64, efiapi, aapcs to the list of ABIs that allow variadics, `@beepster4096` added system. `@workingjubilee` recently refactored the ABI handling in the compiler, also affecting this feature.
> ### Which tools need to be adjusted to support this feature. Has this work been done?
>
> Consider rustdoc, clippy, rust-analyzer, rustfmt, rustup, docs.rs.
Maybe RA needs to be taught about the new allowed ABIs? No idea how precisely they mirror what exactly rustc accepts and rejects here.
> ## Type system and execution rules
> ### What compilation-time checks are done that are needed to prevent undefined behavior?
>
> (Be sure to link to tests demonstrating that these tests are being done.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.)
Nothing new here, this just expands the existing support for calling variadic functions to more ABIs.
> ### What updates are needed to the reference/specification? (link to PRs when they exist)
- https://github.com/rust-lang/reference/pull/1936
> ## Common interactions
> ### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
No.
> ### What other unstable features may be exposed by this feature?
None.
Rehome 30 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [#1 of Batch #2]
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that `@Kivooeo` was using.
r? `@jieyouxu`
No source fixes
This PR started as a fix for a rendering bug that [got noticed in #143661](https://github.com/rust-lang/rust/pull/143661#discussion_r2199109530), but turned into a fix for any rendering bugs related to files with no source.
- Don't add an end column separator after a file with no source
- Add column separator before secondary messages with no source
- Render continuation between no source labels
Before
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
╰╴
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
╰ note: private field
│
╰ note: private field
```
After
```
error[E0423]: expected function, tuple struct or tuple variant, found struct `std::collections::HashMap`
╭▸ $DIR/multi-suggestion.rs:17:13
│
LL │ let _ = std::collections::HashMap();
│ ━━━━━━━━━━━━━━━━━━━━━━━━━━━
╰╴
╭▸ $SRC_DIR/std/src/collections/hash/map.rs:LL:COL
│
╰ note: `std::collections::HashMap` defined here
note: constructor is not visible here due to private fields
╭▸ $SRC_DIR/alloc/src/boxed.rs:LL:COL
│
├ note: private field
│
╰ note: private field
```
Note: This PR also makes it so `rustc` and `annotate-snippets` match in these cases
mention lint group in default level lint note
### Summary
This PR updates lint diagnostics so that default-level notes now mention the lint group they belong to, if any.
Fixes: rust-lang/rust#65464.
### Example
```rust
fn main() {
let x = 5;
}
```
Before:
```
= note: `#[warn(unused_variables)]` on by default
```
After:
```
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
```
### Unchanged Cases
Messages remain the same when the lint level is explicitly set, e.g.:
* Attribute on the lint `#[warn(unused_variables)]`:
```
note: the lint level is defined here
LL | #[warn(unused_variables)]
| ^^^^^^^^^^^^^^^^
```
* Attribute on the group `#[warn(unused)]:`:
```
= note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
```
* CLI option `-W unused`:
```
= note: `-W unused-variables` implied by `-W unused`
= help: to override `-W unused` add `#[allow(unused_variables)]`
```
* CLI option `-W unused-variables`:
```
= note: requested on the command line with `-W unused-variables`
```
Properly recover from parenthesized use-bounds (precise capturing lists) plus small cleanups
Fixes https://github.com/rust-lang/rust/issues/145470.
First commit fixes the issue, second one performs some desperately needed cleanups.
The fix shouldn't be a breaking change because IINM the parser always ensures that all brackets are balanced (via a buffer of brackets). Meaning even though we used to accept `(use<>` as a valid precise capturing list, it was guaranteed that we would fail in the end.
Implement declarative (`macro_rules!`) derive macros (RFC 3698)
This is a draft for review, and should not be merged yet.
This is layered atop https://github.com/rust-lang/rust/pull/145153 , and has
only two additional commits atop that. The first handles parsing and provides a
test for various parse errors. The second implements expansion and handles
application.
This implements RFC 3698, "Declarative (`macro_rules!`) derive macros".
Tracking issue: https://github.com/rust-lang/rust/issues/143549
This has one remaining issue, which I could use some help debugging: in
`tests/ui/macros/macro-rules-derive-error.rs`, the diagnostics for
`derive(fn_only)` (for a `fn_only` with no `derive` rules) and
`derive(ForwardReferencedDerive)` both get emitted twice, as a duplicate
diagnostic.
From what I can tell via adding some debugging code,
`unresolved_macro_suggestions` is getting called twice from
`finalize_macro_resolutions` for each of them, because
`self.single_segment_macro_resolutions` has two entries for the macro, with two
different `parent_scope` values. I'm not clear on why that happened; it doesn't
happen with the equivalent code using attrs.
I'd welcome any suggestions for fixing this.
`tests/ui/issues/`: The Issues Strike Back [4/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ````````@jieyouxu````````
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.
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.
```
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();
| ++
```
Parser: Recover from attributes applied to types and generic args
r? compiler
Add clearer error messages for invalid attribute usage in types or generic types
fixesrust-lang/rust#135017fixesrust-lang/rust#144132
`tests/ui/issues/`: The Issues Strike Back [2/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ``@jieyouxu``
`tests/ui/issues/`: The Issues Strike Back [1/N]
I believe I’ve finally brought [my program](https://github.com/Kivooeo/test-manager) to life -- it now handles multiple test moves in one go: plain moves first, then a gentle touch on each file depends on given options. The process should be much smoother now.
Of course, I won’t rush through everything in a few days -- that would be unkind to `@Oneirical.` I’ll pace myself. And also I can't have more than one such PR because `issues.txt` will conflict with previous parts after merging them which is not fun as well.
This PR is just that: first commit - moves; second - regression comments and the occasional .stderr reblesses, also issue.txt and tidy changes. Nothing special, but progress nonetheless. This is for the purpose of preserving test file history during restructuring
Part of https://github.com/rust-lang/rust/issues/133895.
r? `@jieyouxu`
don't link to the nightly version of the Edition Guide in stable lints
As reported in rust-lang/rust#143557 for `rust_2024_incompatible_pat`, most future-Edition-incompatibility lints link to the nightly version of the Edition Guide; the lints were written before their respective Editions (and their guides) stabilized. But now that Rusts 2021 and 2024 are stable, these lints are emitted on stable versions of the compiler, where it makes more sense to present users with links that don't say "nightly" in them.
This does not change the link for `rust_2024_incompatible_pat`. That's handled in rust-lang/rust#144006.
Constify `Index` traits
tracking issue: rust-lang/rust#143775
the `SliceIndex` trait cannot be implemented by users as it is sealed. While it would be useful for the `get` method on slices, it seems weird to have a feature gate for that that isn't also gating index syntax at the same time, so I put them under the same feature gate.
r? ```````@fee1-dead```````
