This commit removes the obsolete printer and replaces all uses of it
with `FmtPrinter`. Of the replaced uses, all but one use was in `debug!`
logging, two cases were notable:
- `MonoItem::to_string` is used in `-Z print-mono-items` and therefore
affects the output of all codegen-units tests.
- `DefPathBasedNames` was used in `librustc_codegen_llvm/type_of.rs`
with `LLVMStructCreateNamed` and that'll now get different values, but
this should result in no functional change.
Signed-off-by: David Wood <david@davidtw.co>
StringReader is an intornal abstraction which at the moment changes a
lot, so these unit tests cause quite a bit of friction.
Moving them to rustc_lexer and more ingerated-testing style should
make them much less annoying, hopefully without decreasing their
usefulness much.
Note that coloncolon tests are removed (it's unclear what those are
testing).
\r\n tests are removed as well, as we normalize line endings even
before lexing.
Fixes#75930
This changes the tokens seen by a proc-macro. However, ising a `#[cfg]` attribute
on a generic paramter is unusual, and combining it with a proc-macro
derive is probably even more unusual. I don't expect this to cause any
breakage.
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.
`alloc::slice` uses `core::slice` functions, documentation are copied
from there and the links as well without resolution. `crate::ptr...`
cannot be resolved in `alloc::slice`, but `ptr` itself is imported in
both `alloc::slice` and `core::slice`, so we used that instead.
vars() rather than vars function
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Use [xxx()] rather than the [xxx] function
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Env text representation of function intra-doc link
Suggested by @jyn514
Link join_paths in env doc for parity
Change xxx to env::xxx for lib env doc
Add link requsted by @jyn514
Fix doc build with same link
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Fix missing intra-doc link
Fix added whitespace in doc
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Add brackets for `join_paths`
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Use unused link join_paths
Removed same link for join_paths
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Remove unsed link join_paths
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
