rustdoc: remove the `!` from macro URLs and titles
Because the `!` is part of a macro use, not the macro's name. E.g., you write `macro_rules! foo` not `macro_rules! foo!`, also `#[macro_import(foo)]`.
(Pulled out of #35020).
rustdoc: Fix a couple of issues with the search results
* Fix links to static items in the search results.
* Don't include the path for primitive methods in the search results. Displaying `std::u32::max_value` is misleading so just display `u32::max_value`.
Added empty CloseDelim to tokens for future use.
Description says it all. I added a new DelimToken type, Empty, to indicate a Delimited tokenstream with no actual delimiters (which are variously useful for constructing macro output).
r? @nrc
Currently methods from extern crates are sometimes added to the search
index when they shouldn't be or added with the original path rather than
the reexported path. This fixes that by making sure `cache().paths` only
contains local paths like the description for it states. It also fixes a
few minor issues with link rendering and redirect generation which would
point to local crate docs even if the docs for that crate hadn't been
generated.
Also a bug with methods implemented on traits which caused wrong paths and
so dead links in the search results has been fixed.
rustdoc: Remove paths from primitive page <title> tags
Currently primitive pages have a title like "std::u8 - Rust" this changes
it to "u8 - Rust" as "std::u8" is the name of a module not a primitive
type.
This is a spiritual succesor to #34268/8531d581, in which we replaced a
number of matches of None to the unit value with `if let` conditionals
where it was judged that this made for clearer/simpler code (as would be
recommended by Manishearth/rust-clippy's `single_match` lint). The same
rationale applies to matches of None to the empty block.
rustdoc: Remove Derived Implementations title
As far as I know whether a trait was derived or not does not change the
public API so there is no need to include this information in the docs.
This title currently just adds an extra divide in the list of trait
implementations which I don't think needs to be there.
Batch up libsyntax breaking changes
Batch of the following syntax-[breaking-change] changes:
- #34213: Add a variant `Macro` to `TraitItemKind`
- #34368: Merge the variant `QPath` of `PatKind` into the variant `PatKind::Path`
- #34385: Move `syntax::ast::TokenTree` into a new module `syntax::tokenstream`
- #33943:
- Remove the type parameter from `visit::Visitor`
- Remove `attr::WithAttrs` -- use `attr::HasAttrs` instead.
- Change `fold_tt`/`fold_tts` to take token trees by value and avoid wrapping token trees in `Rc`.
- Remove the field `ctxt` of `ast::Mac_`
- Remove inherent method `attrs()` of types -- use the method `attrs` of `HasAttrs` instead.
- #34316:
- Remove `ast::Decl`/`ast::DeclKind` and add variants `Local` and `Item` to `StmtKind`.
- Move the node id for statements from the `StmtKind` variants to a field of `Stmt` (making `Stmt` a struct instead of an alias for `Spanned<StmtKind>`)
- Rename `ast::ExprKind::Again` to `Continue`.
- #34339: Generalize and abstract `ThinAttributes` to `ThinVec<Attribute>`
- Use `.into()` in convert between `Vec<Attribute>` and `ThinVec<Attribute>`
- Use autoderef instead of `.as_attr_slice()`
- #34436: Remove the optional expression from `ast::Block` and instead use a `StmtKind::Expr` at the end of the statement list.
- #34403: Move errors into a separate crate (unlikely to cause breakage)
This PR refactors the 'errors' part of libsyntax into its own crate (librustc_errors). This is the first part of a few refactorings to simplify error reporting and potentially support more output formats (like a standardized JSON output and possibly an --explain mode that can work with the user's code), though this PR stands on its own and doesn't assume further changes.
As part of separating out the errors crate, I have also refactored the code position portion of codemap into its own crate (libsyntax_pos). While it's helpful to have the common code positions in a separate crate for the new errors crate, this may also enable further simplifications in the future.
rustdoc: Fix a couple of issues with src links to external crates
- src links/redirects to extern fn from another crate had an extra '/'.
- src links to `pub use` of a crate module had an extra '/'.
- src links to renamed reexports from another crate used the new name
for the link but should use the original name.
Fixes: #34274
Implementation of #34168
r? @brson
cc @alexcrichton
cc @steveklabnik
cc @jonathandturner
I only updated `librustc_privacy/diagnostics.rs`, and I already found a case where the code doesn't throw the expected error code (E0448).
Fixes#34168.
- src links/redirects to extern fn from another crate had an extra '/'.
- src links to `pub use` of a crate module had an extra '/'.
- src links to renamed reexports from another crate used the new name
for the link but should use the original name.
When items are inlined from extern crates, the filename in the debug info
is taken from the FileMap that's serialized in the rlib metadata.
Currently this is just FileMap.name, which is whatever path is passed to rustc.
Since libcore and libstd are built by invoking rustc with relative paths,
they wind up with relative paths in the rlib, and when linked into a binary
the debug info uses relative paths for the names, but since the compilation
directory for the final binary, tools trying to read source filenames
will wind up with bad paths. We noticed this in Firefox with source
filenames from libcore/libstd having bad paths.
This change stores an absolute path in FileMap.abs_path, and uses that
if available for writing debug info. This is not going to magically make
debuggers able to find the source, but it will at least provide sensible
paths.
