Just because the code says it's OK does not mean that it actually is OK.
Nodes with the same total size were not sorted, their order relied on
hashmap iteration.
rustdoc: Clean up footnote handling
Best reviewed commit by commit.
Extracts footnote handling logic into it's own file (first commit) and then makes that file slightly nicer to read/understand.
No functional changes, but lays the groundwork for making more changes to footnotes (eg #131901, #131946)
compiler: Adopt rust-analyzer impls for `LayoutCalculatorError`
We're about to massively churn the internals of `rustc_abi`. To minimize the immediate and future impact on rust-analyzer, as a subtree that depends on this crate, grow some API on `LayoutCalculatorError` that reflects their uses of it. This way we can nest the type in theirs, and they can just call functions on it without having to inspect and flatten-out its innards.
compiletest: disambiguate html-tidy from rust tidy tool
when i first saw this error message i was very confused, i thought it was talking about `src/tools/tidy`. now it should be much more clear what tool should be installed.
refactor fudge_inference, handle effect vars
this makes it easier to use fudging outside of `fudge_inference_if_ok`, which is likely necessary to handle inference variable leaks on rollback.
We now also uses exhaustive matches where possible and improve the code to handle effect vars.
r? `@compiler-errors` `@BoxyUwU`
Get rid of `OnlySelfBounds`
We turn `PredicateFilter` into a newtyped bool called `OnlySelfBounds`. There's no reason to lose the information of the `PredicateFilter`, so let's just pass it all the way through.
feat(rustdoc-json-types): introduce rustc-hash feature
This allows the public `rustdoc-types` crate to expose this feature easily and allows consumers of the crate to get the performance advantages from doing so.
The reasoning for this was discussed on [Zulip][1]
Changes:
- Make `rustc-hash` optional but default to including it
- Rename all occurrences of `FxHashMap` to `HashMap`.
- Feature gate the import and rename the imported `FxHashMap` to `HashMap`
- Introduce a type alias `FxHashMap` which resolves to the currently used `HashMap` (`rustc_hash::FxHashMap` or `std::collections::HashMap`) for use in `src/librustdoc`.
[1]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/rustc-hash.20and.20performance.20of.20rustdoc-types
**extra context from the zulip thread:**
- `@obi1kenobi` requested benchmarks of the switch to `rustc-hash`
- I benchmarked switching `rustdoc-types` to `rustc-hash` which yielded a ~300ms improvement to `cargo-semver-checks`'s index building step (this step is done twice so the improvements are ~150ms per index).
- The benchmarks were presented in Zulip and people were in favor of introducing `rustc-hash` to the public `rustdoc-types` crate.
- There were differing opinions on how to introduce the dependency:
1. "Hard" dependency: remove use of `std::collections::HashMap` in favor of `FxHashMap`.
2. "Soft" dependency: make optional and introduce a feature then enable/disable it by default (this PR).
3. ~~Make `rustdoc-types` generic and expose the `RandomState`~~ (a lot of work & complexity for little gain over a feature gate).
`@obi1kenobi` and I prefer the feature gate so that is what I am adding here.
My reasons for the preference are:
- `cargo-semver-checks` is especially perf sensitive, we don't expect people to care about ~150ms extra time when reading in a 500MB file (the size of the sample we used for benchmarking).
- Keeping `rustdoc-types` lean by having its only direct dependency be `serde` is nice for the general consumer of the crate.
- `rustc-hash` is not HashDOS resistant (but it is questionable whether `rustdoc-types` would be used on adversarial inputs).
r? `@aDotInTheVoid`
Remove unnecessary constness from `lower_generic_args_of_path`
We pass `NotConst` to all callsites of `lower_generic_args_of_path` except for `lower_poly_trait_ref`, so let's not do that.
replace STATX_ALL with (STATX_BASIC_STATS | STATX_BTIME) as former is deprecated
STATX_ALL was deprecated in 581701b7ef and suggested to use equivalent (STATX_BASIC_STATS | STATX_BTIME) combination, to prevent future surprises.
Stop inverting expectation in normalization errors
We have some funky special case logic to invert the expectation and actual type for normalization errors depending on their cause code. IMO most of the error messages get better, except for `try {}` blocks' type expectations. I think that these need to be special cased in some other way, rather than via this hack.
Fixes#131763
Make sure that outer opaques capture inner opaques's lifetimes even with precise capturing syntax
When lowering an opaque, we must capture and duplicate all of the lifetimes in the opaque's bounds to correctly lower the opaque's bounds. We do this *even if* the lifetime is not captured according to the `+ use<>` precise capturing bound; in that case, we will later reject that captured lifetime. For example, Given an opaque like `impl Sized + 'a + use<>`, we will still duplicate `'a` but later error that it is not mentioned in the `use<>` bound.
The current heuristic was not properly handling cases like:
```
//@ edition: 2024
fn foo<'a>() -> impl Trait<Assoc = impl Trait2> + use<> {}
```
Which forces the outer `impl Trait` to capture `'a` since `impl Trait2` *implicitly* captures `'a` due to the new lifetime capture rules for edition 2024. We were only capturing lifetimes syntactically mentioned in the bounds. (Note that this still is an error; we just need to capture `'a` so it is handled later in the compiler correctly -- hence the ICE in #131769 where a late-bound lifetime was being referenced outside of its binder).
This PR reworks the way we collect lifetimes to capture and duplicate in AST lowering to fix this.
Fixes#131769
warn less about non-exhaustive in ffi
Bindgen allows generating `#[non_exhaustive] #[repr(u32)]` enums. This results in nonintuitive nonlocal `improper_ctypes` warnings, even when the types are otherwise perfectly valid in C.
Adjust for actual tooling expectations by avoiding warning on simple enums with only unit variants.
Closes https://github.com/rust-lang/rust/issues/116831
Migrate `llvm::set_comdat` and `llvm::SetUniqueComdat` to LLVM-C FFI.
Note, now we can call `llvm::set_comdat` only when the target actually
supports adding comdat. As this has no convenient LLVM-C API, we
implement this as `TargetOptions::supports_comdat`.
Co-authored-by: Stuart Cook <Zalathar@users.noreply.github.com>
This allows the public `rustdoc-types` crate to expose this feature
easily and allows consumers of the crate to get the performance
advantages from doing so.
The reasoning for this was discussed on [Zulip][1]
Changes:
- Make `rustc-hash` optional but default to including it
- Rename all occurrences of `FxHashMap` to `HashMap`.
- Feature gate the import and rename the imported `FxHashMap` to
`HashMap`
- Introduce a type alias `FxHashMap` which resolves to the currently
used `HashMap` (`rustc_hash::FxHashMap` or
`std::collections::HashMap`) for use in `src/librustdoc`.
[1]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/rustc-hash.20and.20performance.20of.20rustdoc-types
zero-sized accesses are fine on null pointers
We entirely forgot to update all the function docs when changing the central docs. That's the problem with helpfully repeating shared definitions in tons of places...
small interpreter error cleanup
- Add `InterpretResult::map_err_kind` for the common case of swapping out the error kind (while preserving the backtrace pointing to the original error source)
- Rename `InterpError` -> `InterpErrorKind` to be consistent with the `kind` field name, and make it more clear that this is not the final error type
rustdoc: Switch from FxHash to sha256 for static file hashing.
Fixes https://github.com/rust-lang/rust/pull/129533#issuecomment-2422891519
fxhash isn't well defined, and it's implementation is being changed in #129533. But because rustdoc uses it for static files (and encodes that hashing in rustdoc.css), this broke our tests. Given that this isn't performace critical, I think the right fix is to used a well-defined hash that will never change its definition. I've picked (rather arbitrarily) sha256.
Update `use` keyword docs to describe precise capturing
I noticed that the standard library keyword docs for the `use` keyword haven't been updated yet to describe the new precise capturing syntax.
