| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
Fixes rust-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](https://github.com/rust-lang/rust/blob/9c870d30e2d6434c9e9a004b450c5ccffdf3d844/compiler/rustc_hir_analysis/src/lib.rs#L109-L126).
The special handling of "system" is [here](https://github.com/rust-lang/rust/blob/c24914ec8329b22ec7bcaa6ab534a784b2bd8ab9/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.
|
|
add a flag to always apply the maximum float error
|
|
macro matching
|
|
|
|
changelog: [`ptr_cast_constness`]: avoid suggesting unresolvable method
call
Spell check says "unresolvable" isn't a word. Which repository do I open
a PR against to fix that?
Fixes https://github.com/rust-lang/rust-clippy/issues/11317
|
|
changelog: [`option_map_unit`]: preserve `unsafe` blocks
Fixes rust-lang/rust-clippy#15568
|
|
|
|
cleanup and cache proof tree building
There's some cruft left over from when we had deep proof trees. We never encounter overflow when evaluating proof trees. Even if the recursion limit is `0`, we still only hit the overflow limit when evaluating nested goals of the root. The root goal simply inherits the `root_depth` of the `SearchGraph`.
Split `evaluate_root_goal_for_proof_tree` from the rest of the trait solver. This enables us to simplify the implementation of `evaluate_goal_raw` and the `ProofTreeBuilder` as we no longer need to manually track the state of the builder and can instead use separate types for that. It does require making a few internal methods into associated functions taking a `delegate` and a `span` instead of the `EvalCtxt` itself.
I've also split `SearchGraph::evaluate_goal` and `SearchGraph::evaluate_root_goal_for_proof_tree` for the same reason. Both functions don't actually share too much code, so by splitting them each version gets significantly easier to read.
Add a `query evaluate_root_goal_for_proof_tree_raw` to cache proof tree building. This requires arena allocating `inspect::Probe`. I've added a new type alias `I::ProbeRef` for this. We may need to adapt this for rust-analyzer? It would definitely be easy to remove the `Copy` bound here :thinking:
|
|
|
|
This patch introduces an LSX-optimized version of `analyze_source_file`
for the `loongarch64` target. Similar to existing SSE2 implementation
for x86, this version:
- Processes 16-byte chunks at a time using LSX vector intrinsics.
- Quickly identifies newlines in ASCII-only chunks.
- Falls back to the generic implementation when multi-byte UTF-8
characters are detected or in the tail portion.
|
|
|
|
|
|
|
|
|
|
This updates tests/codegen-llvm/issues/issue-118306.rs to pass also
after https://github.com/llvm/llvm-project/pull/155415
|
|
Revert introduction of `[workspace.dependencies]`.
This was done in rust-lang/rust#145740 and rust-lang/rust#145947. It is causing problems for people using r-a on anything that uses the rustc-dev rustup package, e.g. Miri, clippy.
This repository has lots of submodules and subtrees and various different projects are carved out of pieces of it. It seems like `[workspace.dependencies]` will just be more trouble than it's worth.
r? `@Kobzol`
|
|
|
|
|
|
|
|
|
|
|
|
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
|
|
use `qemu-user` instead of `qemu-user-static` for loongarch CI
|
|
|
|
|
|
|
|
|
|
fix: Deduplicate methods in completion by function ID and not by name
|
|
Because duplicates can be found with traits. Worse, the inherent methods could be private, and we'll discover that only later. But even if they're not they're different methods, and its seems worthy to present them all to the user.
|
|
To the extent possible.
Previously they were confused. Sometimes generic params were treated as `Param` and sometimes as `Placeholder`. A completely redundant (in the new solver) mapping of salsa::Id to ints to intern some info where we could just store it uninterned (not in Chalk though, for some weird reason).
Plus fix a cute bug in closure substitution that was caught by the assertions of Chalk but the next solver did not have such assertions. Do we need more assertions?
|
|
|
|
Closes rust-lang/rust-clippy#15579
changelog: `alloc_instead_of_core` fix FP when `alloc` is an alias
|
|
In writing up the reference for frontmatter, I realized that we probably
shouldn't be accepting Unicode Line Ending characters between the code
fence and infostring or trailing after the infostring or a code fence.
In digging into the unicode specification we use for Whitespace, it
divides it up into categories, so I'm deferring to what it says for
horizontal whitespace for what should be used within a line.
Note, I am leaving out support for Unicde Default Ignorable characters.
I figure that can be discussed outside of this change within the
reference and tracking issue.
|
|
|
|
|
|
|
|
|
|
|
|
explicitly end the lifetime of `va_list`
tracking issue: https://github.com/rust-lang/rust/issues/44930
split out from: https://github.com/rust-lang/rust/pull/144549
The `va_list` is created in the compiler itself when the variable argument list `...` is desugared, and hence the lifetime end is not inserted automatically. The value can't outlive the function in which it was created, so it is correct to end the lifetime here. Ending the lifetime explicitly also appears to give slightly better codegen in https://github.com/rust-lang/rust/pull/144549.
I also included a little drive-by improvement to not cast pointers to integers and back again.
r? codegen
|
|
```
error[E0308]: mismatched types
--> $DIR/expr-as-stmt-2.rs:15:15
|
LL | if true { true } else { false } && true;
| ----------^^^^-----------------
| | |
| | expected `()`, found `bool`
| expected this to be `()`
|
help: parentheses are required to parse this as an expression
|
LL | (if true { true } else { false }) && true;
| + +
```
|
|
outside of local_sources
add test against crashing with --html-after-content file
correctly add --html-after-content to env not args
formatting fix for rustdoc-call-locations-after-content/rmake.rs
Use local crate source file as default span in `render_call_locations`
- avoids unwrapping the first file added to the source map as a local file in
`href_from_span`
move test to tests/rustdoc-gui, rename to scrape_examples_ice
test link is correct
use rustdocflags, rename path in example, track lock file
factor out duplicate function calls
use compile-flags to make sure the after.html file is actually included in the rustdoc call
fix goml go-to path
increment assert-count in sidebar-source-code.goml
adjust crate-search width in search-result-display.goml
renamed Bar in scrape_examples_ice test
make crate name shorter ..
|
|
`-Znext-solver`: support non-defining uses in closures
Cleaned up version of rust-lang/rust#139587, finishing the implementation of https://github.com/rust-lang/types-team/issues/129. This does not affect stable. The reasoning for why this is the case is subtle however.
## What does it do
We split `do_mir_borrowck` into `borrowck_collect_region_constraints` and `borrowck_check_region_constraints`, where `borrowck_collect_region_constraints` returns an enormous `CollectRegionConstraintsResult` struct which contains all the relevant data to actually handle opaque type uses and to check the region constraints later on.
`query mir_borrowck` now simply calls `BorrowCheckRootCtxt::do_mir_borrowck` which starts by iterating over all nested bodies of the current function - visiting nested bodies before their parents - and computing their `CollectRegionConstraintsResult`.
After we've collected all constraints it's time to actually compute the concrete types for the opaques defined by this function. With this PR we now compute the concrete types of opaques for each body before using them to check the non-defining uses of any of them.
After we've computed the concrete types by using all bodies, we use `apply_computed_concrete_opaque_types` for each body to constrain non-defining uses, before finally finishing with `borrowck_check_region_constraints`. We always visit nested bodies before their parents when doing this.
## `ClosureRegionRequirements`
As we only call `borrowck_collect_region_constraints` for nested bodies before type checking the parent, we can't simply use the final `ClosureRegionRequirements` of the nested body during MIR type check. We instead track that we need to apply these requirements in `deferred_closure_requirements`.
We now manually apply the final closure requirements to each body after handling opaque types.
This works, except that we may need the region constraints of nested bodies to successfully define an opaque type in the parent. This is handled by using a new `fn compute_closure_requirements_modulo_opaques` which duplicates region checking - while ignoring any errors - before we've added the constraints from `apply_computed_concrete_opaque_types`. This is necessary for a lot of async tests, as pretty much the entire function is inside of an async block while the opaque type gets defined in the parent.
As an performance optimization we only use `fn compute_closure_requirements_modulo_opaques` in case the nested body actually depends on any opaque types. Otherwise we eagerly call `borrowck_check_region_constraints` and apply the final closure region requirements right away.
## Impact on stable code
Handling the opaque type uses in the parent function now only uses the closure requirements *modulo opaques*, while it previously also considered member constraints from nested bodies. `External` regions are never valid choice regions. Also, member constraints will never constrain a member region if it is required to be outlived by an external region, as that fails the upper-bound check. https://github.com/rust-lang/rust/blob/564ee219127b796d56f74767366fd359758b97de/compiler/rustc_borrowck/src/region_infer/opaque_types/member_constraints.rs#L90-L96
Member constraints therefore never add constraints for external regions :>
r? `@BoxyUwU`
|
|
support non-defining uses in closures
|
|
|
|
Update to ar_archive_writer 0.5
This updates `ar_archive_writer` to 0.5, which in turn was updated to match LLVM 20.1.8: <https://github.com/rust-lang/ar_archive_writer/pull/24>
As part of this, I refactored part of `SymbolWrapper.cpp` to pull common code that I was about to duplicate again into a new function.
NOTE: `ar_archive_writer` does include a breaking change where it no longer supports mangling C++ mangled names for Arm64EC. Since we don't need the mangled name (it's not the "exported name" which we're trying to load from the external dll), I'm setting the `import_name` when building for Arm64EC to prevent error when failing to mangle.
r? `@bjorn3`
|
|
|
|
|
|
|
|
fix `#[loop_match]` on diverging loop
tracking issue: https://github.com/rust-lang/rust/issues/132306
fixes https://github.com/rust-lang/rust/issues/144492
fixes https://github.com/rust-lang/rust/issues/144493
fixes https://github.com/rust-lang/rust/issues/144781
this generated invalid MIR before. issue https://github.com/rust-lang/rust/issues/143806 still has an issue where we assign `state = state` which is invalid in MIR. Fixing that problem is tricky, so I'd like to do that separately.
r? `@bjorn3`
|
|
Normally, changes to rustfmt go into the separate repo. But, in
this case, the bug is introduced in a local change and therefore
isn't present in the rustfmt repo.
|
