Changes the error handler for inner attributes that replace the root
with a non-module. Previously it would emit a fatal error. It now emits
an empty expasion and a non-fatal error like the existing handler for a
failed expansion.
Address inconsistency in using "is" with "declared here"
"is" was generally used for NLL diagnostics, but not other diagnostics. Using "is" makes the diagnostics sound more natural and readable, so it seems sensible to commit to them throughout.
r? @Centril
```
error[E0412]: cannot find type `T` in this scope
--> file.rs:3:12
|
3 | impl Trait<T> for Struct {}
| - ^ not found in this scope
| |
| help: you might be missing a type parameter: `<T>`
```
Fix#64298.
Fixes#66910
We have several different kinds of suggestions we can try to make when
type coercion fails. However, we were previously only emitting these
suggestions from `demand_coerce_diag`. This resulted in the compiler
failing to emit applicable suggestions in several different cases, such
as when the implicit return value of a function had the wrong type.
This commit adds a new `emit_coerce_suggestions` method, which tries to
emit a number of related suggestions. This method is called from both
`demand_coerce_diag` and `CoerceMany::coerce_inner`, which covers a much
wider range of cases than before.
We now suggest using `.await` in more cases where it is applicable,
among other improvements.
Making ICEs and test them in incremental
This adds:
- A way to make the compiler ICE
- A way to check for ICE in `cfail` tests with `should-ice`
- A regression test for issue #65401
I am not sure the attribute added `should-ice` is the best for this job
Fix error message about exported symbols from proc-macro crates
Someone forgot to update the error message after `#[proc_macro]` and
`#[proc_macro_attribute]` were stabilized.
Support registering inert attributes and attribute tools using crate-level attributes
And remove `#[feature(custom_attribute)]`.
(`rustc_plugin::Registry::register_attribute` is not removed yet, I'll do it in a follow up PR.)
```rust
#![register_attr(my_attr)]
#![register_tool(my_tool)]
#[my_attr] // OK
#[my_tool::anything] // OK
fn main() {}
```
---
Some tools (`rustfmt` and `clippy`) used in tool attributes are hardcoded in the compiler.
We need some way to introduce them without hardcoding as well.
This PR introduces a way to do it with a crate level attribute.
The previous attempt to introduce them through command line (https://github.com/rust-lang/rust/pull/57921) met some resistance.
This probably needs to go through an RFC before stabilization.
However, I'd prefer to land *this* PR without an RFC to able to remove `#[feature(custom_attribute)]` and `Registry::register_attribute` while also providing a replacement.
---
`register_attr` is a direct replacement for `#![feature(custom_attribute)]` (https://github.com/rust-lang/rust/issues/29642), except it doesn't rely on implicit fallback from unresolved attributes to custom attributes (which was always hacky and is the primary reason for the removal of `custom_attribute`) and requires registering the attribute explicitly.
It's not clear whether it should go through stabilization or not.
It's quite possible that all the uses should migrate to `#![register_tool]` (https://github.com/rust-lang/rust/issues/66079) instead.
---
Details:
- The naming is `register_attr`/`register_tool` rather than some `register_attributes` (plural, no abbreviation) for consistency with already existing attributes like `cfg_attr`, or `feature`, etc.
---
Previous attempt: https://github.com/rust-lang/rust/pull/57921
cc https://github.com/rust-lang/rust/issues/44690
Tracking issues: #66079 (`register_tool`), #66080 (`register_attr`)
Closes https://github.com/rust-lang/rust/issues/29642
Re-enable Emscripten's exception handling support
Passes LLVM codegen and Emscripten link-time flags for exception
handling if and only if the panic strategy is `unwind`. Sets the
default panic strategy for Emscripten targets to `unwind`. Re-enables
tests that depend on unwinding support for Emscripten, including
`should_panic` tests.
r? @alexcrichton
