Port `#[rustc_legacy_const_generics]` to use attribute parser
Small PR that ports the `#[rustc_legacy_const_generics]` to use the new attribute parser!
r? JonathanBrouwer
dont create unnecessary `DefId`s under mgca
Fixesrust-lang/rust#149977Fixesrust-lang/rust#148838
Accidentally left this out of rust-lang/rust#149136 even though being able to do this was a large part of the point of the PR :3
First ICE was caused by the fact that we create a defid but never lower the nodeid associated with it to a hirid which later parts of the compiler can't handle.
See test for second ICE
r? oli-obk
Externally implementable items
Supersedes https://github.com/rust-lang/rust/pull/140010
Tracking issue: https://github.com/rust-lang/rust/issues/125418
Getting started:
```rust
#![feature(eii)]
#[eii(eii1)]
pub fn decl1(x: u64)
// body optional (it's the default)
{
println!("default {x}");
}
// in another crate, maybe
#[eii1]
pub fn decl2(x: u64) {
println!("explicit {x}");
}
fn main() {
decl1(4);
}
```
- tiny perf regression, underlying issue makes multiple things in the compiler slow, not just EII, planning to solve those separately.
- No codegen_gcc support, they don't have bindings for weak symbols yet but could
- No windows support yet for weak definitions
This PR merges the implementation of EII for just llvm + not windows, doesn't yet contain like a new panic handler implementation or alloc handler. With this implementation, it would support implementing the panic handler in terms of EII already since it requires no default implementation so no weak symbols
The PR has been open in various forms for about a year now, but I feel that having some implementation merged to build upon
Overhaul filename handling for cross-compiler consistency
This PR overhauls the way we handle filenames in the compiler and `rmeta` in order to achieve achieve cross-compiler consistency (ie. having the same path no matter if the filename was created in the current compiler session or is coming from `rmeta`).
This is required as some parts of the compiler rely on consistent paths for the soundness of generated code (see rust-lang/rust#148328).
In order to achieved consistency multiple steps are being taken by this PR:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- currently `RealFileName` can be created from any `Path` and are remapped afterwards, which creates consistency issue
- by also making `RealFileName` holds it's working directory, embeddable name and the remapped scopes
- this removes the need for a `Session`, to know the current(!) scopes and cwd, which is invalid as they may not be equal to the scopes used when creating the filename
In order for `SourceMap::to_real_filename` to know which scopes to apply `FilePathMapping` now takes the current remapping scopes to apply, which makes `FileNameDisplayPreference` and company useless and are removed.
This PR is split-up in multiple commits (unfortunately not atomic), but should help review the changes.
Unblocks https://github.com/rust-lang/rust/pull/147611
Fixes https://github.com/rust-lang/rust/issues/148328
Fix: Prevent macro-expanded extern crates from shadowing extern arguments
prevents an ICE by fixing a logic bug in `build_reduced_graph.rs`.
the bug caused the compiler to correctly detect and report a shadowing error for a macro-expanded `extern crate` but then continue processing the invalid item, corrupting the resolver's internal state (`extern_prelude`) and leading to a crash in later resolution passes the fix adds an early return after the shadowing error is reported to ensure the invalid item is not added to the resolution graph.
Fixesrust-lang/rust#149821
This commit refactors `SourceMap` and most importantly `RealFileName` to
make it self-contained in order to achieve cross-compiler consistency.
This is achieved:
- by making `RealFileName` immutable
- by only having `SourceMap::to_real_filename` create `RealFileName`
- by also making `RealFileName` holds it's working directory,
it's embeddable name and the remapped scopes
- by making most `FileName` and `RealFileName` methods take a scope as
an argument
In order for `SourceMap::to_real_filename` to know which scopes to apply
`FilePathMapping` now takes the current remapping scopes to apply, which
makes `FileNameDisplayPreference` and company useless and are removed.
The scopes type `RemapPathScopeComponents` was moved from
`rustc_session::config` to `rustc_span`.
The previous system for scoping the local/remapped filenames
`RemapFileNameExt::for_scope` is no longer useful as it's replaced by
methods on `FileName` and `RealFileName`.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#142380 (Put negative implementors first and apply same ordering logic to foreign implementors)
- rust-lang/rust#146584 (remove duplicated columns from `rustc_error_code::error_codes!`)
- rust-lang/rust#148717 (Point at span within local macros even when error happens in nested external macro)
- rust-lang/rust#149565 (rustdoc: Add unstable `--merge-doctests=yes/no/auto` flag)
- rust-lang/rust#149770 (Rename some issue-* tests)
- rust-lang/rust#149807 (Use ubuntu:24.04 for the `x86_64-gnu-miri` job)
- rust-lang/rust#149850 (Remove "tidy" tool for `tests/rustdoc` testsuite)
- rust-lang/rust#149863 (Do not suggest moving expression out of for loop when hitting `break` from desugaring)
- rust-lang/rust#149867 (only resolve main in bin crates)
r? `@ghost`
`@rustbot` modify labels: rollup
Port `doc` attributes to new attribute API
Part of https://github.com/rust-lang/rust/issues/131229.
This PR ports the `doc` attributes to the new attribute API. However, there are things that will need to be fixed in a follow-up:
* Some part of `cfg_old.rs` are likely unused now, so they should be removed.
* Not all error/lints are emitted at the same time anymore, making them kinda less useful considering that you need to run and fix rustc/rustdoc multiple times to get through all of them.
* For coherency with the other attribute errors, I didn't modify the default output too much, meaning that we have some new messages now. I'll likely come back to that to check if the previous ones were better in a case-by-case approach.
* `doc(test(attr(...)))` is handled in a horrifying manner currently. Until we can handle it correctly with the `Attribute` system, it'll remain that thing we're all very ashamed of. 😈
* A type in rustdoc got its size increased, I'll check the impact on performance. But in any case, I plan to improve it in a follow-up so should be "ok".
* Because of error reporting, some fields of `Doc` are suboptimal, like `inline` which instead of being an `Option` is a `ThinVec` because we report the error later on. Part of the things I'm not super happy about but can be postponed to future me.
* In `src/librustdoc/clean/cfg.rs`, the `pub(crate) fn parse(cfg: &MetaItemInner) -> Result<Cfg, InvalidCfgError> {` function should be removed once `cfg_trace` has been ported to new `cfg` API.
* Size of type `DocFragment` went from 32 to 48. Would be nice to get it back to 32.
* ``malformed `doc` attribute input`` wasn't meant for so many candidates, should be improved.
* See how many of the checks in `check_attr` we can move to attribute parsing
* Port target checking to be in the attribute parser completely
* Fix target checking for `doc(alias)` on fields & patterns
And finally, once this PR is merged, I plan to finally stabilize `doc_cfg` feature. :)
cc `@jdonszelmann`
r? `@JonathanBrouwer`
Emit `check-cfg` lints during attribute parsing rather than evaluation
The goal of this PR is to make the `eval_config_entry` not have any side effects, by moving the check-cfg lints to the attribute parsing. This also helps ensure we do emit the lint in situations where the attribute happens to be parsed, but never evaluated.
cc ``@jdonszelmann`` ``@Urgau`` for a vibe check if you feel like it
Fix bad intra-doc-link preprocessing
How did rust-lang/rust#147981 happen?
1. We don't parse intra-doc links as Rust paths or qpaths. Instead they follow a very lenient bespoke grammar. We completely ignore Markdown links if they contain characters that don't match `/[a-zA-Z0-9_:<>, !*&;]/` (we don't even emit lint *broken-intra-doc-links* for these).
2. PR [#132748](https://github.com/rust-lang/rust/pull/132748) made rustdoc intepret more Markdown links as potential intra-doc links. Namely, if the link is surrounded by backticks (and some other conditions apply) then it doesn't matter if the (partially processed) link contains bad characters as defined above (cc `ignore_urllike && should_ignore_link(path_str)`).
3. However, rustdoc's `preprocess_link` must be kept in sync with a simplified counterpart in rustc. More specifically, whenever rustdoc's preprocessor returns a successful result then rustc's must yield the same result. Otherwise, rustc doesn't resolve the necessary links for rustdoc.
4. This uncovered a "dormant bug" / "mistake" in rustc's `preprocess_link`. Namely, when presented with a link like `struct@Type@suffix`, it didn't cut off the disambiguator if present (here: `struct@`). Instead it `rsplit('``@')``` which is incorrect if the "path" contains ```@``` itself (yielding `suffix` instead of `Type@suffix` here). Prior to PR [#132748](https://github.com/rust-lang/rust/pull/132748), a link like ``[`struct@Type@suffix`]`` was not considered a potential intra-doc link / worth querying rustc for. Now it is due to the backticks.
5. Finally, since rustc didn't record a resolution for `Type@suffix` (it only recorded `suffix` (to be `Res::Err`)), we triggered an assertion we have in place to catch cases like this.
Fixesrust-lang/rust#147981.
I didn't and still don't have the time to investigate if rust-lang/rust#132748 led to more rustc/rustdoc mismatches (after all, the PR made rustdoc's `preprocess_link` return `Some(Ok(_))` in more cases). I've at least added another much needed "warning banner" & made the existing one more flashy.
While this fixes a stable-to-beta regression, I don't think it's worth beta backporting, esp. since it's only P-medium and since the final 1.91 release steps commence today / the next days, so it would only be stressful to get it in on time. However, feel free to nominate.
<sub>(I've written such a verbose PR description since I tend to reread my old PR descriptions in the far future to fully freshen my memories when I have to work again in this area)</sub>
r? ``@lolbinarycat``
Jacob Pratt