Move methods from `Map` to `TyCtxt`, part 2.
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already have a `par_` or `try_par_` prefix I added the `hir_` after that.
r? Zalathar
Continuing the work started in #136466.
Every method gains a `hir_` prefix, though for the ones that already
have a `par_` or `try_par_` prefix I added the `hir_` after that.
Allow configuring jemalloc per target
In Ferrocene we're trying to switch from `./configure` to a predefined `config.toml` file. One of the limitations of doing that is the `rust.jemalloc` configuration option, which we need to conditionally disable based on the target. This PR adds a `target.$tuple.jemalloc` option to override `rust.jemalloc` to make that possible.
CI: rfl: move job forward to Linux v6.14-rc3
Linux v6.14-rc3 contains commit 6273a058383e ("x86: rust: set rustc-abi=x86-softfloat on rustc>=1.86.0"), which resolves the error from https://github.com/rust-lang/rust/pull/136146.
r? `@lqd` `@Kobzol`
try-job: x86_64-rust-for-linux
`@rustbot` label A-rust-for-linux
`@bors` try
boostrap: skip no_std targets in Std doc step
This fixes a bug that currently prevents us from adding no_std library targets to rustc in nixpkgs (https://github.com/NixOS/nixpkgs/pull/382166).
When running `./x.py doc`, the `Std` doc step generally fails for no_std targets, logs: https://gist.github.com/niklaskorz/fb83f9503ce19b75e8b1af02cdebd592
Skipping no_std targets in this step will allow using no_std targets such as `bpfel-unknown-none` together with other targets in the same config without blocking the doc generator for them, e.g.
```
./configure --release-channel=stable --tools=rustc,rustdoc,rust-analyzer-proc-macro-srv --build=aarch64-apple-darwin --host=aarch64-apple-darwin --target=aarch64-apple-darwin,bpfel-unknown-none
./x.py doc
```
Logs with this fix applied: https://gist.github.com/niklaskorz/cdd50aaea33ede579f737434286d800b
Pass vendored sources from bootstrap to generate-copyright
In addition to doing the vendoring in bootstrap, this PR also loads the list of manifests to parse from bootstrap (instead of hardcoding a smaller list in generate-copyright). This is best reviewed commit-by-commit.
Fixes https://github.com/rust-lang/rust/issues/136955
Rollup of 7 pull requests
Successful merges:
- #137095 (Replace some u64 hashes with Hash64)
- #137100 (HIR analysis: Remove unnecessary abstraction over list of clauses)
- #137105 (Restrict DerefPure for Cow<T> impl to T = impl Clone, [impl Clone], str.)
- #137120 (Enable `relative-path-include-bytes-132203` rustdoc-ui test on Windows)
- #137125 (Re-add missing empty lines in the releases notes)
- #137145 (use add-core-stubs / minicore for a few more tests)
- #137149 (Remove SSE ABI from i586-pc-windows-msvc)
r? `@ghost`
`@rustbot` modify labels: rollup
I was wrong on #19127, I thought hir-def resolver is enough for them, but it turns out not because of paths like `<Enum>::Variant` and `Type::AssocThatIsEnum::Variant`.
Linux v6.14-rc3 contains commit 6273a058383e ("x86: rust: set
rustc-abi=x86-softfloat on rustc>=1.86.0"), which resolves the error
from https://github.com/rust-lang/rust/pull/136146.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Replace some u64 hashes with Hash64
I introduced the Hash64 and Hash128 types in https://github.com/rust-lang/rust/pull/110083, essentially as a mechanism to prevent hashes from landing in our leb128 encoding paths. If you just have a u64 or u128 field in a struct then derive Encodable/Decodable, that number gets leb128 encoding. So if you need to store a hash or some other value which behaves very close to a hash, don't store it as a u64.
This reverts part of https://github.com/rust-lang/rust/pull/117603, which turned an encoded Hash64 into a u64.
Based on https://github.com/rust-lang/rust/pull/110083, I don't expect this to be perf-sensitive on its own, though I expect that it may help stabilize some of the small rmeta size fluctuations we currently see in perf reports.
Overhaul `rustc_middle::limits`
In particular, to make `pattern_complexity` work more like other limits, which then enables some other simplifications.
r? ``@Nadrieril``
Start removing `rustc_middle::hir::map::Map`
`rustc_middle::hir::map::Map` is now just a low-value wrapper around `TyCtxt`. This PR starts removing it.
r? `@cjgillot`
First of all, note that `Map` has three different relevant meanings.
- The `intravisit::Map` trait.
- The `map::Map` struct.
- The `NestedFilter::Map` associated type.
The `intravisit::Map` trait is impl'd twice.
- For `!`, where the methods are all unreachable.
- For `map::Map`, which gets HIR stuff from the `TyCtxt`.
As part of getting rid of `map::Map`, this commit changes `impl
intravisit::Map for map::Map` to `impl intravisit::Map for TyCtxt`. It's
fairly straightforward except various things are renamed, because the
existing names would no longer have made sense.
- `trait intravisit::Map` becomes `trait intravisit::HirTyCtxt`, so named
because it gets some HIR stuff from a `TyCtxt`.
- `NestedFilter::Map` assoc type becomes `NestedFilter::MaybeTyCtxt`,
because it's always `!` or `TyCtxt`.
- `Visitor::nested_visit_map` becomes `Visitor::maybe_tcx`.
I deliberately made the new trait and associated type names different to
avoid the old `type Map: Map` situation, which I found confusing. We now
have `type MaybeTyCtxt: HirTyCtxt`.
The end goal is to eliminate `Map` altogether.
I added a `hir_` prefix to all of them, that seemed simplest. The
exceptions are `module_items` which became `hir_module_free_items` because
there was already a `hir_module_items`, and `items` which became
`hir_free_items` for consistency with `hir_module_free_items`.
There were two mistakes: first, tests were sorted before test modules, and second, we re-sorted based on the name only, which cancelled the sort based on the kind.
It's similar to the other limits, e.g. obtained via `get_limit`. So it
makes sense to handle it consistently with the other limits. We now use
`Limit`/`usize` in most places instead of `Option<usize>`, so we use
`Limit::new(usize::MAX)`/`usize::MAX` to emulate how `None` used to work.
The commit also adds `Limit::unlimited`.
Rollup of 8 pull requests
Successful merges:
- #136986 (Apply unsafe_op_in_unsafe_fn to the standard library)
- #137012 (add docs and ut for bootstrap util cc-detect)
- #137072 (Load all builtin targets at once instead of one by one in check-cfg)
- #137102 (Rework `name_regions` to not rely on reverse scc graph for non-member-constrain usages)
- #137112 (Don't project into `NonNull` when dropping a `Box`)
- #137114 (Add an example for `std::error::Error`)
- #137117 (Fix test that relies on error language)
- #137119 (fix broken `x {doc, build} core`)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix musl's CVE-2025-26519
The musl project [announced CVE-2025-26519](https://www.openwall.com/lists/musl/2025/02/13/1), which could result in out-of-bounds writes when calling the `iconv` function. There is no musl release available with the fixes at this point in time (and we're using an older version of musl anyway), so this PR applies the provided patches on top of the musl source tarball we download.
And add a new diagnostic for non-`Fn` parenthesized generic args.
Path lowering started to look like a mess, with each function carrying additional parameters for the diagnostic callback (since paths can occur both in type and in expression/pattern position, and their diagnostic handling is different) and the segment index, for the diagnostics report. So I refactored it from stateless functions on `TyLoweringContext` into stateful struct, `PathLoweringContext`, that tracks the process of lowering a path from resolution til assoc types selection.
Apply unsafe_op_in_unsafe_fn to the standard library
This applies unsafe_op_in_unsafe_fn to the standard library in preparation for updating to Rust 2024.
Closes https://github.com/rust-lang/rust/issues/127747 (I think?) cc ``@workingjubilee``
I have been testing a variety of targets, and I feel like they are all pretty much covered. I'll continue doing some testing async, but I don't expect to catch any more.