This is a standard pattern:
```
MyAnalysis.into_engine(tcx, body).iterate_to_fixpoint()
```
`into_engine` and `iterate_to_fixpoint` are always called in pairs, but
sometimes with a builder-style `pass_name` call between them. But a
builder-style interface is overkill here. This has been bugging me a for
a while.
This commit:
- Merges `Engine::new` and `Engine::iterate_to_fixpoint`. This removes
the need for `Engine` to have fields, leaving it as a trivial type
that the next commit will remove.
- Renames `Analysis::into_engine` as `Analysis::iterate_to_fixpoint`,
gives it an extra argument for the optional pass name, and makes it
call `Engine::iterate_to_fixpoint` instead of `Engine::new`.
This turns the pattern from above into this:
```
MyAnalysis.iterate_to_fixpoint(tcx, body, None)
```
which is shorter at every call site, and there's less plumbing required
to support it.
Rollup of 7 pull requests
Successful merges:
- #130350 (stabilize Strict Provenance and Exposed Provenance APIs)
- #131737 (linkchecker: add a reminder on broken links to add new/renamed pages to `SUMMARY.md` for mdBooks)
- #131991 (test: Add test for trait in FQS cast, issue #98565)
- #131997 (Make `rustc_abi` compile on stable again)
- #131999 (Improve test coverage for `unit_bindings` lint)
- #132001 (fix coherence error for very large tuples™)
- #132003 (update ABI compatibility docs for new option-like rules)
r? `@ghost`
`@rustbot` modify labels: rollup
linkchecker: add a reminder on broken links to add new/renamed pages to `SUMMARY.md` for mdBooks
I spent an embarrassingly long amount of time trying to figure out why CI was failing for a PR adding new platform support docs. In turns out it's because the PR author didn't register the new page in `SUMMARY.md`. I completely forgot about it too, and was reading linkchecker source because I thought it was a bug in linkchecker.
So this PR adds a note to modify `SUMMARY.md` when adding new pages in a mdBook.
E.g.
```
# Adding a new `meow` target but forgor to register the page in `SUMMARY.md`
rustc\platform-support.html:183: broken link - `rustc\platform-support\meow.html`
rustc\print.html:9730: broken link - `rustc\platform-support\meow.html`
checked links in: 19.1s
number of HTML files scanned: 43588
number of HTML redirects found: 13735
number of links checked: 3145951
number of links ignored due to external: 156244
number of links ignored due to exceptions: 9
number of intra doc links ignored: 8
errors found: 2
NOTE: if you are adding or renaming a markdown file in a mdBook, don't forget to register the page in SUMMARY.md
found some broken links
```
stabilize Strict Provenance and Exposed Provenance APIs
Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs:
```rust
// core::ptr
pub const fn without_provenance<T>(addr: usize) -> *const T;
pub const fn dangling<T>() -> *const T;
pub const fn without_provenance_mut<T>(addr: usize) -> *mut T;
pub const fn dangling_mut<T>() -> *mut T;
pub fn with_exposed_provenance<T>(addr: usize) -> *const T;
pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T;
impl<T: ?Sized> *const T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> *mut T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> NonNull<T> {
pub fn addr(self) -> NonZero<usize>;
pub fn with_addr(self, addr: NonZero<usize>) -> Self;
pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self;
}
```
I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort.
There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](https://github.com/rust-lang/rust/issues/130351) feature since I didn't want this PR to have an even bigger FCP. ;)
`@rust-lang/opsem` Would be great to get some feedback on the docs here. :)
Nominating for `@rust-lang/libs-api.`
Part of https://github.com/rust-lang/rust/issues/95228.
[FCP comment](https://github.com/rust-lang/rust/pull/130350#issuecomment-2395114536)
Finish stabilization of `result_ffi_guarantees`
The internal linting has been changed, so all that is left is making sure we stabilize what we want to stabilize.
Rollup of 4 pull requests
Successful merges:
- #126588 (Added more scenarios where comma to be removed in the function arg)
- #131728 (bootstrap: extract builder cargo to its own module)
- #131968 (Rip out old effects var handling code from traits)
- #131981 (Remove the `BoundConstness::NotConst` variant)
r? `@ghost`
`@rustbot` modify labels: rollup
Rip out old effects var handling code from traits
Traits no longer have an effect parameter, so this removes logic associated with it. It also removes logic surrounding confirming `~const Destruct` bounds, which I added a looooong time ago, and which I don't feel like we need anymore -- if it needs to be added back, it should be rewritten :D
cc `@fee1-dead`
bootstrap: extract builder cargo to its own module
I was looking at our cargo rustflags/rustdocflags usages, and I found `builder.rs` to be a large
file which made it hard to digest. This PR tries to break out the cargo command wrapper parts to
its own submodule to make it easier to identify builder cargo-specific logic.
This PR:
- Extracts the cargo command wrapper to its own module and also move `Builder::{bare_,}cargo` impl
to the submodule.
- Reorganizes some imports in `lib.rs` (no functional changes).
- Slightly adjusts some docs in `builder.rs`.
This PR is basically just moving code around, and should not contain any functional changes.
Before this PR, `builder.rs` was 2743 lines. After this PR, `builder.rs` is down to a more
manageable 1386 lines and `cargo.rs` is 1085 lines.
Continue to get rid of `ty::Const::{try_}eval*`
This PR mostly does:
* Removes all of the `try_eval_*` and `eval_*` helpers from `ty::Const`, and replace their usages with `try_to_*`.
* Remove `ty::Const::eval`.
* Rename `ty::Const::normalize` to `ty::Const::normalize_internal`. This function is still used in the normalization code itself.
* Fix some weirdness around the `TransmuteFrom` goal.
I'm happy to split it out further; for example, I could probably land the first part which removes the helpers, or the changes to codegen which are more obvious than the changes to tools.
r? BoxyUwU
Part of https://github.com/rust-lang/rust/issues/130704
I found builder.rs to be a massive file which made it hard to digest. To
make `RUSTFLAGS` usage hardening easier later, I extracted the cargo
part in `builder.rs` into its own module.
ci update freebsd version proposal, freebsd 12 being eol
raising to the lowest still active supported freebsd version.
From 13.1 (already eol too), freebsd introduces a cpu affinity layer
with linux. It also introduces a api compatible copy_file_range which
can be used like its linux's counterpart.
The former is essential to build https://github.com/rust-lang/rust/pull/120589, therefore breaks the backward
compatibility with the previous FreeBSD releases.
Blocked on https://github.com/rust-lang/rust/issues/130465
feat(rustdoc-json-types): mark simple enums as copy
Fixesrust-lang/rustdoc-types#26 and some typos in the documentation
r? `@aDotInTheVoid`
I have been assigning these PRs to you `@aDotInTheVoid,` is that okay? I think I'm out of PRs for now, but for future reference c:
fix(rustdoc-json-types): document rustc-hash feature
The `rustc-hash` feature is publicly exposed by the `rustdoc-types`. It is already documented in that crate's README and Cargo.toml, but we might as well add some information to the crate docs themselves c:
Follow up to:
- #131936
- [rust-lang/rustdoc-types#42][1]
[1]: https://github.com/rust-lang/rustdoc-types/pull/42
r? `@aDotInTheVoid`
compiletest: tidy up how `tidy` and `tidy` (html version) are disambiguated
Rename `has_tidy` -> `has_html_tidy` (`tidy` is also a bootstrap tool, but rustdoc uses a html tidy that has the same binary name). Follow-up to #131941.
Also apparently `runtest.rs` is short enough now, we can delete the `tidy` (bootstrap version) ignore for file length.
Align boolean option descriptions in `configure.py`
Boolean options are currently printed as
```
Options
--enable-debug OR --disable-debug enables debugging environment; does not affect optimization of bootstrapped code
--enable-docs OR --disable-docs build standard library documentation
--enable-compiler-docs OR --disable-compiler-docs build compiler documentation
--enable-optimize-tests OR --disable-optimize-tests build tests with optimizations
--enable-verbose-tests OR --disable-verbose-tests enable verbose output when running tests
--enable-ccache OR --disable-ccache invoke gcc/clang via ccache to reuse object files between builds
--enable-sccache OR --disable-sccache invoke gcc/clang via sccache to reuse object files between builds
--enable-local-rust OR --disable-local-rust use an installed rustc rather than downloading a snapshot
--local-rust-root=VAL set prefix for local rust binary
--enable-local-rebuild OR --disable-local-rebuild assume local-rust matches the current version, for rebuilds; implies local-rust, and is implied if local-rust already matches the current version
```
as of #131117
imo, this is a little difficult to skim. This PR changes this to align the `OR`s and push the description onto a newline:
```
Options
--enable-debug OR --disable-debug
enables debugging environment; does not affect optimization of bootstrapped code
--enable-docs OR --disable-docs
build standard library documentation
--enable-compiler-docs OR --disable-compiler-docs
build compiler documentation
--enable-optimize-tests OR --disable-optimize-tests
build tests with optimizations
--enable-verbose-tests OR --disable-verbose-tests
enable verbose output when running tests
--enable-ccache OR --disable-ccache
invoke gcc/clang via ccache to reuse object files between builds
--enable-sccache OR --disable-sccache
invoke gcc/clang via sccache to reuse object files between builds
--enable-local-rust OR --disable-local-rust
use an installed rustc rather than downloading a snapshot
--local-rust-root=VAL set prefix for local rust binary
--enable-local-rebuild OR --disable-local-rebuild
assume local-rust matches the current version, for rebuilds; implies local-rust, and is implied if local-rust already matches the current version
```
Register `src/tools/unicode-table-generator` as a runnable tool
It seems like `src/tools/unicode-table-generator` is not currently managed by bootstrap. This PR wires it up with bootstrap as a runnable tool.
This tool seems to take two possible args:
1. (Mandatory) path to `library/core/src/unicode/unicode_data.rs`, and
2. (Optional) path to generate a test file.
I only passed the mandatory path to `unicode_data.rs` in bootstrap and didn't do anything about (2). I'm not sure about how this tool is supposed to be run.
`Cargo.lock` is modified because I renamed `unicode-table-generator`'s bin name to match the tool name, as bootstrap's tool running logic expects the bin name to be derived from the tool name.
I also added a triagebot message to remind to not manually edit the library source file and edit the tool then regenerate instead, but this should probably be a tidy check (if that's desirable then that can be in a follow-up PR, though may be overkill).
Helps with #131640 but does not close it because still no docs.
r? `@Mark-Simulacrum` (since I think you authored this tool?)
Fix missing rustfmt in msi installer #101993
# Context
- Fixed missing `rustfmt`, `clippy`, `miri` and `rust-analyzer` in msi installer
- Fixed missing `rustfmt` for apple darwin installer
- Closes#101993
r? `@jyn514`
- Please let me know if I should request from someone else instead. I divided the changes into 3 separate commits for the ease of review. The refactoring commit `fbdfd5c03c3c979bcf105ccdd05ff4ab9f37a763` is a bit more involved, but I think it helps in the long term for readability and to avoid bugs.
- I changed `build-manifest` to `build_manifest` in order to invoke it as a library. Not sure if this is gonna break any upstream processes. I checked `generate-manifest-list` and `generate-release` but didn't find any obvious reference
- Will push fixes for linting later
Allow `#[deny]` inside `#[forbid]` as a no-op
Forbid cannot be overriden. When someome tries to do this anyways, it results in a hard error. That makes sense.
Except it doesn't, because macros. Macros may reasonably use `#[deny]` (or `#[warn]` for an allow-by-default lint) in their expansion to assert that their expanded code follows the lint. This is doesn't work when the output gets expanded into a `forbid()` context. This is pretty silly, since both the macros and the code agree on the lint!
By making it a warning instead, we remove the problem with the macro, which is now nothing as warnings are suppressed in macro expanded code, while still telling users that something is up.
fixes#121483
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.
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`
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
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.
bootstrap: allow setting `--jobs` in config.toml
Allow setting `--jobs` in config.toml's `[build]` section.
```toml
[build]
jobs = 0
```
If this is unset or set to zero in config.toml, we look at `--jobs` flag. If that is also unset, then we fallback to `std::thread::available_parallelism`. If that is not available, then we default to `1`. The flags and `available_parallelism` fallback are already setup, this PR just adds a config.toml option to wire that up.
Closes#131836.
r? bootstrap
Nicholas Nethercote