| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This updates the rust-version file to 21a19c297d4f5a03501d92ca251bd7a17073c08a.
|
|
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 -->
|
|
|
|
|
|
|
|
internal: Make flycheck generational
|
|
|
|
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: 
|
|
Fix extract_expressions_from_format_string on write!
|
|
**Input**:
```rust
fn main() {
write!(f, "{2+3}$0")
}
```
**Old output**:
```rust
fn main() {
write!("{}"$0, 2+3)
}
```
**This PR output**:
```rust
fn main() {
write!(f, "{}"$0, 2+3)
}
```
|
|
The rustc AST allows both `for<>` binders and `?` polarity
modifiers in trait bounds, but they are parsed in a specific
order and validated for correctness:
1. `for<>` binder is parsed first.
2. Polarity modifiers (`?`, `!`) are parsed second.
3. The parser validates that binders and polarity modifiers
do not conflict:
```rust
if let Some(binder_span) = binder_span {
match modifiers.polarity {
BoundPolarity::Maybe(polarity_span) => {
// Error: "for<...> binder not allowed with ? polarity"
}
}
}
```
This implies:
- `for<> ?Sized` → Valid syntax. Invalid semantics.
- `?for<> Sized` → Invalid syntax.
However, rust-analyzer incorrectly had special-case logic that
allowed `?for<>` as valid syntax. This fix removes that incorrect
special case, making rust-analyzer reject `?for<> Sized` as a
syntax error, matching rustc behavior.
This has caused confusion in other crates (such as syn) which
rely on these files to implement correct syntax evaluation.
|
|
|
|
Add write! and writeln! to minicore
|
|
|
|
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".
|
|
|
|
|
|
|
|
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: 4c7749e8c8e50ad146da599eea3a250160c1bc2b
Filtered ref: 9742b5940dcb4aea810f9ce020a92b3f72ed7bb4
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to 4c7749e8c8e50ad146da599eea3a250160c1bc2b.
|
|
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
|
|
Disable error log for position clamping, its too noisy due to ease of triggering
|
|
|
|
|
|
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.
|
|
rust-lang/dependabot/npm_and_yarn/editors/code/tmp-0.2.4
Bump tmp from 0.2.3 to 0.2.4 in /editors/code
|
|
`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.
|
