I've tried a few ways of implementing this, but each fell short.
Adding an auxiliary `_Idx` associated type to `Analysis` that defaults
to `!` but is overridden in the blanket impl of `Analysis` for `A:
GenKillAnalysis` to `A::Idx` seems promising, but the trait solver is
unable to prove equivalence between `A::Idx` and `A::_Idx` within the
overridden version of `into_engine`. Without full-featured
specialization, removing `into_engine` or splitting it into a different
trait would have a significant ergonomic penalty.
Alternatively, we could erase the index type and store a
`GenKillSet<u32>` as well as a function pointer for transmuting between
`&mut A::Domain` and `&mut BitSet<u32>` in the hopes that LLVM can
devirtualize a simple function pointer better than the boxed closure.
However, this is brittle, requires `unsafe` code, and doesn't work for
index types that aren't the same size as a `u32` (e.g. `usize`) since
`GenKillSet` stores a `HybridBitSet`, which may be a `Vec<I>`. Perhaps
safe transmute could help here?
A few small cleanups to `BitSet` and friends:
- Overload `clone_from` for `BitSet`.
- Improve `Debug` represenation of `HybridBitSet`.
- Make `HybridBitSet::domain_size` public.
- Don't require `T: Idx` at the type level. The `Idx` bound is still on
most `BitSet` methods, but like `HashMap`, it doesn't need to be
satisfied for the type to exist.
Move almost all compiler crates to compiler/
This PR implements https://github.com/rust-lang/compiler-team/issues/336 and moves all `rustc_*` crates from `src` to the new `compiler` directory.
`librustc_foo` directories are renamed to `rustc_foo`.
`src` directories are introduced inside `rustc_*` directories to mirror the scheme already use for `library` crates.
Fix intra-doc links for cross-crate re-exports of default trait methods
The original fix for this was very simple: https://github.com/rust-lang/rust/pull/58972 ignored `extern_traits` because before https://github.com/rust-lang/rust/issues/65983 was fixed, they would always fail to resolve, giving spurious warnings. So the first commit just undoes that change, so extern traits are now seen by the `collect_intra_doc_links` pass. There are also some minor changes in `librustdoc/fold.rs` to avoid borrowing the `extern_traits` RefCell more than once at a time.
However, that brought up a much more thorny problem. `rustc_resolve` started giving 'error: cannot find a built-in macro with name `cfg`' when documenting `libproc_macro` (I still haven't been able to reproduce on anything smaller than the full standard library). The chain of events looked like this (thanks @eddyb for the help debugging!):
0. `x.py build --stage 1` builds the standard library and creates a sysroot
1. `cargo doc` does something like `cargo check` to create `rmeta`s for all the crates (unrelated to what was built above)
2. the `cargo check`-like `libcore-*.rmeta` is loaded as a transitive dependency *and claims ownership* of builtin macros
3. `rustdoc` later tries to resolve some path in a doc link
4. suggestion logic fires and loads "extern prelude" crates by name
5. the sysroot `libcore-*.rlib` is loaded and *fails to claim ownership* of builtin macros
`rustc_resolve` gives the error after step 5. However, `rustdoc` doesn't need suggestions at all - `resolve_str_path_error` completely discards the `ResolutionError`! The fix implemented in this PR is to skip the suggestion logic for `resolve_ast_path`: pass `record_used: false` and skip `lookup_import_candidates` when `record_used` isn't set.
It's possible that if/when https://github.com/rust-lang/rust/issues/74207 is implemented this will need a more in-depth fix which returns a `ResolutionError` from `compile_macro`, to allow rustdoc to reuse the suggestions from rustc_resolve. However, that's a much larger change and there's no need for it yet, so I haven't implemented it here.
Fixes https://github.com/rust-lang/rust/issues/73829.
r? @GuillaumeGomez
This avoids a rare rustdoc bug where loading `core` twice caused a
'cannot find a built-in macro' error:
1. `x.py build --stage 1` builds the standard library and creates a sysroot
2. `cargo doc` does something like `cargo check` to create `rmeta`s for all the crates (unrelated to what was built above)
3. the `cargo check`-like `libcore-*.rmeta` is loaded as a transitive dependency *and claims ownership* of builtin macros
4. `rustdoc` later tries to resolve some path in a doc link
5. suggestion logic fires and loads "extern prelude" crates by name
6. the sysroot `libcore-*.rlib` is loaded and *fails to claim ownership* of builtin macros
This fixes step 5. by not running suggestion logic if this is a
speculative resolution. Additionally, it marks `resolve_ast_path` as a
speculative resolution.
Fix intra-doc links for associated constants
Previously, only associated functions would be resolved. Fixes the issues in https://github.com/rust-lang/rust/pull/75969#discussion_r477898003.
I'm a little uncomfortable hard-coding the string constants, but it looks like that's how it's done elsewhere. I might make a follow-up PR at some point putting it in one place.
Not sure how to test associated types, since AFAIK there aren't any on primitives.
r? @Manishearth
Rollup of 14 pull requests
Successful merges:
- #75832 (Move to intra-doc links for wasi/ext/fs.rs, os_str_bytes.rs…)
- #75852 (Switch to intra-doc links in `core::hash`)
- #75874 (Shorten liballoc doc intra link while readable)
- #75881 (Expand rustdoc theme chooser x padding)
- #75885 (Fix another clashing_extern_declarations false positive.)
- #75892 (Fix typo in TLS Model in Unstable Book)
- #75910 (Add test for issue #27130)
- #75917 (Move to intra doc links for core::ptr::non_null)
- #75975 (Allow --bess ing expect-tests in tools)
- #75990 (Add __fastfail for Windows on arm/aarch64)
- #76015 (Fix loading pretty-printers in rust-lldb script)
- #76022 (Clean up rustdoc front-end source code)
- #76029 (Move to intra-doc links for library/core/src/sync/atomic.rs)
- #76057 (Move retokenize hack to save_analysis)
Failed merges:
r? @ghost
Move to intra-doc links for library/core/src/sync/atomic.rs
Helps with #75080.
@rustbot modify labels: T-doc, A-intra-doc-links, T-rustdoc
Known issues:
* Link from core to std:
[`Arc`]
[`std:🧵:yield_now`]
[`std:🧵:sleep`]
[`std::sync::Mutex`]
Allow --bess ing expect-tests in tools
I haven't tried this, but I think this should do the trick, as `RustdocCrate` is a special step in bootstrap, which uses `tool_caro`
r? @ghost
Add test for issue #27130#27130 seems to be fixed by the llvm 11 update. The issue is marked with needs-test, so here it is. As some historical context, the generated code was fine until 1.38, and remained unoptimized from 1.38 up until the current nightly.
I've also added a pattern matching version that was fine on 1.45.2.
Fix another clashing_extern_declarations false positive.
Fixes#75739.
Fix another clashing_extern_declarations false positive, this time for transparent newtype with a non-zero member.
r? @lcnr
Shorten liballoc doc intra link while readable
r? @jyn514
Do you want to reviews these sort of pull requests in the future? I might send a few of them while reading vec code.
#58972 ignored extern_traits because before #65983 was fixed, they
would always fail to resolve, giving spurious warnings.
This undoes that change, so extern traits are now seen by the
`collect_intra_doc_links` pass. There are also some minor changes in
librustdoc/fold.rs to avoid borrowing the extern_traits RefCell more
than once at a time.
New pass to optimize `if`conditions on integrals to switches on the integer
Fixes#75144
Pass to convert `if` conditions on integrals into switches on the integral.
For an example, it turns something like
```
_3 = Eq(move _4, const 43i32);
StorageDead(_4);
switchInt(_3) -> [false: bb2, otherwise: bb3];
```
into:
```
switchInt(_4) -> [43i32: bb3, otherwise: bb2];
```
Should not apply field accessing on enum
Closes#75977
But I'm surprised that `x.py test --stage 1` and CI didn't catch this with existing testcase.
r? @estebank
Unify error reporting for intra-doc links
- Give a suggestion even if there is no span available
- Give a more accurate description of the change than 'use the
disambiguator'
- Write much less code
Closes#75836.
r? @euclio
cc @pickfire - this gets rid of 'disambiguator' like you suggested in https://github.com/rust-lang/rust/pull/75079#discussion_r464464195.
Set ninja=true by default
Ninja substantially improves LLVM build time. On a 96-way system, using
Make took 248s, and using Ninja took 161s, a 35% improvement.
We already require a variety of tools to build Rust. If someone wants to
build without Ninja (for instance, to minimize the set of packages
required to bootstrap a new target), they can easily set `ninja=false`
in `config.toml`. Our defaults should help people build Rust (and LLVM)
faster, to speed up development.
