Remove windows-sys from the library workspace
Windows-sys isn't actually used as dlmalloc doesn't use it on any of the targets where std uses dlmalloc, but still ends up in the lockfile and thus gets vendored. By using a patch to replace it with an empty crate the vendor size of the standard library is reduced from 93MB to 20MB.
Update `browser-ui-test` version to `0.23.5`
This new version adds a small delay on page loads (with a timeout of 500ms) to give more time for some checks to work as expected.
r? ghost
tests: mark import UI tests as check-pass
These import and extern-prelude UI tests only exercise checking behavior, so they do not need codegen or linking.
Mark them as check-pass and remove the old FIXME(62277) markers.
Remove most uses of def_id_to_node_id
Especially those happening during normal resolving, where we are actually looking at current parent scopes. It allows follow-up refactorings to not have a way to go from `NodeId` to `DefId` until macro expansion is done
r? @petrochenkov
Add a `doc_cfg` regression test to ensure foreign types impls are working as expected
Fixes https://github.com/rust-lang/rust/issues/150268.
This is the last case mentioned in the issue that wasn't tested. With this, the issue can be closed.
r? @Urgau
Relax `T: Sized` bound on `try_as_dyn` / `try_as_dyn_mut`
`trait_info_of` already returns `None` for unsized types, so allowing `T: ?Sized` is sound and lets callers in generic contexts use these functions without a separate `Sized` bound. For unsized `T`, the function always returns `None`.
Tracking issue: rust-lang/rust#144361
## Motivation
Currently, it is not possible to use `try_as_dyn` as "specialization-like" dispatch in
blanket impls with `?Sized` type.
```rust
// Cannot add ?Sized now.
impl<T: 'static /* + ?Sized */, S: Serializer + 'static> Serialize<S> for T {
fn serialize(&self, serializer: &mut S) -> Result<S::Ok, S::Error> {
if let Some(spec) = try_as_dyn::<_, dyn SpecializedSer<S>>(self) {
spec.specialized_serialize(serializer)
} else {
// fall back to compile-time reflection via TypeId
...
}
}
}
```
Fix E0040 suggestion for explicit `Drop::drop` UFCS calls
`Drop::drop(&mut f)` now correctly suggests `drop(f)` instead of the bare `drop` with no argument.
Fix: rust-lang/rust#156017
Clean up `TyCtxt::needs_crate_hash` usage and rename it to `needs_hir_hash`.
While reviewing `crate_hash` query usage for https://github.com/rust-lang/rust/pull/155871, the `needs_crate_hash` function turned out to be the cause of unnecessary calls to the query. The `needs_crate_hash` name is easy to mistake for the functionality of "needs the crate_hash query". This PR removes the usage of `needs_crate_hash` where it was not appropriate and renames the function to `needs_hir_hash` which better reflects its functionality.
Improve `&pin` reference-pattern suggestions
This fills in the `pin_ergonomics` FIXME in `borrow_pat_suggestion` by making the diagnostic prefix account for both `Pinnedness` and `Mutability`.
Previously, the type-position suggestion path used ordinary reference spelling, which can spell `&` and `&mut` but cannot correctly spell pinned reference-pattern suggestions such as `&pin const` and `&pin mut`.
This is a diagnostic-only change. It adds focused UI coverage for both pinned const and pinned mut reference-pattern suggestions.
c-variadic: gate `va_arg` on `c_variadic_experimental_arch`
tracking issue: https://github.com/rust-lang/rust/issues/44930
Just gating `...` is insufficient because we make the types available everywhere, and you could still define and export functions that used va_arg for targets where we don't want to stably support it.
r? joshtriplett
`rustc`: `target_features`: allow for `cfg`-only stable `target_features`
This PR introduces a new stabilization level for `target_features`: `CfgOnlyStable`. The motivation is allowing the Rust compiler to expose `target_features` of targets so users can use `cfg(target_feature = "feature")` for conditional blocks depending on target features. However, `CfgOnlyStable` cannot be used for `#[target_feature(enable = "feature")]`, as this is still considered unstable. Accordingly, the compiler will still raise an error if these expressions are used on stable.
This PR relates partially to rust-lang/rust#150257. As discussed, for RISC-V targets, having the `"d"`, `"e"`, and `"f"` target features exposed will allow baremetal developers to adapt the code depending on the target's properties.
r? @RalfJung
docs(unstable-book): Document const generics features
Relevant tracking issues: rust-lang/rust#113521rust-lang/rust#132980rust-lang/rust#76560rust-lang/rust#151972
## What
Adds a high-level overview of 4 unstable features related to const generic exprs.
## Why
While trying to learn about the current state of const generic exprs, I found it a bit too hard due to lack of documentation -- had to read through a bunch of tracking issues & look for PRs/examples in the repo just to understand what the feature is about.
Moreover, given that there is a bunch of features with similarly-looking names, it was even more confusing. For that purpose, I also added cross-referencing across (directly or logically) related features.
As a result, I decided to add some more context to the unstable book, so that new readers have an easier time than I had.
## Caveats
I understand that the features are incomplete/experimental, so the docs are at risk of becoming stale, but the book entrypoint already has [a corresponding warning](https://doc.rust-lang.org/unstable-book/), so I guess it should be fine.
Also, given that I did research myself, the examples provided might be not the best to showcase the feature -- happy to provide better examples, if you have suggestions. The examples provided are what "made the feature make sense" to me as an outsider, so there is a chance that they will be good for other external readers too, though.
LLM use disclosue: an LLM was used for self-review only; research, coming up with examples, and writing is mine. Issues reported by LLM were fixed manually too.
r? @BoxyUwU
Remove unnecessary `get_unchecked`
My benchmarking did not show any issue with using the safe method instead so I assume this isn't an issue any more. But let's do a perf run to be sure.
`Drop::drop(&mut f)` now correctly suggests `drop(f)` instead of
the bare `drop` with no argument.
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
Short-circuit `calculate_fallback_to_f32` when no float vars
Sharing a small fix.
When no unresolved variable is a `float_vid`, no f32 fallback can apply,
so we can skip `from_float_for_f32_root_vids` (which walks the proof tree
of every pending obligation under the new solver — O(N × M) on crates
with many large obligations).
On ReShell: stage1 wall-clock 2m35s → 1m46s (-49s, ~31%).
Context + profile breakdown will be linked at
rust-lang/trait-system-refactor-initiative#254 after this PR opens.
r? @lcnr
refactor using ExprParenthesesNeeded where possible
Found multiple instances where the equivalent of `ExprParenthesesNeeded` was done 'manually'.
Replaced them with an `ExprParenthesesNeeded::surrounding` call.
Regression test for trait-system-refactor#7
Adds a regression test for [`AliasRelate` hides info in transitive cases](https://github.com/rust-lang/trait-system-refactor-initiative/issues/7).
The example previously errored under the new solver but compiles cleanly now thanks to eager normalization (post-rust-lang/rust#119106). Verified on both the `old` and `next` revisions.
The issue body has an older TODO suggesting a goal-proving variant test; per lcnr's recent note in `#t-types/trait-system-refactor` ("this isn't an issue as we eagerly normalize"), the underlying mechanism is now resolved across both inference and goal-proving paths, so this single regression test is sufficient. Closing the upstream issue manually after merge.
r? @lcnr
Just gating `...` is insufficient because we make the types available
everywhere, and you could still define and export functions that used
va_arg for targets where we don't want to stably support it.
std: implement `clear` via `truncate`
This gets rid of some `unsafe`. `truncate(0)` is even documented to be equivalent to `clear`, this makes that equivalence even more obvious.
Several printing functions (e.g. `short_string`) take a liftable
parameter. This commit changes the call sites to do the lifting instead.
This simplifies the type signatures and puts the `lift` calls inside
`tls::with` calls which is where they usually appear, and the minor cost
of having more `lift` call sites.
found multiple instances where the equivalent of ExprParenthesesNeeded
was done 'manually'.
replaced them with a `ExprParenthesesNeeded::surrounding` call
Jonathan Brouwer