rustdoc: DocFS: Replace rayon with threadpool and enable it for all targets
Fixes https://github.com/rust-lang/rust/issues/109060.
Switching to `threadpool` makes it a bit simpler for us to wait for all tasks in `DocFS` directly in the `Drop` implementation. I'm also curious if making all the writes into a thread pool could improve run time for rustdoc on all other platforms than Windows as well.
I'll run a perf check to see.
cc ```@ehuss```
r? ```@notriddle```
Update cargo
14 commits in 7d3033d2e59383fd76193daf9423c3d141972a7d..4a3c588b1f0a8e2dc8dd8789dbf3b6a71b02ed49
2023-03-08 17:05:08 +0000 to 2023-03-14 14:05:36 +0000
- ci: make clean-test-output a script for reuse (rust-lang/cargo#11848)
- Accurately show status when downgrading dependencies (rust-lang/cargo#11839)
- docs(contrib): Move Design Principles earlier in the book (rust-lang/cargo#11842)
- docs(contrib): Point compilation docs to doc comments (rust-lang/cargo#11841)
- `cargo install --git` multiple packages with binaries found hint (rust-lang/cargo#11835)
- Disable flaky auth tests when `gitoxide` runs them (rust-lang/cargo#11830)
- Add some documentation on writing cross-compilation tests (rust-lang/cargo#11825)
- chore: Use sparse protocol on stable CI (rust-lang/cargo#11829)
- Notice for potential unexpected shell expansions in help text of `cargo-add` (rust-lang/cargo#11826)
- Add tracking issue to gitoxide unstable docs (rust-lang/cargo#11822)
- Bump crates-io to 0.36.0 (rust-lang/cargo#11820)
- Bump to 0.71.0; update changelog (rust-lang/cargo#11815)
- docs(contrib): Move overview to lib (rust-lang/cargo#11809)
- Fix semver check for 1.68 (rust-lang/cargo#11817)
r? `@ghost`
14 commits in 7d3033d2e59383fd76193daf9423c3d141972a7d..4a3c588b1f0a8e2dc8dd8789dbf3b6a71b02ed49
2023-03-08 17:05:08 +0000 to 2023-03-14 14:05:36 +0000
- ci: make clean-test-output a script for reuse (rust-lang/cargo#11848)
- Accurately show status when downgrading dependencies (rust-lang/cargo#11839)
- docs(contrib): Move Design Principles earlier in the book (rust-lang/cargo#11842)
- docs(contrib): Point compilation docs to doc comments (rust-lang/cargo#11841)
- `cargo install --git` multiple packages with binaries found hint (rust-lang/cargo#11835)
- Disable flaky auth tests when `gitoxide` runs them (rust-lang/cargo#11830)
- Add some documentation on writing cross-compilation tests (rust-lang/cargo#11825)
- chore: Use sparse protocol on stable CI (rust-lang/cargo#11829)
- Notice for potential unexpected shell expansions in help text of `cargo-add` (rust-lang/cargo#11826)
- Add tracking issue to gitoxide unstable docs (rust-lang/cargo#11822)
- Bump crates-io to 0.36.0 (rust-lang/cargo#11820)
- Bump to 0.71.0; update changelog (rust-lang/cargo#11815)
- docs(contrib): Move overview to lib (rust-lang/cargo#11809)
- Fix semver check for 1.68 (rust-lang/cargo#11817)
StableMIR: Proof-of-concept implementation + test
This PR is part of the [project Stable MIR](https://github.com/rust-lang/project-stable-mir). The PR deletes old re-exports from rustc_smir and introduces a proof-of-concept implementation for APIs to retrieve crate information.
The implementation follows the [design described here](https://hackmd.io/XhnYHKKuR6-LChhobvlT-g?view), but instead of using separate crates for the implementation, it uses separate modules inside `rustc_smir`.
The API introduced at this point should be seen just as an example on how we are planning to structure the communication between tools and the compiler.
I have not explored yet what should be the right granularity, the best starting point for users, neither the best way to implement it.
r? ``````@oli-obk``````
rustdoc-json: switch from HashMap to FxHashMap to fix non-determinism
Using `HashMap` in `rustdoc_json_types::Crate` were causing creating randomly ordered objects in the json doc files. Which might cause problems to people who are doing comparison on those files specially in CI pipelines. See https://github.com/rust-lang/rust/issues/103785#issuecomment-1307425590
This PR fixes that issue and extends the coverage of `tests/run-make/rustdoc-verify-output-files` testing ability.
Add support for QNX Neutrino to standard library
This change:
- adds standard library support for QNX Neutrino (7.1).
- upgrades `libc` to version `0.2.139` which supports QNX Neutrino
`@gh-tr`
⚠️ Backtraces on QNX require https://github.com/rust-lang/backtrace-rs/pull/507 which is not yet merged! (But everything else works without these changes) ⚠️
Tested mainly with a x86_64 virtual machine (see qnx-nto.md) and partially with an aarch64 hardware (some tests fail due to constrained resources).
10 commits in 9d5b32f503fc099c4064298465add14d4bce11e6..9880b408a3af50c08fab3dbf4aa2a972df71e951
2023-02-22 23:04:16 +0000 to 2023-02-28 19:39:39 +0000
- bump jobserver to respect `--jobserver-auth=fifo:PATH` (rust-lang/cargo#11767)
- Addition of support for -F as an alias for --features (rust-lang/cargo#11774)
- Added documentation for the configuration discovery of `cargo install` to the man pages (rust-lang/cargo#11763)
- Fix Cargo removing the sparse+ prefix from sparse URLs in .crates.toml (rust-lang/cargo#11756)
- Fix warning with tempfile (rust-lang/cargo#11771)
- Error message for transitive artifact dependencies with targets the package doesn't directly interact with (rust-lang/cargo#11643)
- Fix tests with nondeterministic ordering (rust-lang/cargo#11766)
- Make some blocking tests non-blocking (rust-lang/cargo#11650)
- Suggest cargo add when installing library crate (rust-lang/cargo#11410)
- chore: bump is-terminal to 0.4.4 (rust-lang/cargo#11759)
Upgrade to ena-0.14.1.
It avoids some inlining within its `inlined_probe_value` function, which seems to result in better codegen for the very large `process_obligations` function within rustc. It might also help with reducing the bimodal perf results we see for the `keccak` and `cranelift-codegen-0.82.1` benchmarks.
r? `@ghost`
RustHermit publishs a new kernel interface and supports
a common BSD socket layer. By supporting this interface,
the implementation can be harmonized to other operating systems.
To realize this socket layer, the handling of file descriptors
is also harmonized to other operating systems.
errors: generate typed identifiers in each crate
Instead of loading the Fluent resources for every crate in `rustc_error_messages`, each crate generates typed identifiers for its own diagnostics and creates a static which are pulled together in the `rustc_driver` crate and provided to the diagnostic emitter.
There are advantages and disadvantages to this change..
#### Advantages
- Changing a diagnostic now only recompiles the crate for that diagnostic and those crates that depend on it, rather than `rustc_error_messages` and all crates thereafter.
- This approach can be used to support first-party crates that want to supply translatable diagnostics (e.g. `rust-lang/thorin` in https://github.com/rust-lang/rust/pull/102612#discussion_r985372582, cc `@JhonnyBillM)`
- We can extend this a little so that tools built using rustc internals (like clippy or rustdoc) can add their own diagnostic resources (much more easily than those resources needing to be available to `rustc_error_messages`)
#### Disadvantages
- Crates can only refer to the diagnostic messages defined in the current crate (or those from dependencies), rather than all diagnostic messages.
- `rustc_driver` (or some other crate we create for this purpose) has to directly depend on *everything* that has error messages.
- It already transitively depended on all these crates.
#### Pending work
- [x] I don't know how to make `rustc_codegen_gcc`'s translated diagnostics work with this approach - because `rustc_driver` can't depend on that crate and so can't get its resources to provide to the diagnostic emission. I don't really know how the alternative codegen backends are actually wired up to the compiler at all.
- [x] Update `triagebot.toml` to track the moved FTL files.
r? `@compiler-errors`
cc #100717
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.
Signed-off-by: David Wood <david.wood@huawei.com>
Use a lock-free datastructure for source_span
follow up to the perf regression in https://github.com/rust-lang/rust/pull/105462
The main regression is likely the CStore, but let's evaluate the perf impact of this on its own
Most tests involving save-analysis were removed, but I kept a few where
the `-Zsave-analysis` was an add-on to the main thing being tested,
rather than the main thing being tested.
For `x.py install`, the `rust-analysis` target has been removed.
For `x.py dist`, the `rust-analysis` target has been kept in a
degenerate form: it just produces a single file `reduced.json`
indicating that save-analysis has been removed. This is necessary for
rustup to keep working.
Closes#43606.
Update the minimum external LLVM to 14
With this change, we'll have stable support for LLVM 14 through 16 (pending release).
For reference, the previous increase to LLVM 13 was #100460.
Resolve documentation links in rustc and store the results in metadata
This PR implements MCP https://github.com/rust-lang/compiler-team/issues/584.
Doc links are now resolved in rustc and stored into metadata, so rustdoc simply retrieves them through a query (local or extern),
Code that is no longer used is removed, and some code that no longer needs to be public is privatized.
The removed code includes resolver cloning, so this PR fixes https://github.com/rust-lang/rust/issues/83761.
