Much like the previous commit.
I think the removal of "the token" in each message is fine here. There
are many more error messages that mention tokens without saying "the
token" than those that do say it.
By using `token_descr`, as is done for many other errors, we can get
slightly better descriptions in error messages, e.g.
"macro expansion ignores token `let` and any following" becomes
"macro expansion ignores keyword `let` and any tokens following".
This will be more important once invisible delimiters start being
mentioned in error messages -- without this commit, that leads to error
messages such as "error at ``" because invisible delimiters are
pretty printed as an empty string.
Use `Enabled{Lang,Lib}Feature` instead of n-tuples
Instead of passing around e.g. `(gate_name, attr_span, stable_since)` 3-tuples for enabled lang features or `(gate_name, attr_span)` 2-tuples for enabled lib features, use `Enabled{Lang,Lib}Feature` structs with named fields.
Also did some minor code-golfing of involved iterator chains to hopefully make them easier to follow.
Follow-up to https://github.com/rust-lang/rust/pull/132098#issuecomment-2434523431 cc `@RalfJung.`
Fundamentally, we have *three* disjoint categories of functions:
1. const-stable functions
2. private/unstable functions that are meant to be callable from const-stable functions
3. functions that can make use of unstable const features
This PR implements the following system:
- `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions.
- `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category.
- `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls.
Also, several holes in recursive const stability checking are being closed.
There's still one potential hole that is hard to avoid, which is when MIR
building automatically inserts calls to a particular function in stable
functions -- which happens in the panic machinery. Those need to *not* be
`rustc_const_unstable` (or manually get a `rustc_const_stable_indirect`) to be
sure they follow recursive const stability. But that's a fairly rare and special
case so IMO it's fine.
The net effect of this is that a `#[unstable]` or unmarked function can be
constified simply by marking it as `const fn`, and it will then be
const-callable from stable `const fn` and subject to recursive const stability
requirements. If it is publicly reachable (which implies it cannot be unmarked),
it will be const-unstable under the same feature gate. Only if the function ever
becomes `#[stable]` does it need a `#[rustc_const_unstable]` or
`#[rustc_const_stable]` marker to decide if this should also imply
const-stability.
Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to
use unstable const lang features (including intrinsics), or (b) `#[stable]`
functions that are not yet intended to be const-stable. Adding
`#[rustc_const_stable]` is only needed for functions that are actually meant to
be directly callable from stable const code. `#[rustc_const_stable_indirect]` is
used to mark intrinsics as const-callable and for `#[rustc_const_unstable]`
functions that are actually called from other, exposed-on-stable `const fn`. No
other attributes are required.
"innermost", "outermost", "leftmost", and "rightmost" don't need hyphens
These are all standard dictionary words and don't require hyphenation.
-----
Encountered an instance of this in error messages and it bugged me, so I
figured I'd fix it across the entire codebase.
Rollup of 8 pull requests
Successful merges:
- #125205 (Fixup Windows verbatim paths when used with the `include!` macro)
- #131049 (Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`)
- #131549 (Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function)
- #131731 (add `TestFloatParse` to `tools.rs` for bootstrap)
- #131732 (Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES)
- #132006 (don't stage-off to previous compiler when CI rustc is available)
- #132022 (Move `cmp_in_dominator_order` out of graph dominator computation)
- #132033 (compiletest: Make `line_directive` return a `DirectiveLine`)
r? `@ghost`
`@rustbot` modify labels: rollup
Fixup Windows verbatim paths when used with the `include!` macro
On Windows, the following code can fail if the `OUT_DIR` environment variable is a [verbatim path](https://doc.rust-lang.org/std/path/enum.Prefix.html) (i.e. begins with `\\?\`):
```rust
include!(concat!(env!("OUT_DIR"), "/src/repro.rs"));
```
This is because verbatim paths treat `/` literally, as if it were just another character in the file name.
The good news is that the standard library already has code to fix this. We can simply use `components` to normalize the path so it works as intended.
Rollup of 9 pull requests
Successful merges:
- #122670 (Fix bug where `option_env!` would return `None` when env var is present but not valid Unicode)
- #131095 (Use environment variables instead of command line arguments for merged doctests)
- #131339 (Expand set_ptr_value / with_metadata_of docs)
- #131652 (Move polarity into `PolyTraitRef` rather than storing it on the side)
- #131675 (Update lint message for ABI not supported)
- #131681 (Fix up-to-date checking for run-make tests)
- #131702 (Suppress import errors for traits that couldve applied for method lookup error)
- #131703 (Resolved python deprecation warning in publish_toolstate.py)
- #131710 (Remove `'apostrophes'` from `rustc_parse_format`)
r? `@ghost`
`@rustbot` modify labels: rollup
Make deprecated_cfg_attr_crate_type_name a hard error
Turns the forward compatibility lint added by #83744 into a hard error, so now, while the `#![crate_name]` and `#![crate_type]` attributes are still allowed in raw form, they are now forbidden to be nested inside a `#![cfg_attr()]` attribute.
The following will now be an error:
```Rust
#![cfg_attr(foo, crate_name = "foobar")]
#![cfg_attr(foo, crate_type = "bin")]
```
This code will continue working and is not deprecated:
```Rust
#![crate_name = "foobar"]
#![crate_type = "lib"]
```
The reasoning for this is explained in #83744: it allows us to not have to cfg-expand in order to determine the crate's type and name.
As of filing the PR, exactly two years have passed since #99784 has been merged, which has turned the lint's default warning level into an error, so there has been ample time to move off the now-forbidden syntax.
cc #91632 - tracking issue for the lint
Implement RFC3695 Allow boolean literals as cfg predicates
This PR implements https://github.com/rust-lang/rfcs/pull/3695: allow boolean literals as cfg predicates, i.e. `cfg(true)` and `cfg(false)`.
r? `@nnethercote` *(or anyone with parser knowledge)*
cc `@clubby789`
rustc_expand: remember module `#[path]`s during expansion
During invocation collection, if a module item parsed from a `#[path]` attribute needed a second pass after parsing, its path wouldn't get added to the file path stack, so cycle detection broke. This checks the `#[path]` in such cases, so that it gets added appropriately. I think it should work identically to the case for external modules that don't need a second pass, but I'm not 100% sure.
Fixes#97589
Stabilize `unsafe_attributes`
# Stabilization report
## Summary
This is a tracking issue for the RFC 3325: unsafe attributes
We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`.
RFC: rust-lang/rfcs#3325
Tracking issue: #123757
## What is stabilized
### Summary of stabilization
Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones.
```rust
#[unsafe(no_mangle)]
fn a() {}
#[cfg_attr(any(), unsafe(export_name = "c"))]
fn b() {}
```
For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](https://github.com/rust-lang/rust/pull/124214#issuecomment-2124753464)
## Tests
The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.
Use more slice patterns inside the compiler
Nothing super noteworthy. Just replacing the common 'fragile' pattern of "length check followed by indexing or unwrap" with slice patterns for legibility and 'robustness'.
r? ghost
When using `concat!` to join paths, the Unix path separator (`/`) is often used. This breaks on Windows if the base path is a verbatim path (i.e. starts with `\\?\`).
This makes it possible for the `unsafe(...)` syntax to only be
valid at the top level, and the `NestedMetaItem`s will automatically
reject `unsafe(...)`.
Tell users not to file a bug when using internal library features
Actually fixes#97501. I don't think we should suppress the suggestion to add `#![feature(..)]`, though I guess I could be convinced otherwise.
r? `@Nilstrieb` cc `@RalfJung`
Didn't add a test b/c I don't think we test this for lang features either, but I can confirm it does work.
```
warning: the feature `core_intrinsics` is internal to the compiler or standard library
--> /home/michael/test.rs:1:12
|
1 | #![feature(core_intrinsics)]
| ^^^^^^^^^^^^^^^
|
= note: using it is strongly discouraged
= note: `#[warn(internal_features)]` on by default
thread 'rustc' panicked at compiler/rustc_mir_transform/src/validate.rs:94:25:
broken MIR in Item(DefId(0:6 ~ test[42db]::{impl#0}::add)) (after phase change to runtime-optimized) at bb0[0]:
Cannot perform arithmetic Add on type WrapInt8
stack backtrace:
0: begin_panic_handler
at ./library/std/src/panicking.rs:665:5
1: panic_fmt
at ./library/core/src/panicking.rs:74:14
2: fail<alloc::string::String>
at ./compiler/rustc_mir_transform/src/validate.rs:146:9
3: run_pass
at ./compiler/rustc_mir_transform/src/validate.rs:94:13
4: validate_body
at ./compiler/rustc_mir_transform/src/pass_manager.rs:193:5
5: run_passes_inner
at ./compiler/rustc_mir_transform/src/pass_manager.rs:176:13
6: rustc_mir_transform::pass_manager::run_passes
at ./compiler/rustc_mir_transform/src/pass_manager.rs:87:5
7: run_optimization_passes
at ./compiler/rustc_mir_transform/src/lib.rs:561:5
8: inner_optimized_mir
at ./compiler/rustc_mir_transform/src/lib.rs:667:5
9: optimized_mir
at ./compiler/rustc_mir_transform/src/lib.rs:630:21
10: {closure#0}
at ./compiler/rustc_query_impl/src/plumbing.rs:285:13
[... omitted 22 frames ...]
11: query_get_at<rustc_query_system::query::caches::DefIdCache<rustc_middle::query::erase::Erased<[u8; 8]>>>
at ./compiler/rustc_middle/src/query/plumbing.rs:145:17
12: instance_mir
13: collect_items_of_instance
at ./compiler/rustc_monomorphize/src/collector.rs:1203:16
14: {closure#0}
at ./compiler/rustc_monomorphize/src/collector.rs:447:17
15: maybe_grow<(), rustc_monomorphize::collector::collect_items_rec::{closure_env#0}>
at /home/michael/.cargo/registry/src/index.crates.io-6f17d22bba15001f/stacker-0.1.15/src/lib.rs:55:9
16: ensure_sufficient_stack<(), rustc_monomorphize::collector::collect_items_rec::{closure_env#0}>
at ./compiler/rustc_data_structures/src/stack.rs:17:5
17: collect_items_rec
at ./compiler/rustc_monomorphize/src/collector.rs:446:13
18: collect_items_rec
at ./compiler/rustc_monomorphize/src/collector.rs:526:13
19: {closure#0}
at ./compiler/rustc_monomorphize/src/collector.rs:1597:17
20: {closure#0}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>
at ./compiler/rustc_data_structures/src/sync/parallel.rs:182:34
21: call_once<(), rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure#0}::{closure#0}::{closure_env#0}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>
at ./library/core/src/panic/unwind_safe.rs:272:9
22: do_call<core::panic::unwind_safe::AssertUnwindSafe<rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure#0}::{closure#0}::{closure_env#0}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>, ()>
at ./library/std/src/panicking.rs:557:40
23: try<(), core::panic::unwind_safe::AssertUnwindSafe<rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure#0}::{closure#0}::{closure_env#0}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>>
at ./library/std/src/panicking.rs:521:19
24: run<(), rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure#0}::{closure#1}::{closure_env#0}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>
at ./compiler/rustc_data_structures/src/sync/parallel.rs:28:9
25: {closure#1}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>
at ./compiler/rustc_data_structures/src/sync/parallel.rs:186:21
26: {closure#0}<rustc_middle::mir::mono::MonoItem, rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure#0}::{closure_env#1}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>
at ./library/core/src/iter/traits/iterator.rs:815:29
27: fold<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global, (), core::iter::traits::iterator::Iterator::for_each::call::{closure_env#0}<rustc_middle::mir::mono::MonoItem, rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure#0}::{closure_env#1}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>>
at ./library/alloc/src/vec/into_iter.rs:317:25
28: for_each<alloc::vec::into_iter::IntoIter<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure#0}::{closure_env#1}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>
at ./library/core/src/iter/traits/iterator.rs:818:9
29: {closure#0}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>
at ./compiler/rustc_data_structures/src/sync/parallel.rs:185:17
30: parallel_guard<(), rustc_data_structures::sync::parallel::enabled::par_for_each_in::{closure_env#0}<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>>
at ./compiler/rustc_data_structures/src/sync/parallel.rs:44:15
31: par_for_each_in<rustc_middle::mir::mono::MonoItem, alloc::vec::Vec<rustc_middle::mir::mono::MonoItem, alloc::alloc::Global>, rustc_monomorphize::collector::collect_crate_mono_items::{closure#1}::{closure_env#0}>
at ./compiler/rustc_data_structures/src/sync/parallel.rs:178:9
32: {closure#1}
at ./compiler/rustc_monomorphize/src/collector.rs:1595:13
33: run<(), rustc_monomorphize::collector::collect_crate_mono_items::{closure_env#1}>
at ./compiler/rustc_data_structures/src/profiling.rs:754:9
34: time<(), rustc_monomorphize::collector::collect_crate_mono_items::{closure_env#1}>
at ./compiler/rustc_session/src/utils.rs:16:9
35: collect_crate_mono_items
at ./compiler/rustc_monomorphize/src/collector.rs:1594:9
36: collect_and_partition_mono_items
at ./compiler/rustc_monomorphize/src/partitioning.rs:1124:30
37: {closure#0}
at ./compiler/rustc_query_impl/src/plumbing.rs:281:9
[... omitted 22 frames ...]
38: query_get_at<rustc_query_system::query::caches::SingleCache<rustc_middle::query::erase::Erased<[u8; 24]>>>
at ./compiler/rustc_middle/src/query/plumbing.rs:145:17
39: collect_and_partition_mono_items
at ./compiler/rustc_middle/src/query/plumbing.rs:423:31
40: collect_and_partition_mono_items
at ./compiler/rustc_middle/src/query/plumbing.rs:414:17
41: codegen_crate<rustc_codegen_llvm::LlvmCodegenBackend>
at ./compiler/rustc_codegen_ssa/src/base.rs:596:25
42: codegen_crate
at ./compiler/rustc_codegen_llvm/src/lib.rs:361:18
43: {closure#0}
at ./compiler/rustc_interface/src/passes.rs:1027:9
44: run<alloc::boxed::Box<dyn core::any::Any, alloc::alloc::Global>, rustc_interface::passes::start_codegen::{closure_env#0}>
at ./compiler/rustc_data_structures/src/profiling.rs:754:9
45: time<alloc::boxed::Box<dyn core::any::Any, alloc::alloc::Global>, rustc_interface::passes::start_codegen::{closure_env#0}>
at ./compiler/rustc_session/src/utils.rs:16:9
46: start_codegen
at ./compiler/rustc_interface/src/passes.rs:1026:19
47: codegen_and_build_linker
at ./compiler/rustc_interface/src/queries.rs:128:31
48: {closure#6}
at ./compiler/rustc_driver_impl/src/lib.rs:451:25
49: {closure#1}<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure_env#6}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_middle/src/ty/context.rs:1336:37
50: {closure#0}<rustc_middle::ty::context::{impl#19}::enter::{closure_env#1}<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure_env#6}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_middle/src/ty/context/tls.rs:82:9
51: try_with<core::cell::Cell<*const ()>, rustc_middle::ty::context::tls::enter_context::{closure_env#0}<rustc_middle::ty::context::{impl#19}::enter::{closure_env#1}<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure_env#6}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
at ./library/std/src/thread/local.rs:283:12
52: with<core::cell::Cell<*const ()>, rustc_middle::ty::context::tls::enter_context::{closure_env#0}<rustc_middle::ty::context::{impl#19}::enter::{closure_env#1}<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure_env#6}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
at ./library/std/src/thread/local.rs:260:9
53: enter_context<rustc_middle::ty::context::{impl#19}::enter::{closure_env#1}<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure_env#6}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_middle/src/ty/context/tls.rs:79:5
54: enter<rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure_env#6}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_middle/src/ty/context.rs:1336:9
55: <rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>>::enter::<core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#0}::{closure#1}::{closure#6}>
at ./compiler/rustc_interface/src/queries.rs:64:9
56: {closure#1}
at ./compiler/rustc_driver_impl/src/lib.rs:450:13
57: enter<rustc_driver_impl::run_compiler::{closure#0}::{closure_env#1}, core::result::Result<core::option::Option<rustc_interface::queries::Linker>, rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_interface/src/queries.rs:209:19
58: {closure#0}
at ./compiler/rustc_driver_impl/src/lib.rs:388:22
59: {closure#1}<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure_env#0}>
at ./compiler/rustc_interface/src/interface.rs:502:27
60: {closure#0}<rustc_interface::interface::run_compiler::{closure_env#1}<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure_env#0}>, core::result::Result<(), rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_interface/src/util.rs:154:13
61: {closure#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#1}<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure_env#0}>, core::result::Result<(), rustc_span::ErrorGuaranteed>>, core::result::Result<(), rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_interface/src/util.rs:106:21
62: set<rustc_span::SessionGlobals, rustc_interface::util::run_in_thread_with_globals::{closure#0}::{closure#0}::{closure_env#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#1}<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure_env#0}>, core::result::Result<(), rustc_span::ErrorGuaranteed>>, core::result::Result<(), rustc_span::ErrorGuaranteed>>, core::result::Result<(), rustc_span::ErrorGuaranteed>>
at /home/michael/.cargo/registry/src/index.crates.io-6f17d22bba15001f/scoped-tls-1.0.1/src/lib.rs:137:9
63: create_session_globals_then<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_interface::util::run_in_thread_with_globals::{closure#0}::{closure#0}::{closure_env#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#1}<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure_env#0}>, core::result::Result<(), rustc_span::ErrorGuaranteed>>, core::result::Result<(), rustc_span::ErrorGuaranteed>>>
at ./compiler/rustc_span/src/lib.rs:134:5
64: {closure#0}<rustc_interface::util::run_in_thread_pool_with_globals::{closure_env#0}<rustc_interface::interface::run_compiler::{closure_env#1}<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure_env#0}>, core::result::Result<(), rustc_span::ErrorGuaranteed>>, core::result::Result<(), rustc_span::ErrorGuaranteed>>
at ./compiler/rustc_interface/src/util.rs:105:17
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: the compiler unexpectedly panicked. this is a bug.
note: using internal features is not supported and expected to cause internal compiler errors when used incorrectly
note: rustc 1.82.0-dev running on x86_64-unknown-linux-gnu
query stack during panic:
#0 [optimized_mir] optimizing MIR for `<impl at /home/michael/test.rs:9:1: 9:32>::add`
#1 [collect_and_partition_mono_items] collect_and_partition_mono_items
end of query stack
```
`missing_fragment_specifier` has been a future compatibility warning
since 2017. Uplifting it to an unconditional hard error was attempted in
2020, but eventually reverted due to fallout.
Make it an error only in edition >= 2024, leaving the lint for older
editions. This change will make it easier to support more macro syntax
that relies on usage of `$`.
Fixes <https://github.com/rust-lang/rust/issues/40107>
Improve spans on evaluated `cfg_attr`s.
When converting something like `#![cfg_attr(cond, attr)]` into `#![attr]`, we currently duplicate the `#` token and the `!` token. But weirdly, there is also this comment:
// We don't really have a good span to use for the synthesized `[]`
// in `#[attr]`, so just use the span of the `#` token.
Maybe that comment used to be true? But now it is false: we can duplicate the existing delimiters (and their spans and spacing), much like we do for the `#` and `!`.
This commit does that, thus removing the incorrect comment, and improving the spans on `Group`s in a few proc-macro tests.
`@petrochenkov`
When converting something like `#![cfg_attr(cond, attr)]` into
`#![attr]`, we currently duplicate the `#` token and the `!` token. But
weirdly, there is also this comment:
// We don't really have a good span to use for the synthesized `[]`
// in `#[attr]`, so just use the span of the `#` token.
Maybe that comment used to be true? But now it is false: we can
duplicate the existing delimiters (and their spans and spacing), much
like we do for the `#` and `!`.
This commit does that, thus removing the incorrect comment, and
improving the spans on `Group`s in a few proc-macro tests.
This commit does the following.
- Pulls the code out of `AttrTokenStream::to_token_trees` into a new
function `attrs_and_tokens_to_token_trees`.
- Simplifies `TokenStream::from_ast` by calling the new function. This
is nicer than the old way, which created a temporary
`AttrTokenStream` containing a single `AttrsTarget` (which required
some cloning) just to call `to_token_trees` on it. (It is good to
remove this use of `AttrsTarget` which isn't related to `cfg_attr`
expansion.)
[`macro_metavar_expr_concat`] Add support for literals
Adds support for things like `${concat($variable, 123)}` or `${concat("hello", "_world")}` .
cc #124225
The number of source code bytes can't exceed a `u32`'s range, so a token
position also can't. This reduces the size of `Parser` and
`LazyAttrTokenStreamImpl` by eight bytes each.
Just some extra sanity checking, making explicit some values not
possible in code working with token trees -- we shouldn't be seeing
explicit delimiter tokens, because they should be represented as
`TokenTree::Delimited`.
Add hard error and migration lint for unsafe attrs
More implementation work for https://github.com/rust-lang/rust/issues/123757
This adds the migration lint for unsafe attributes, as well as making it a hard error in Rust 2024.
Rework pattern and expression nonterminal kinds.
Some tweaks to `NonterminalKind` that will assist with #124141. Details in the individual commits.
r? compiler-errors
cc ```@eholk```
Merge `PatParam`/`PatWithOr`, and `Expr`/`Expr2021`, for a few reasons.
- It's conceptually nice, because the two pattern kinds and the two
expression kinds are very similar.
- With expressions in particular, there are several places where both
expression kinds get the same treatment.
- It removes one unreachable match arm.
- Most importantly, for #124141 I will need to introduce a new type
`MetaVarKind` that is very similar to `NonterminalKind`, but records a
couple of extra fields for expression metavars. It's nicer to have a
single `MetaVarKind::Expr` expression variant to hold those extra
fields instead of duplicating them across two variants
`MetaVarKind::{Expr,Expr2021}`. And then it makes sense for patterns
to be treated the same way, and for `NonterminalKind` to also be
treated the same way.
I also clarified the comments, because I have long found them a little
hard to understand.
Make edition dependent `:expr` macro fragment act like the edition-dependent `:pat` fragment does
Parse the `:expr` fragment as `:expr_2021` in editions <=2021, and as `:expr` in edition 2024. This is similar to how we parse `:pat` as `:pat_param` in edition <=2018 and `:pat_with_or` in >=2021, and means we can get rid of a span dependency from `nonterminal_may_begin_with`.
Specifically, this fixes a theoretical regression since the `expr_2021` macro fragment previously would allow `const {}` if the *caller* is edition 2024. This is inconsistent with the way that the `pat` macro fragment was upgraded, and also leads to surprising behavior when a macro *caller* crate upgrades to edtion 2024, since they may have parsing changes that they never asked for (with no way of opting out of it).
This PR also allows using `expr_2021` in all editions. Why was this was disallowed in the first place? It's purely additive, and also it's still feature gated?
r? ```@fmease``` ```@eholk``` cc ```@vincenzopalazzo```
cc #123865
Tracking:
- https://github.com/rust-lang/rust/issues/123742
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
delegation: Implement glob delegation
Support delegating to all trait methods in one go.
Overriding globs with explicit definitions is also supported.
The implementation is generally based on the design from https://github.com/rust-lang/rfcs/pull/3530#issuecomment-2020869823, but unlike with list delegation in https://github.com/rust-lang/rust/pull/123413 we cannot expand glob delegation eagerly.
We have to enqueue it into the queue of unexpanded macros (most other macros are processed this way too), and then a glob delegation waits in that queue until its trait path is resolved, and enough code expands to generate the identifier list produced from the glob.
Glob delegation is only allowed in impls, and can only point to traits.
Supporting it in other places gives very little practical benefit, but significantly raises the implementation complexity.
Part of https://github.com/rust-lang/rust/issues/118212.
Spruce up the diagnostics of some early lints
Implement the various "*(note to myself) in a follow-up PR we should turn parts of this message into a subdiagnostic (help msg or even struct sugg)*" drive-by comments I left in #124417 during my review.
For context, before #124417, only a few early lints touched/decorated/customized their diagnostic because the former API made it a bit awkward. Likely because of that, things that should've been subdiagnostics were just crammed into the primary message. This PR rectifies this.
Currently we have an awkward mix of fallible and infallible functions:
```
new_parser_from_source_str
maybe_new_parser_from_source_str
new_parser_from_file
(maybe_new_parser_from_file) // missing
(new_parser_from_source_file) // missing
maybe_new_parser_from_source_file
source_str_to_stream
maybe_source_file_to_stream
```
We could add the two missing functions, but instead this commit removes
of all the infallible ones and renames the fallible ones leaving us with
these which are all fallible:
```
new_parser_from_source_str
new_parser_from_file
new_parser_from_source_file
source_str_to_stream
source_file_to_stream
```
This requires making `unwrap_or_emit_fatal` public so callers of
formerly infallible functions can still work.
This does make some of the call sites slightly more verbose, but I think
it's worth it for the simpler API. Also, there are two `catch_unwind`
calls and one `catch_fatal_errors` call in this diff that become
removable thanks this change. (I will do that in a follow-up PR.)
Lexing converts source text into a token stream. Parsing converts a
token stream into AST fragments. This commit renames several lexing
operations that have "parse" in the name. I think these names have been
subtly confusing me for years.
This is just a `s/parse/lex/` on function names, with one exception:
`parse_stream_from_source_str` becomes `source_str_to_stream`, to make
it consistent with the existing `source_file_to_stream`. The commit also
moves that function's location in the file to be just above
`source_file_to_stream`.
The commit also cleans up a few comments along the way.
We still check for the `rental`/`allsorts-rental` crates. But now if
they are detected we just emit a fatal error, instead of emitting a
warning and providing alternative behaviour.
The original "hack" implementing alternative behaviour was added
in #73345.
The lint was added in #83127.
The tracking issue is #83125.
The direct motivation for the change is that providing the alternative
behaviour is interfering with #125174 and follow-on work.
cleanup dependence of `ExtCtxt` in transcribe when macro expansion
part of #125356
We can remove `transcribe`’s dependence on `ExtCtxt` to facilitate subsequent work (such as moving macro expansion into the incremental compilation system)
r? ```@petrochenkov```
Thanks for the reviewing!
- Name the colon span as `colon_span` to distinguish it from the other
`span` local variable.
- Just use basic pattern matching, which is easier to read than `map_or`.
Translation of the lint message happens when the actual diagnostic is
created, not when the lint is buffered. Generating the message from
BuiltinLintDiag ensures that all required data to construct the message
is preserved in the LintBuffer, eventually allowing the messages to be
moved to fluent.
Remove the `msg` field from BufferedEarlyLint, it is either generated
from the data in the BuiltinLintDiag or stored inside
BuiltinLintDiag::Normal.
Update `expr` matcher for Edition 2024 and add `expr_2021` nonterminal
This commit adds a new nonterminal `expr_2021` in macro patterns, and `expr_fragment_specifier_2024` feature flag.
This change also updates `expr` so that on Edition 2024 it will also match `const { ... }` blocks, while `expr_2021` preserves the current behavior of `expr`, matching expressions without `const` blocks.
Joint work with `@vincenzopalazzo.`
Issue #123742
expand: fix minor diagnostics bug
The error mentions `///`, when it's actually `//!`:
```
error[E0658]: attributes on expressions are experimental
--> test.rs:4:9
|
4 | //! wah
| ^^^^^^^
|
= note: see issue https://github.com/rust-lang/rust/issues/15701 <https://github.com/rust-lang/rust/issues/15701> for more information
= help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable
= help: `///` is for documentation comments. For a plain comment, use `//`.
```
Rename `${length()}` to `${len()}`
Implements the rename suggested in https://github.com/rust-lang/rust/pull/122808#issuecomment-2047722187
> I brought this up in the doc PR but it belongs here – `length` should probably be renamed `len` before stabilization. The latter is de facto standard in the standard library, whereas the former is only used in a single unstable API. These metafunctions aren’t library items of course, but should presumably still be consistent with established names.
r? `@c410-f3r`
The extra span is now recorded in the new `TokenKind::NtIdent` and
`TokenKind::NtLifetime`. These both consist of a single token, and so
there's no operator precedence problems with inserting them directly
into the token stream.
The other way to do this would be to wrap the ident/lifetime in invisible
delimiters, but there's a lot of code that assumes an interpolated
ident/lifetime fits in a single token, and changing all that code to work with
invisible delimiters would have been a pain. (Maybe it could be done in a
follow-up.)
This change might not seem like much of a win, but it's a first step toward the
much bigger and long-desired removal of `Nonterminal` and
`TokenKind::Interpolated`. That change is big and complex enough that it's
worth doing this piece separately. (Indeed, this commit is based on part of a
late commit in #114647, a prior attempt at that big and complex change.)
This commit adds a new nonterminal `expr_2021` in macro patterns, and
`expr_fragment_specifier_2024` feature flag. For now, `expr` and
`expr_2021` are treated the same, but in future PRs we will update
`expr` to match to new grammar.
Co-authored-by: Vincezo Palazzo <vincenzopalazzodev@gmail.com>
This span records the declaration of the metavariable in the LHS of the macro.
It's used in a couple of error messages. Unfortunately, it gets in the way of
the long-term goal of removing `TokenKind::Interpolated`. So this commit
removes it, which degrades a couple of (obscure) error messages but makes
things simpler and enables the next commit.
The starting point for this was identical comments on two different
fields, in `ast::VariantData::Struct` and `hir::VariantData::Struct`:
```
// FIXME: investigate making this a `Option<ErrorGuaranteed>`
recovered: bool
```
I tried that, and then found that I needed to add an `ErrorGuaranteed`
to `Recovered::Yes`. Then I ended up using `Recovered` instead of
`Option<ErrorGuaranteed>` for these two places and elsewhere, which
required moving `ErrorGuaranteed` from `rustc_parse` to `rustc_ast`.
This makes things more consistent, because `Recovered` is used in more
places, and there are fewer uses of `bool` and
`Option<ErrorGuaranteed>`. And safer, because it's difficult/impossible
to set `recovered` to `Recovered::Yes` without having emitted an error.
Remove braces when fixing a nested use tree into a single item
[Back in 2019](https://github.com/rust-lang/rust/pull/56645) I added rustfix support for the `unused_imports` lint, to automatically remove them when running `cargo fix`. For the most part this worked great, but when removing all but one childs of a nested use tree it turned `use foo::{Unused, Used}` into `use foo::{Used}`. This is slightly annoying, because it then requires you to run `rustfmt` to get `use foo::Used`.
This PR automatically removes braces and the surrouding whitespace when all but one child of a nested use tree are unused. To get it done I had to add the span of the nested use tree to the AST, and refactor a bit the code I wrote back then.
A thing I noticed is, there doesn't seem to be any `//@ run-rustfix` test for fixing the `unused_imports` lint. I created a test in `tests/suggestions` (is that the right directory?) that for now tests just what I added in the PR. I can followup in a separate PR to add more tests for fixing `unused_lints`.
This PR is best reviewed commit-by-commit.
There are some test cases involving `parse` and `tokenstream` and
`mut_visit` that are located in `rustc_expand`. Because it used to be
the case that constructing a `ParseSess` required the involvement of
`rustc_expand`. However, since #64197 merged (a long time ago)
`rust_expand` no longer needs to be involved.
This commit moves the tests into `rustc_parse`. This is the optimal
place for the `parse` tests. It's not ideal for the `tokenstream` and
`mut_visit` tests -- they would be better in `rustc_ast` -- but they
still rely on parsing, which is not available in `rustc_ast`. But
`rustc_parse` is lower down in the crate graph and closer to `rustc_ast`
than `rust_expand`, so it's still an improvement for them.
The exact renaming is as follows:
- rustc_expand/src/mut_visit/tests.rs -> rustc_parse/src/parser/mut_visit/tests.rs
- rustc_expand/src/tokenstream/tests.rs -> rustc_parse/src/parser/tokenstream/tests.rs
- rustc_expand/src/tests.rs + rustc_expand/src/parse/tests.rs ->
compiler/rustc_parse/src/parser/tests.rs
The latter two test files are combined because there's no need for them
to be separate, and having a `rustc_parse::parser::parse` module would
be weird. This also means some `pub(crate)`s can be removed.
It is currently an enum and the `tts` and `idx` fields are repeated
across the two variants.
This commit splits it into a struct `Frame` and an enum `FrameKind`, to
factor out the duplication. The commit also renames `Frame::new` as
`Frame::new_delimited` and adds `Frame::new_sequence`. I.e. both
variants now have a constructor.
Control flow never gets past the end of the `ExpandResult::Retry` match
arm, due to the `span_bug` and the `continue`. Therefore, the code after
the match can only be reached from the `ExpandResult::Ready` arm.
This commit moves that code after the match into the
`ExpandResult::Ready` arm, avoiding the need for the `continue` in the
`ExpandResult::Retry` arm.
