| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Simplify polonius location-sensitive analysis
This PR reworks the location-sensitive analysis into what we think is a worthwhile subset of the datalog analysis. A sort of polonius alpha analysis that handles NLL problem case 3 and more, but is still using the faster "reachability as an approximation of liveness", as well as the same loans-in-scope computation as NLLs -- and thus doesn't handle full flow-sensitivity like the datalog implementation.
In the last few months, we've identified this subset as being actionable:
- we believe we can make a stabilizable version of this analysis
- it is an improvement over the status quo
- it can also be modeled in a-mir-formality, or some other formalism, for assurances about soundness, and I believe ````````@nikomatsakis```````` is interested in looking into this during H2.
- and we've identified the areas of work we wish to explore later to gradually expand the supported cases: the differences between reachability and liveness, support of kills, and considerations of time-traveling, for example.
The approach in this PR is to try less to have the graph only represent live paths, by checking whether we reach a live region during traversal and recording the loan as live there, instead of equating traversal with liveness like today because it has subtleties with the typeck edges in statements (that could forward loans to the successor point without ensuring their liveness). We can then also simplify these typeck stmt edges. And we also can simplify traversal by removing looking at kills, because that's enough to handle a bunch of NLL problem 3 cases -- and we can gradually support them more and more in traversal in the future, to reduce the approximation of liveness.
There's still some in-progress pieces of work w/r/t opaque types that I'm expecting [lcnr's opaque types rework](https://github.com/rust-lang/rust/pull/139587), and [amanda's SCCs rework](https://github.com/rust-lang/rust/pull/130227) to handle. That didn't seem to show up in tests until I rebased today (and shows lack of test coverage once again) when https://github.com/rust-lang/rust/pull/142255 introduced a couple of test failures with the new captures rules from edition 2024. It's not unexpected since we know more work is needed with member constraints (and we're not even using SCCs in this prototype yet)
I'll look into these anyways, both for future work, and checking how these other 2 PRs would change things.
---
I'm not sure the following means a lot until we have some formalism in-place, but:
- I've changed the polonius compare-mode to use this analysis: the tests pass with it, except 2 cases with minor diagnostics differences, and the 2 edition 2024 opaque types one I mentioned above and need to investigate
- things that are expected to work still do work: it bootstraps, can run our rustc-perf benchmarks (and the results are not even that bad), and a crater run didn't find any regressions (forgetting that crater currently fails to test around a quarter of all crates 👼)
- I've added tests with improvements, like the NLL problem case 3 and others, as well as some that behave the same as NLLs today and are thus worse than the datalog implementation
r? ````````@jackh726````````
(no rush I know you're deep in phd work and "implmentating" the new trait solver for r-a :p <3)
This also fixes rust-lang/rust#135646, a diagnostics ICE from the previous implementation.
|
|
unstable-book: Add stubs for environment variables; document some of the important ones
This uses a very hacky regex that will probably miss some variables. But having some docs seems better than none at all.
In particular, this documents the following env vars explicitly (cc ````````@madsmtm```````` ````````@flba-eb```````` - do the docs for SDKROOT and QNX_TARGET look right?):
- COLORTERM
- QNX_TARGET
- SDKROOT
- TERM
and generates stubs for the following env vars:
- RUST_BACKTRACE
- RUSTC_BLESS
- RUSTC_BREAK_ON_ICE
- RUSTC_CTFE_BACKTRACE
- RUSTC_FORCE_RUSTC_VERSION
- RUSTC_GRAPHVIZ_FONT
- RUSTC_ICE
- RUSTC_LOG
- RUSTC_RETRY_LINKER_ON_SEGFAULT
- RUSTC_TRANSLATION_NO_DEBUG_ASSERT
- RUST_DEP_GRAPH_FILTER
- RUST_DEP_GRAPH
- RUST_FORBID_DEP_GRAPH_EDGE
- RUST_MIN_STACK
- RUST_TARGET_PATH
- UNSTABLE_RUSTDOC_TEST_LINE
- UNSTABLE_RUSTDOC_TEST_PATH
rendered: 
|
|
Implement `stability_implications` without a visitor.
Since https://github.com/rust-lang/rust/pull/143845, the `Annotator` visitor was a no-op when the crate is not staged_api. This PR avoids using a visitor altogether, making `stability_implications` truly a no-op in most cases.
|
|
Refactor codegen backends in bootstrap
This PR refactors the codegen backend steps, in preparation to make more progress on the integration of the GCC codegen backend in bootstrap. It does several things:
1) Splits the `CodegenBackend` step into two, one for clif and another one for gcc. Even though their code is mostly similar, that's IMO mostly fake similarity, and they do (or will) ultimately require different handling. This was already visible in the requirement of building GCC for cg_gcc, of course.
2) It is now possible to build both backends (and dist cranelift) even if they are not specified in `rust.codegen-backends`. It was quite weird that it wasn't possible to even invoke the corresponding codegen backend if the backend wasn't specified in that array, as that array should ideally only change defaults (see later below).
3) Changes the path specification of these steps to an alias. In other words, instead of `compiler/rustc_codegen_cranelift`, the step is now built only using `rustc_codegen_cranelift` or `cg_clif`. This is done to avoid an annoying clash with `x build compiler`, which would otherwise build both codegen backends after the 2) change.
4) Made the copying of codegen backend artifacts more explicit, in particular in the `Assemble` step.
5) Codifies the semantics of `rust.codegen-backends`, which now only affects the defaults of whether a codegen backend will be included in rustc's sysroot and whether it will be disted in `x dist` by default. We can change the behavior later, e.g. to dist cranelift by default in `x dist` once it becomes stabilized. Currently I left the existing behavior that we use on CI, I just tried to document it better.
I don't think that this requires a change tracker entry, because the defaults should work the same as before. It is just now possible to do `x build/dist rustc_codegen_cranelift` even if CLIF is not in the `codegen-backends` array. It is no longer possible to do `./x build compiler/rustc_codegen_cranelift` though, not sure if that requires a change tracker entry.
There is one thing that I didn't touch yet, and that is the fact that `rust.codegen-backends` not only affects the default behavior of `x dist` w.r.t. Cranelift, but also of `x test`. In other words, `x test rustc_codegen_cranelift` still does not hing if cranelift isn't in `rust.codegen-backends`. I plan to take a look at this once I get to refactoring the test steps.
r? `@jieyouxu`
|
|
remove `P`
Previous work: rust-lang/rust#141603
MCP: https://github.com/rust-lang/compiler-team/issues/878
cc `@nnethercote`
|
|
Co-authored-by: Florian Bartels <108917393+flba-eb@users.noreply.github.com>
Co-authored-by: Mads Marquart <mads@marquart.dk>
|
|
Rollup of 23 pull requests
Successful merges:
- rust-lang/rust#141658 (rustdoc search: prefer stable items in search results)
- rust-lang/rust#141828 (Add diagnostic explaining STATUS_STACK_BUFFER_OVERRUN not only being used for stack buffer overruns if link.exe exits with that exit code)
- rust-lang/rust#144823 (coverage: Extract HIR-related helper code out of the main module)
- rust-lang/rust#144883 (Remove unneeded `drop_in_place` calls)
- rust-lang/rust#144923 (Move several more float tests to floats/mod.rs)
- rust-lang/rust#144988 (Add annotations to the graphviz region graph on region origins)
- rust-lang/rust#145010 (Couple of minor abi handling cleanups)
- rust-lang/rust#145017 (Explicitly disable vector feature on s390x baseline of bad-reg test)
- rust-lang/rust#145027 (Optimize `char::is_alphanumeric`)
- rust-lang/rust#145050 (add member constraints tests)
- rust-lang/rust#145073 (update enzyme submodule to handle llvm 21)
- rust-lang/rust#145080 (Escape diff strings in MIR dataflow graphviz)
- rust-lang/rust#145082 (Fix some bad formatting in `-Zmacro-stats` output.)
- rust-lang/rust#145083 (Fix cross-compilation of Cargo)
- rust-lang/rust#145096 (Fix wasm target build with atomics feature)
- rust-lang/rust#145097 (remove unnecessary `TypeFoldable` impls)
- rust-lang/rust#145100 (Rank doc aliases lower than equivalently matched items)
- rust-lang/rust#145103 (rustc_metadata: remove unused private trait impls)
- rust-lang/rust#145115 (defer opaque type errors, generally greatly reduce tainting)
- rust-lang/rust#145119 (rustc_public: fix missing parenthesis in pretty discriminant)
- rust-lang/rust#145124 (Recover `for PAT = EXPR {}`)
- rust-lang/rust#145132 (Refactor map_unit_fn lint)
- rust-lang/rust#145134 (Reduce indirect assoc parent queries)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Reduce indirect assoc parent queries
Simplify some code that uses multiple queries to get the parent of an associated item.
|
|
Refactor map_unit_fn lint
Just some light refactoring.
|
|
Recover `for PAT = EXPR {}`
I type this constantly, and the existing suggestion to put `in` before the `=` is misleading.
|
|
rustc_public: fix missing parenthesis in pretty discriminant
|
|
defer opaque type errors, generally greatly reduce tainting
fixes the test for rust-lang/rust#135528, does not actually fix that issue properly.
This is useful as it causes the migration to rust-lang/rust#139587 to be a lot easier.
|
|
rustc_metadata: remove unused private trait impls
These are impls for non-reachable traits that don't appear to be used. Please let me know if there is value in keeping some of them for now.
cc `@cjgillot`
|
|
Rank doc aliases lower than equivalently matched items
Follow-up of https://github.com/rust-lang/rust/pull/143988.
cc `@lolbinarycat`
|
|
remove unnecessary `TypeFoldable` impls
|
|
Fix wasm target build with atomics feature
Introduced by https://github.com/rust-lang/rust/pull/115746
close https://github.com/rust-lang/rust/issues/145101
|
|
Fix cross-compilation of Cargo
Regressed in https://github.com/rust-lang/rust/pull/144303. I guess this wasn't seen in other `ToolTarget` tools, because they are more dependent on the compiler and are ~always built together with other stuff that also built the std, while Cargo is relatively self-contained.
Fixes: https://github.com/rust-lang/rust/issues/145059
r? ``@jieyouxu``
|
|
Fix some bad formatting in `-Zmacro-stats` output.
r? `@petrochenkov`
|
|
Escape diff strings in MIR dataflow graphviz
This uses `dot::escape_html` on diff strings so that `<` and `>` are properly escaped in MIR dataflow graphviz.
Previously the output could be malformed. For example, the graphviz for borrow check `MaybeInitializedPlaces` for the example in rust-lang/rust#145032 contained an unescaped `Fork<'_>`.
|
|
update enzyme submodule to handle llvm 21
This currently has a fix / workaround in our local rust-lang/Enzyme fork, which is needed to unblock a few people contributing to std::autodiff. It also permanently disables a component (BCLoader) which we shouldn't need on the rust side, hence saving a bit of compile time and disk space.
Once upstream Enzyme (EnzymeAD/Enzyme) fixed llvm-21 support I'll probably make another pr to drop our local patch.
|
|
add member constraints tests
taken from rust-lang/rust#139587.
|
|
Optimize `char::is_alphanumeric`
Avoid an unnecessary call to `unicode::Alphabetic` when `self` is an ASCII digit (ie `0..=9`).
|
|
Explicitly disable vector feature on s390x baseline of bad-reg test
If the baseline s390x cpu is changed to a newer variant, such as z13, the vector feature may be enabled by default. When rust is packaged on fedora 38 and newer, it is set to z13.
Explicitly disable vector support on the baseline test for consistent results across s390x cpus.
|
|
Couple of minor abi handling cleanups
These are extracted out of a wip branch I have to get rid of the `extern "unadjusted"` ABI for anything other than LLVM intrinsics.
|
|
Add annotations to the graphviz region graph on region origins
This adds
- `(ex<'e>)` for regions whose origin is existential, with name if one exists,
- `(for<'p>)` for regions whose origin is a placeholder, with name if one exists
For any region whose name we don't know, use `'_`.
This has helped _my_ debugging and it doesn't create too bad clutter, I feel.
The change ~~is~~was ridiculously small, but I turned it into a separate PR so we can bikeshed the format.
The following snippet:
```rust
struct Co<'a>(&'a ());
struct Contra<'a>(fn(&'a ()));
// `exists<'e> forall<'p> 'p: 'e` -> ERROR
fn p_outlives_e(
x: for<'e> fn(for<'p> fn(fn(fn(Contra<'e>, Co<'p>)))),
) -> fn(fn(fn(for<'unify> fn(Contra<'unify>, Co<'unify>)))) {
x
```
Gives this graph:
|
|
Move several more float tests to floats/mod.rs
This PR moves several tests to `floats/mod.rs`, as discussed in https://github.com/rust-lang/rust/issues/141726. The tests moved are:
* `test_abs`
* `test_signum`
* `test_is_sign_positive`
* `test_is_sign_negative`
* `test_next_up`
* `test_next_down`
* `test_sqrt_domain`
* `test_clamp_min_greater_than_max`
* `test_clamp_min_is_nan`
* `test_clamp_max_is_nan`
* `test_total_cmp`
This covers all the "easy" tests: the ones that don't have a lot of precision-specific constants. It's not clear to me that it's worth migrating the others.
Each test is its own commit (with the exception of the clamp tests), so it may be easiest to review each commit individually.
r? tgross35
|
|
Remove unneeded `drop_in_place` calls
Might as well pull this out from rust-lang/rust#144561 because this is still used in things like `Vec::truncate` where it'd be nice to allow it be removed if inlined enough to see that the type is `Copy`.
So long as perf says it's ok, at least 🤞
|
|
coverage: Extract HIR-related helper code out of the main module
This is a decent chunk of helper code with a narrow external interface (one function returning one struct), making it a good candidate to be extracted out of the main `rustc_mir_transform::coverage` module.
No functional changes.
|
|
r=wesleywiser
Add diagnostic explaining STATUS_STACK_BUFFER_OVERRUN not only being used for stack buffer overruns if link.exe exits with that exit code
`STATUS_STACK_BUFFER_OVERRUN` is also used for fast abnormal program termination, e.g. by abort(). Emit a special diagnostic to let people know that this most likely doesn't indicate a stack buffer overrun.
This doesn't look up the crash report in the event log to determine what the fast fail error code is. This is due to the way crashes are logged: When a process crash happens, the system logs an "Application Error" event, which contains the exit code and the process ID, but not the fast fail error code. A second event by Windows Error Reporting does contain that fast fail code, but not the process ID - but that event is not emitted at process exit, but when WER has dealt with it (on my system, it happens roughly two seconds later), so querying the code would have to read the `IntegratorReportId`, wait two seconds or potentially longer for the WER event with the same `ReportID`, and read out the code. (Also, that second event doesn't happen if WER is disabled.)
Fixes rust-lang/rust#100519.
|
|
r=GuillaumeGomez
rustdoc search: prefer stable items in search results
fixes https://github.com/rust-lang/rust/issues/138067
this does add a new field to the search index, but since we're only listing unstable items instead of adding a boolean flag to every item, it should only increase the search index size of sysroot crates, since those are the only ones using the `staged_api` feature, at least as far as the rust project is concerned.
|
|
add a scope for `if let` guard temporaries and bindings
This fixes my concern with `if let` guard drop order, namely that the guard's bindings and temporaries were being dropped after their arm's pattern's bindings, instead of before (https://github.com/rust-lang/rust/pull/141295#issuecomment-2968975596). The guard's bindings and temporaries now live in a new scope, which extends until (but not past) the end of the arm, guaranteeing they're dropped before the arm's pattern's bindings.
This only introduces a new scope for match arms with guards. Perf results (https://github.com/rust-lang/rust/pull/143376#issuecomment-3034922617) seemed to indicate there wasn't a significant hit to introduce a new scope on all match arms, but guard patterns (rust-lang/rust#129967) will likely benefit from only adding new scopes when necessary (with some patterns requiring multiple nested scopes).
Tracking issue for `if_let_guard`: rust-lang/rust#51114
Tests are adapted from examples by `@traviscross,` `@est31,` and myself on rust-lang/rust#141295.
|
|
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();
|
```
Fix rust-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`
|
|
|
|
|
|
This allows a macro attribute to implement default arguments by
reapplying itself with the defaults filled in, for instance.
|
|
|
