Remove unneeded `forbid_generic` field from `Res::SelfTyAlias`
Following rust-lang/rust#150519, the `forbid_generic` field in `Res::SelfTyAlias` is no longer needed and can be removed.
- Remove the `forbid_generic: bool` field from `Res::SelfTyAlias`
- Simplify the ConstantItem rib handling in `rustc_resolve` - no longer need to mutate res to set `forbid_generic: true`
- Update all pattern matches and constructors of `SelfTyAlias`
Closesrust-lang/rust#150579
r? ``@camelid``
The `forbid_generic` field in `Res::SelfTyAlias` is no longer needed.
The check for generic `Self` types in anonymous constants is now handled
by `check_param_uses_if_mcg` in HIR type lowering, making this field
redundant.
This removes:
- The `forbid_generic` field from `Res::SelfTyAlias`
- The hack in `rustc_resolve` that set `forbid_generic: true` when
encountering `Self` in constant items
- Related pattern matching and field propagation code
Previously we could lose the already found binding and break with an error, if some blocking error was found in the shadowed scopes.
Also, avoid some impossible state in the return type of `fn resolve_ident_in_scope`.
fix ICE when {{root}} appears in import suggestions
Fixesrust-lang/rust#150103
When wrong nested imports like `use A::{::Fish}` were used, the internal {{root}} would appear in diagnostic suggestions, causing an ICE in `join_path_idents` which asserted that **{{root}} should only appear at the start of a path**.
r? ``@matthiaskrgr``
Support recursive delegation
This PR adds support for recursive delegations and is a part of the delegation feature rust-lang/rust#118212.
r? ``@petrochenkov``
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`
