Add `#[rustc_safe_intrinsic]`
This PR adds the `#[rustc_safe_intrinsic]` attribute as mentionned on Zulip. The goal of this attribute is to avoid keeping a list of symbols as the source for stable intrinsics, and instead rely on an attribute. This is similar to `#[rustc_const_stable]` and `#[rustc_const_unstable]`, which among other things, are used to mark the constness of intrinsic functions.
Do not overwrite lifetime binders for another HirId.
This PR makes higher-ranked bounds in where clauses a bit more principled.
We used to conflate `for<'a> T: Trait` with `(for<'a> T): Trait`.
This PR separates both binders.
This caused issued with fn types, which have their own binder, causing us to overwrite the predicates's binders with `fn`'s binders, ICEing.
Fixes https://github.com/rust-lang/rust/issues/98594
Migrate more of rustc_parse to SessionDiagnostic
Still far from complete, but I thought I'd add a checkpoint here because rebasing was starting to get annoying.
Rollup of 8 pull requests
Successful merges:
- #100747 (Add long description and test for E0311)
- #102232 (Stabilize bench_black_box)
- #102288 (Suggest unwrapping `???<T>` if a method cannot be found on it but is present on `T`.)
- #102338 (Deny associated type bindings within associated type bindings)
- #102347 (Unescaping cleanups)
- #102348 (Tweak `FulfillProcessor`.)
- #102378 (Use already resolved `self_ty` in `confirm_fn_pointer_candidate`)
- #102380 (rustdoc: remove redundant mobile `.source > .sidebar` CSS)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Deny associated type bindings within associated type bindings
Fixes#102335
This was made worse by #100865, which unified the way we generate substs for GATs and non-generic associated types. However, the issue was not _caused_ by #100865, evidenced by the test I added for GATs:
```rust
trait T {
type A: S<C<(), i32 = ()> = ()>;
//~^ ERROR associated type bindings are not allowed here
}
trait Q {}
trait S {
type C<T>: Q;
}
fn main() {}
```
^ which passes on beta (where GATs are stable) and presumably ever since GATs support was added to `create_substs_for_associated_item` in astconv.
Suggest unwrapping `???<T>` if a method cannot be found on it but is present on `T`.
This suggests various ways to get inside wrapper types if the method cannot be found on the wrapper type, but is present on the wrappee.
For this PR, those wrapper types include `Localkey`, `MaybeUninit`, `RefCell`, `RwLock` and `Mutex`.
Stabilize bench_black_box
This PR stabilize `feature(bench_black_box)`.
```rust
pub fn black_box<T>(dummy: T) -> T;
```
The FCP was completed in https://github.com/rust-lang/rust/issues/64102.
`@rustbot` label +T-libs-api -T-libs
Rewrite and refactor format_args!() builtin macro.
This is a near complete rewrite of `compiler/rustc_builtin_macros/src/format.rs`.
This gets rid of the massive unmaintanable [`Context` struct](76531befc4/compiler/rustc_builtin_macros/src/format.rs (L176-L263)), and splits the macro expansion into three parts:
1. First, `parse_args` will parse the `(literal, arg, arg, name=arg, name=arg)` syntax, but doesn't parse the template (the literal) itself.
2. Second, `make_format_args` will parse the template, the format options, resolve argument references, produce diagnostics, and turn the whole thing into a `FormatArgs` structure.
3. Finally, `expand_parsed_format_args` will turn that `FormatArgs` structure into the expression that the macro expands to.
In other words, the `format_args` builtin macro used to be a hard-to-maintain 'single pass compiler', which I've split into a three phase compiler with a parser/tokenizer (step 1), semantic analysis (step 2), and backend (step 3). (It's compilers all the way down. ^^)
This can serve as a great starting point for https://github.com/rust-lang/rust/issues/99012, which will only need to change the implementation of 3, while leaving step 1 and 2 unchanged.
It also makes https://github.com/rust-lang/compiler-team/issues/541 easier, which could then upgrade the new `FormatArgs` struct to an `ast` node and remove step 3, moving that step to later in the compilation process.
It also fixes a few diagnostics bugs.
This also [significantly reduces](https://gist.github.com/m-ou-se/b67b2d54172c4837a5ab1b26fa3e5284) the amount of generated code for cases with arguments in non-default order without formatting options, like `"{1} {0}"` or `"{a} {}"`, etc.
- Rename `unescape_raw_str_or_raw_byte_str` as
`unescape_raw_str_or_byte_str`, which is more accurate.
- Remove the unused `Mode::in_single_quotes` method.
- Make some assertions more precise, and add a missing one to
`unescape_char_or_byte`.
- Change all the assertions to `debug_assert!`, because this code is
reasonably hot, and the assertions aren't required for memory safety,
and any violations are likely to be sufficiently obvious that normal
tests will trigger them.
session: remove now-unnecessary lint `#[allow]`s
In #101230, the internal diagnostic migration lints - `diagnostic_outside_of_impl` and `untranslatable_diagnostic` - were modified so that they wouldn't trigger on functions annotated with `#[rustc_lint_diagnostics]`. However, this change has to make it into the bootstrap compiler before the `#[allow]` annotations that it aims to remove can be removed, which is possible now that #102051 has landed.
Avoid LLVM-deprecated `Optional::hasValue`
LLVM 15 added `Optional::has_value`, and LLVM `main` (16) has deprecated
`hasValue`. However, its `explicit operator bool` does the same thing,
and was added long ago, so we can use that across our full LLVM range of
compatibility.
