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
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`.
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
Check unsafety for non-macro attributes in `validate_attr`
r? `````@jdonszelmann`````
Also adds a test for a previously untested case, unnecessary unsafe on a proc macro attribute
In preparation for https://github.com/rust-lang/rust/issues/148453
mgca: Add ConstArg representation for const items
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#131046fixesrust-lang/rust#134641
As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item.
To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR.
We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
Improve diagnostics: update note and add help message
I moved the content from the note to a help message, as it seemed more appropriate there, and then added new information to the note(`Modules are usually placed outside of blocks, at the top level of the file`)!
resolve: rust-lang/rust#147314
mbe: Implement `unsafe` attribute rules
This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](https://github.com/rust-lang/rfcs/pull/3697).
An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax.
An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax.
`unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule.
Tracking issue for `macro_rules!` attributes: https://github.com/rust-lang/rust/issues/143547
`LegacyAttr` is only used for builtin attributes, and builtin attributes
have their safety checked by `check_attribute_safety`, so we don't need
to check `unsafety` here.
mbe: macro_check: Fix function comments referencing non-existent parameters
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
mbe: Simplify check_redundant_vis_repetition
Eliminate a use of `map_or` in favor of a match.
Inline some variable definitions that don't add clarity, and that
prevent short-circuiting.
Reduce some uses of `LegacyBang`
- **Switch `dummy_bang` from `LegacyBang` to `Bang`**
- **mbe: Switch dummy extension used for errors from `LegacyBang` to `Bang`**
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
mbe: Simplifications and refactoring
A few simplifications and refactors in advance of other work.
Macro metavariable expressions were using `Ident::as_str` and doing string
comparisons; I converted them to use symbols.
I factored out a function for transcribing a `ParseNtResult`, which will help
separate the evaluation and transcription of future macro metavariable
expressions.