| Age | Commit message (Collapse) | Author | Lines |
|
Without any tests/benchmarks that show some improvement, it's hard to
know whether the change had any positive effect at all. (And if it did,
whether that effect is still achieved today.)
|
|
Account for new `assert!` desugaring in `!condition` suggestion
`rustc` in https://github.com/rust-lang/rust/pull/122661 is going to change the desugaring of `assert!` to be
```rust
match condition {
true => {}
_ => panic!(),
}
```
which will make the edge-case of `condition` being `impl Not<Output = bool>` while not being `bool` itself no longer a straightforward suggestion, but `!!condition` will coerce the expression to be `bool`, so it can be machine applicable.
Transposing https://github.com/rust-lang/rust-clippy/pull/15453/ to the rustc repo.
r? `````@samueltardieu`````
|
|
Rename entered trace span variables from `_span` to `_trace`
This PR just changes the name of `EnteredTraceSpan` variables used to automatically close tracing spans when going out of scope. This renaming was needed because `_span` could possibly be confused with the `Span` type in rustc, so I used `_trace` as suggested in https://github.com/rust-lang/rust/pull/144727#discussion_r2247267670.
|
|
Tweak invalid builtin attribute output
- Add link to reference/docs when possible
- More accurate suggestions by supporting multiple alternative suggestions
```
error: malformed `crate_type` attribute input
--> $DIR/crate-type-macro-call.rs:1:1
|
LL | #![crate_type = foo!()]
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= note: for more information, visit <https://doc.rust-lang.org/reference/linkage.html>
help: the following are the possible correct uses
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "bin"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "cdylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "dylib"]
|
LL - #![crate_type = foo!()]
LL + #![crate_type = "lib"]
|
= and 4 other candidates
```
|
|
Extract TraitImplHeader in AST/HIR
Several fields of `Impl` are only applicable when it's a trait impl. This moves those fields into a new struct that is only present for trait impls.
|
|
|
|
|
|
|
|
`rustc` is going to change the desugaring of `assert!` to be
```rust
match condition {
true => {}
_ => panic!(),
}
```
which will make the edge-case of `condition` being `impl Not<Output = bool>`
while not being `bool` itself no longer a straightforward suggestion,
but `!!condition` will coerce the expression to be `bool`, so it can be
machine applicable.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144966 ( Improve suggestion for "missing function argument" on multiline call)
- rust-lang/rust#145111 (remove some unused private trait impls)
- rust-lang/rust#145221 (Fix Cargo cross-compilation (take two))
- rust-lang/rust#145247 (Update `sysinfo` version to `0.37.0`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Ship correct Cranelift library in its dist component
The first commit adds a post-dist UI test to check that Cranelift can be used with the extracted dist x64 Linux archive.
The original codegen copy logic in the Cranelift dist step was a bit redundant, and I didn't notice in https://github.com/rust-lang/rust/pull/144787 that it's copying the codegen backend from the build compiler's sysroot, rather than the target compiler's sysroot. The second commit modifies the logic to directly access the built codegen file (there is no need to search for it in the compiler's sysroot, in fact when you run just `x dist rustc_codegen_cranelift`, it shouldn't "taint" the sysroot with the codegen backend! Which it did before https://github.com/rust-lang/rust/pull/144787) and copy it to the tarball under a normalized name. Thus we get around any similar potential issues in the future, and make previously implicit logic more explicit.
This also fixes running just `x dist rustc_codegen_cranelift` without enabling `cranelift` in `rust.codegen-backends`, which should have been enabled by https://github.com/rust-lang/rust/pull/144787, but it didn't work fully, because the dist step tried to copy the codegen backend from the compiler's sysroot, but it didn't contain the codegen backend if it was not enabled by `rust.codegen-backends`.
Fixes: https://github.com/rust-lang/rust/issues/145201
try-job: dist-x86_64-linux
|
|
_span could possibly be confused with the Span type in rustc
|
|
|
|
|
|
Constify remaining traits/impls for `const_ops`
Tracking issue: rust-lang/rust#143802
This is split into two commits for ease of reviewability:
1. Updates the `forward_ref_*` macros to accept multiple attributes (in anticipation of needing `rust_const_unstable` attributes) and also *require* attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before.
2. Actually constify the traits/impls.
A few random other notes on the implementation specifically:
* I unindented the attributes that were passed to the `forward_ref_*` macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse.
----
As far as the actual changes go, this constifies the following additional traits:
* `Neg`
* `Not`
* `BitAnd`
* `BitOr`
* `BitXor`
* `Shl`
* `Shr`
* `AddAssign`
* `SubAssign`
* `MulAssign`
* `DivAssign`
* `RemAssign`
* `BitAndAssign`
* `BitOrAssign`
* `BitXorAssign`
* `ShlAssign`
* `ShrAssign`
In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in `library/core/src/internal_macros.rs`. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an `&` to one or both sides of an operator for primitives.
Additionally, I constified the implementations for `Wrapping`, `Saturating`, and `NonZero` as well, since all of them forward to already-const-stable methods. (potentially via intrinsics, to avoid extra overhead)
There are three "non-primitive" types which implement these traits, listed below. Note that I put "non-primitive" in quotes since I'm including `Wrapping`, `Saturating`, and `NonZero`, which are just wrappers over primitives.
* `Duration` (arithmetic operations)
* `SystemTime` (arithmetic operations)
* `Ipv4Addr` (bit operations)
* `Ipv6Addr` (bit operations)
Additionally, because the methods on `SystemTime` needed to make these operations const were not marked const, a separate tracking issue for const-stabilising those methods is rust-lang/rust#144517.
Stuff left out of this PR:
* `Assume` (this could trivially be made const, but since the docs indicate this is still under heavy design, I figured I'd leave it out)
* `Instant` (this could be made const, but cannot reasonably be constructed at constant time, so, isn't useful)
* `SystemTime` (will submit separate PR)
* SIMD types (I'm tackling these all at once later; see rust-lang/portable-simd#467)
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_CONCERN-ISSUE_START -->
> [!NOTE]
> # Concerns (0 active)
>
> - ~~[May break Clippy](https://github.com/rust-lang/rust/pull/143949#issuecomment-3081466077)~~ resolved in [this comment](https://github.com/rust-lang/rust/pull/143949#issuecomment-3083628215)
>
> *Managed by ```@rustbot`—see`` [help](https://forge.rust-lang.org/triagebot/concern.html) for details.*
<!-- TRIAGEBOT_CONCERN-ISSUE_END -->
<!-- TRIAGEBOT_END -->
|
|
|
|
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: 
|
|
|
|
compiler & tools dependencies:
Locking 18 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-svg v0.1.9 -> v0.1.10
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating camino v1.1.10 -> v1.1.11
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating cxx v1.0.161 -> v1.0.166
Updating cxx-build v1.0.161 -> v1.0.166
Updating cxxbridge-cmd v1.0.161 -> v1.0.166
Updating cxxbridge-flags v1.0.161 -> v1.0.166
Updating cxxbridge-macro v1.0.161 -> v1.0.166
Updating derive-where v1.5.0 -> v1.6.0
Updating hashbrown v0.15.4 -> v0.15.5
Updating indenter v0.3.3 -> v0.3.4
Updating rustversion v1.0.21 -> v1.0.22
Updating scratch v1.0.8 -> v1.0.9
Updating zerovec v0.11.2 -> v0.11.4
note: pass `--verbose` to see 36 unchanged dependencies behind latest
library dependencies:
Locking 1 package to latest compatible version
Updating hashbrown v0.15.4 -> v0.15.5
note: pass `--verbose` to see 2 unchanged dependencies behind latest
rustbook dependencies:
Locking 10 packages to latest compatible versions
Updating anstream v0.6.19 -> v0.6.20
Updating anstyle-query v1.1.3 -> v1.1.4
Updating anstyle-wincon v3.0.9 -> v3.0.10
Updating cc v1.2.31 -> v1.2.32
Updating clap v4.5.42 -> v4.5.43
Updating clap_builder v4.5.42 -> v4.5.43
Updating clap_complete v4.5.55 -> v4.5.56
Updating hashbrown v0.15.4 -> v0.15.5
Updating rustversion v1.0.21 -> v1.0.22
Updating zerovec v0.11.2 -> v0.11.4
|
|
remove `P`
Previous work: rust-lang/rust#141603
MCP: https://github.com/rust-lang/compiler-team/issues/878
cc `@nnethercote`
|
|
elsewhere
`typos.toml` has an exception for "numer", to avoid flagging its use as
an abbreviation for "numerator". Remove the use of that abbrevation,
spelling out "numerator" instead, and remove the exception, so that typo
checks can find future instances of "numer" as a typo for "number".
|
|
|
|
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.
|
|
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.
|
|
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
|
|
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.
|
|
|
|
|
|
Rollup of 19 pull requests
Successful merges:
- rust-lang/rust#144400 (`tests/ui/issues/`: The Issues Strike Back [3/N])
- rust-lang/rust#144764 ([codegen] assume the tag, not the relative discriminant)
- rust-lang/rust#144807 (Streamline config in bootstrap)
- rust-lang/rust#144899 (Print CGU reuse statistics in `-Zprint-mono-items`)
- rust-lang/rust#144909 (Add new `test::print_merged_doctests_times` used by rustdoc to display more detailed time information)
- rust-lang/rust#144912 (Resolver: introduce a conditionally mutable Resolver for (non-)speculative resolution.)
- rust-lang/rust#144914 (Add support for `ty::Instance` path shortening in diagnostics)
- rust-lang/rust#144931 ([win][arm64ec] Fix msvc-wholearchive for Arm64EC)
- rust-lang/rust#144999 (coverage: Remove all unstable support for MC/DC instrumentation)
- rust-lang/rust#145009 (A couple small changes for rust-analyzer next-solver work)
- rust-lang/rust#145030 (GVN: Do not flatten derefs with ProjectionElem::Index. )
- rust-lang/rust#145042 (stdarch subtree update)
- rust-lang/rust#145047 (move `type_check` out of `compute_regions`)
- rust-lang/rust#145051 (Prevent name collisions with internal implementation details)
- rust-lang/rust#145053 (Add a lot of NLL `known-bug` tests)
- rust-lang/rust#145055 (Move metadata symbol export from exported_non_generic_symbols to exported_symbols)
- rust-lang/rust#145057 (Clean up some resolved test regressions of const trait removals in std)
- rust-lang/rust#145068 (Readd myself to review queue)
- rust-lang/rust#145070 (Add minimal `armv7a-vex-v5` tier three target)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[win][arm64ec] Fix msvc-wholearchive for Arm64EC
`msvc-wholearchive` was failing on Arm64EC Windows as it requires the `/MACHINE:ARM64EC` flag to be passed to the MSVC linker.
This required splitting the `extra_c_flags` function into a new `extra_linker_flags` function as `/MACHINE:ARM64EC` is not a valid argument to be passed to the MSVC Compiler (instead, `/arm64EC` should be used).
|
|
Rename `begin_panic_handler` to `panic_handler`
Part of https://github.com/rust-lang/rust/issues/116005
|
|
|
|
Clippy subtree update
r? `@Manishearth`
Cargo.lock update due to clippy version bump
|
|
clippy-subtree-update
|
|
Rollup of 19 pull requests
Successful merges:
- rust-lang/rust#137831 (Tweak auto trait errors)
- rust-lang/rust#138689 (add nvptx_target_feature)
- rust-lang/rust#140267 (implement continue_ok and break_ok for ControlFlow)
- rust-lang/rust#143028 (emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching)
- rust-lang/rust#143764 (lower pattern bindings in the order they're written and base drop order on primary bindings' order)
- rust-lang/rust#143808 (Port `#[should_panic]` to the new attribute parsing infrastructure )
- rust-lang/rust#143906 (Miri: non-deterministic floating point operations in `foreign_items`)
- rust-lang/rust#143929 (Mark all deprecation lints in name resolution as deny-by-default and report-in-deps)
- rust-lang/rust#144133 (Stabilize const TypeId::of)
- rust-lang/rust#144369 (Upgrade semicolon_in_expressions_from_macros from warn to deny)
- rust-lang/rust#144439 (Introduce ModernIdent type to unify macro 2.0 hygiene handling)
- rust-lang/rust#144473 (Address libunwind.a inconsistency issues in the bootstrap program)
- rust-lang/rust#144601 (Allow `cargo fix` to partially apply `mismatched_lifetime_syntaxes`)
- rust-lang/rust#144650 (Additional tce tests)
- rust-lang/rust#144659 (bootstrap: refactor mingw dist and fix gnullvm)
- rust-lang/rust#144682 (Stabilize `strict_overflow_ops`)
- rust-lang/rust#145026 (Update books)
- rust-lang/rust#145033 (Reimplement `print_region` in `type_name.rs`.)
- rust-lang/rust#145040 (rustc-dev-guide subtree update)
Failed merges:
- rust-lang/rust#143857 (Port #[macro_export] to the new attribute parsing infrastructure)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Stabilize `strict_overflow_ops`
Closes rust-lang/rust#118260
|
|
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/).
|
|
Revert "Preserve the .debug_gdb_scripts section"
https://github.com/rust-lang/rust/pull/143679 introduces a significant build time perf regression for ripgrep. Let's revert it such that we can investigate it without pressure.
|
|
`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.
|
|
This reverts commit b4d923cea0509933b1fb859930cb20784251f9be.
|
|
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#144552 (Rehome 33 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`)
- rust-lang/rust#144676 (Add documentation for unstable_feature_bound)
- rust-lang/rust#144836 (Change visibility of Args new function)
- rust-lang/rust#144910 (Add regression tests for seemingly fixed issues)
- rust-lang/rust#144913 ([rustdoc] Fix wrong `i` tooltip icon)
- rust-lang/rust#144924 (compiletest: add hint for when a ui test produces no errors)
- rust-lang/rust#144926 (Correct the use of `must_use` on btree::IterMut)
- rust-lang/rust#144928 (Drop `rust-version` from `rustc_thread_pool`)
- rust-lang/rust#144945 (Autolabel PRs that change explicit tail call tests as `F-explicit_tail_calls`)
- rust-lang/rust#144954 (run-make: Allow blessing snapshot files that don't exist yet)
- rust-lang/rust#144971 (num: Rename `isolate_most_least_significant_one` functions)
- rust-lang/rust#144978 (Fix some doc links for intrinsics)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
run-make: Allow blessing snapshot files that don't exist yet
This makes it possible to bless the snapshot files used by `diff()` in newly-created run-make tests, without having to create the files manually beforehand.
r? jieyouxu
|
|
r=clubby789
compiletest: add hint for when a ui test produces no errors
|
|
Instead of collecting pretty printers transitively when building
executables/staticlibs/cdylibs, let the debugger find each crate's
pretty printers via its .debug_gdb_scripts section. This covers the case
where libraries defining custom pretty printers are loaded dynamically.
|
|
This makes it possible to bless the snapshot files used by `diff()` in
newly-created run-make tests, without having to create the files manually
beforehand.
|