Update cargo
18 commits in 64a12460708cf146e16cc61f28aba5dc2463bbb4..fc1518ef02b77327d70d4026b95ea719dd9b8c51
2025-05-30 18:25:08 +0000 to 2025-06-06 04:49:44 +0000
- fix: Make UI tests handle hyperlinks consistently (rust-lang/cargo#15640)
- Update "time out" to "timeout" (rust-lang/cargo#15637)
- fix(workspace): reload current manifest path member only (rust-lang/cargo#15633)
- Update dependencies (rust-lang/cargo#15635)
- fix(publish): Don't tell people to ctrl-c without knowing consequences (rust-lang/cargo#15632)
- refactor: clean up `clippy::perf` lint warnings (rust-lang/cargo#15631)
- fix(package): Skip registry check if its not needed (rust-lang/cargo#15629)
- Add --offline for comp (rust-lang/cargo#15623)
- cargo-credential-libsecret: load libsecret only once (rust-lang/cargo#15295)
- test(publish): Improvements in prep for `-Zpackage-workspace` stabilization (rust-lang/cargo#15628)
- fix(package): Allow packaging of self-cycles with -Zpackage-workspace (rust-lang/cargo#15626)
- docs: clarify `--all-features` not available for all commmands (rust-lang/cargo#15572)
- Remove double reference in Shell::print_json (rust-lang/cargo#15460)
- fix(trim-paths): remap all paths to `build.build-dir` (rust-lang/cargo#15614)
- test(trim-paths): enable more tests for windows-msvc (rust-lang/cargo#15621)
- fix(fingerprint): explicit reason rather than "stale; unknown reason" (rust-lang/cargo#15617)
- Fix cargo add overwriting symlinked Cargo.toml files (rust-lang/cargo#15281)
- chore(deps): update alpine docker tag to v3.22 (rust-lang/cargo#15616)
r? ghost
Enable Non-determinism of float operations in Miri and change std tests
Links to [#4208](https://github.com/rust-lang/miri/issues/4208) and [#3555](https://github.com/rust-lang/miri/issues/3555) in Miri.
Non-determinism of floating point operations was disabled in rust-lang/rust#137594 because it breaks the tests and doc-tests in core/coretests and std. This PR enables some of them.
This pr includes the following changes:
- Enables the float non-determinism but with a lower relative error of 4ULP instead of 16ULP
- These operations now have a fixed output based on the C23 standard, except the pow operations, this is tracked in [#4286](https://github.com/rust-lang/miri/issues/4286#issue-3010677983)
- Changes tests that made incorrect assumptions about the operations, not to make that assumption anymore (from `assert_eq!` to `assert_approx_eq!`.
- Changed the doctests of the stdlib of these operations to compare against fixed constants instead of `f*::EPSILON`, which now succeed with Miri and `-Zmiri-many-seeds`
- Added a constant `APPROX_DELTA` in `std/tests/floats/f32.rs` which is used for approximation tests, but with a different value when run in Miri. This is to make these tests succeed.
- Added tests in the float tests of Miri to test the C23 behaviour.
Fixes https://github.com/rust-lang/miri/issues/4208
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
const-eval error: always say in which item the error occurred
I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const.
r? `@oli-obk`
Simplify and optimize `VecCache`'s `SlotIndex::from_index`
Simplify and optimize `SlotIndex::from_index`
Break out bucket 0 (containing `idx < 4096`) as an early return, which
simplifies the remainder of the function, and allows optimizing the
`checked_ilog2` since it can no longer return `None`.
This reduces the runtime of `vec_cache::tests::slot_index_exhaustive`
(which calls `SlotIndex::from_index` for every `u32`, twice) from ~15.5s
to ~13.3s.
Separately, simplify the test case as well. (The old and new code passes with
the old and new test case.)
---
Noticed because `slot_index_exhaustive` stood out as taking unusually long compared to other tests, so I started investigating what it was doing.
The difference between the diagnostics is that no-such-field is for record struct construction, while private-field is for dot syntax.
I tried to unify them, but there is a bit of uniqueness in each. This is possible but maybe not worth it.
Also, fix the quickfix when there is already a visibility to the field (replace it instead of appending to it).
Don't walk into `Certainty::Yes` goals
Don't walk into `Certainty::Yes` goals in the pending obligation finding code, since they will not have been stalled on an infer var anyways
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixesrust-lang/rust#121429
compiler: Treat ForceWarning as a Warning for diagnostic level
This silences an ICE.
No idea if this is the correct solution though tbh.
Fixesrust-lang/rust#142144
compiler: Sort and doc ExternAbi variants
My personal brainworms found this ordering made the most sense while writing the CanonAbi PR. It is *an* ordering, at least, unlike the current mess. There has been no particular reason for the previous order ever since rust-lang/rust#136901, despite the comment I delete here. I just didn't change it.
Because I feel weird just fussing with variant ordering in the source definition, I also documented a bunch to the best of my ability.
Treat normalizing consts like normalizing types in deeply normalize
...so that we don't end up putting a top-level normalizes-to goal in the fulfillment context, which ICEs. This basically just models the normalize-const code off of the normalize-ty code above it, which uses an alias-relate goal instead.
Fixesrust-lang/rust#140571
r? lcnr
Make the `dangerous_implicit_autorefs` lint deny-by-default
I intended for the `dangerous_implicit_autorefs` lint to be deny-by-default, the [T-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097) even clearly mentioned deny-by-default, but somehow I and other missed that it is only warn-by-default.
I think the lint should still be deny-by-default as the implicit aliasing requirements can be quite dangerous.
In any-case, opening this PR for T-lang awareness.
`@rustbot` label +I-lang-nominated +T-lang
r? `@traviscross`
Allow `#![doc(test(attr(..)))]` everywhere
This PR adds the ability to specify [`#![doc(test(attr(..)))]`](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/the-doc-attribute.html#testattr) ~~at module level~~ everywhere in addition to allowing it at crate-root.
This is motivated by a recent PR #140323 (by ````@tgross35)```` where we have to duplicate 2 attributes to every single `f16` and `f128` doctests, by allowing `#![doc(test(attr(..)))]` at module level (and everywhere else) we can omit them entirely and just have (in both module):
```rust
#![doc(test(attr(feature(cfg_target_has_reliable_f16_f128))))]
#![doc(test(attr(expect(internal_features))))]
```
Those new attributes are appended to the one found at crate-root or at a previous module. Those "global" attributes are compatible with merged doctests (they already were before).
Given the small addition that this is, I'm proposing to insta-stabilize it, but I can feature-gate it if preferred.
Best reviewed commit by commit.
r? ````@GuillaumeGomez````
Move coroutine_by_move_body_def_id into the big check_crate body owner loop
This avoids starting a parallel loop in sequence and instead runs all the queries for a specific DefId together.
bootstrap: build std sans leaf frame pointers
Sometimes leaf frame-pointers can impact LLVM inlining choices, and that can be a real problem for things like `mul_add`.
Fast path for stalled obligations on self ty
If we see that the `self` type of a goal is an infer var, then don't try to compute the goal at all, since we know that it'll be forced ambiguous.
This is currently only implemented when there are no opaques in the environment. We could extend it to check that the self type is not related to any already defined opaques via subtyping, but I'll leave that as a follow-up.
---
Also stall coerce and subtype predicates if both of their vars are not resolved to concrete types.
---
~~Also, we don't care if the goal is higher-ranked for the sized and copy/clone fast path.~~ pulling this out into another PR.
r? lcnr
