Otherwise tests fail due to unknown lint and dead code warnings.

For consistency with other `Emitter` impls, such as `JsonEmitter`,
`SilentEmitter`, `SharedEmitter`, etc.

`Emitter` cleanups

Some improvements I found while looking at this code.

r? `@oli-obk`

This works for most of its call sites. This is nice, because `emit` very
much makes sense as a consuming operation -- indeed,
`DiagnosticBuilderState` exists to ensure no diagnostic is emitted
twice, but it uses runtime checks.

For the small number of call sites where a consuming emit doesn't work,
the commit adds `DiagnosticBuilder::emit_without_consuming`. (This will
be removed in subsequent commits.)

Likewise, `emit_unless` becomes consuming. And `delay_as_bug` becomes
consuming, while `delay_as_bug_without_consuming` is added (which will
also be removed in subsequent commits.)

All this requires significant changes to `DiagnosticBuilder`'s chaining
methods. Currently `DiagnosticBuilder` method chaining uses a
non-consuming `&mut self -> &mut Self` style, which allows chaining to
be used when the chain ends in `emit()`, like so:
```
    struct_err(msg).span(span).emit();
```
But it doesn't work when producing a `DiagnosticBuilder` value,
requiring this:
```
    let mut err = self.struct_err(msg);
    err.span(span);
    err
```
This style of chaining won't work with consuming `emit` though. For
that, we need to use to a `self -> Self` style. That also would allow
`DiagnosticBuilder` production to be chained, e.g.:
```
    self.struct_err(msg).span(span)
```
However, removing the `&mut self -> &mut Self` style would require that
individual modifications of a `DiagnosticBuilder` go from this:
```
    err.span(span);
```
to this:
```
    err = err.span(span);
```
There are *many* such places. I have a high tolerance for tedious
refactorings, but even I gave up after a long time trying to convert
them all.

Instead, this commit has it both ways: the existing `&mut self -> Self`
chaining methods are kept, and new `self -> Self` chaining methods are
added, all of which have a `_mv` suffix (short for "move"). Changes to
the existing `forward!` macro lets this happen with very little
additional boilerplate code. I chose to add the suffix to the new
chaining methods rather than the existing ones, because the number of
changes required is much smaller that way.

This doubled chainging is a bit clumsy, but I think it is worthwhile
because it allows a *lot* of good things to subsequently happen. In this
commit, there are many `mut` qualifiers removed in places where
diagnostics are emitted without being modified. In subsequent commits:
- chaining can be used more, making the code more concise;
- more use of chaining also permits the removal of redundant diagnostic
  APIs like `struct_err_with_code`, which can be replaced easily with
  `struct_err` + `code_mv`;
- `emit_without_diagnostic` can be removed, which simplifies a lot of
  machinery, removing the need for `DiagnosticBuilderState`.

`is_force_warn` is only possible for diagnostics with `Level::Warning`,
but it is currently stored in `Diagnostic::code`, which every diagnostic
has.

This commit:
- removes the boolean `DiagnosticId::Lint::is_force_warn` field;
- adds a `ForceWarning` variant to `Level`.

Benefits:
- The common `Level::Warning` case now has no arguments, replacing
  lots of `Warning(None)` occurrences.
- `rustc_session::lint::Level` and `rustc_errors::Level` are more
  similar, both having `ForceWarning` and `Warning`.

One consequence is that errors returned by
`maybe_new_parser_from_source_str` now must be consumed, so a bunch of
places that previously ignored those errors now cancel them. (Most of
them explicitly dropped the errors before. I guess that was to indicate
"we are explicitly ignoring these", though I'm not 100% sure.)

…a macro arg in rustfmt

All the other `emit`/`emit_diagnostic` methods were recently made
consuming (e.g. #119606), but this one wasn't. But it makes sense to.

Much of this is straightforward, and lots of `clone` calls are avoided.
There are a couple of tricky bits.
- `Emitter::primary_span_formatted` no longer takes a `Diagnostic` and
  returns a pair. Instead it takes the two fields from `Diagnostic` that
  it used (`span` and `suggestions`) as `&mut`, and modifies them. This
  is necessary to avoid the cloning of `diag.children` in two emitters.
- `from_errors_diagnostic` is rearranged so various uses of `diag` occur
  before the consuming `emit_diagnostic` call.

…artwright

Format `async` trait bounds in rustfmt

r? `@ytmimi` or `@calebcartwright`

This PR opts to do formatting in the rust-lang/rust tree because otherwise we'd have to wait until a full sync, and rustfmt is currently totally removing the `async` keyword.

cc rust-lang#6070

This makes it more like `hir::TyKind::Err`, and avoids a
`span_delayed_bug` call in `LoweringContext::lower_ty_direct`.

It also requires adding `ast::TyKind::Dummy`, now that
`ast::TyKind::Err` can't be used for that purpose in the absence of an
error emission.

There are a couple of cases that aren't as neat as I would have liked,
marked with `FIXME` comments.

Subdiagnostics don't need to be lazily translated, they can always be
eagerly translated. Eager translation is slightly more complex as we need
to have a `DiagCtxt` available to perform the translation, which involves
slightly more threading of that context.

This slight increase in complexity should enable later simplifications -
like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages
into the diagnostic structs rather than having them in separate files
(working on that was what led to this change).

Signed-off-by: David Wood <david@davidtw.co>

…ercote

errors: only eagerly translate subdiagnostics

Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context.

This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change).

r? ```@nnethercote```

Commit 72b172b in #121206 changed things so that
`emit_stashed_diagnostics` is only called from `run_compiler`. But
rustfmt doesn't use `run_compiler`, so it needs to call
`emit_stashed_diagnostics` itself to avoid an abort in
`DiagCtxtInner::drop` when stashed diagnostics occur.

Fixes #121450.

Implement RFC 3373: Avoid non-local definitions in functions

This PR implements [RFC 3373: Avoid non-local definitions in functions](rust-lang/rust#120363).

This call was added to `parse_crate_mod` in #121487, to fix a case where
a stashed diagnostic wasn't emitted. But there is another path where a
stashed diagnostic might fail to be emitted if there's a parse error, if
the `build` call in `parse_crate_inner` fails before `parse_crate_mod`
is reached.

So this commit moves the `emit_stashed_diagnostic` call outwards, from
`parse_crate_mod` to `format_project`, just after the
`Parser::parse_crate` call. This should be far out enough to catch any
parsing errors.

Fixes #121517.

Add `ErrorGuaranteed` to `ast::ExprKind::Err`

See #119967 for context
```
      \
       \
          _~^~^~_
      \) /  o o  \ (/
        '_   -   _'
        / '-----' \
```

r? fmease

Move `emit_stashed_diagnostic` call in rustfmt.

This call was added to `parse_crate_mod` in #121487, to fix a case where a stashed diagnostic wasn't emitted. But there is another path where a stashed diagnostic might fail to be emitted if there's a parse error, if the `build` call in `parse_crate_inner` fails before `parse_crate_mod` is reached.

So this commit moves the `emit_stashed_diagnostic` call outwards, from `parse_crate_mod` to `format_project`, just after the `Parser::parse_crate` call. This should be far out enough to catch any parsing errors.

Fixes #121517.

r? `@oli-obk`
cc `@ytmimi`

Rollup of 6 pull requests

Successful merges:

 - #121389 (llvm-wrapper: fix few warnings)
 - #121493 (By changing some attributes to only_local, reducing encoding attributes in the crate metadate.)
 - #121615 (Move `emit_stashed_diagnostic` call in rustfmt.)
 - #121617 (Actually use the right closure kind when checking async Fn goals)
 - #121628 (Do not const prop unions)
 - #121629 (fix some references to no-longer-existing ReprOptions.layout_seed)

r? `@ghost`
`@rustbot` modify labels: rollup

I started by changing it to `DiagData`, but that didn't feel right.
`DiagInner` felt much better.

Much better!

Note that this involves renaming (and updating the value of)
`DIAGNOSTIC_BUILDER` in clippy.

I removed it in #121206 because I thought thought it wasn't necessary.
But then I had to add an `emit_stashed_diagnostics` call elsewhere in
rustfmt to avoid the assertion failure (which took two attempts to get
right, #121487 and #121615), and now there's an assertion failure in
clippy as well (rust-lang/rust-clippy#12364).

So this commit just reinstates the call in `DiagCtxtInner::drop`. It
also reverts the rustfmt changes from #121487 and #121615, though it
keeps the tests added for those PRs.

Because it's now the only constructor.

Because `HumanEmitter::new` is enough, in conjunction with the (renamed)
`stderr_destination` function.

Emitter cleanups

Some cleanups I made when reading emitter code. In particular, `HumanEmitter` and `JsonEmitter` have gone from three constructors to one.

r? `@oli-obk`

…n-ty-aliases, r=compiler-errors

Detect empty leading where clauses on type aliases

1. commit: refactor the AST of type alias where clauses
   * I could no longer bear the look of `.0.1` and `.1.0`
   * Arguably moving `split` out of `TyAlias` into a substruct might not make that much sense from a semantic standpoint since it reprs an index into `TyAlias.predicates` but it's alright and it cleans up the usage sites of `TyAlias`
2. commit: fix an oversight: An empty leading where clause is still a leading where clause
   * semantically reject empty leading where clauses on lazy type aliases
     * e.g., on `#![feature(lazy_type_alias)] type X where = ();`
   * make empty leading where clauses on assoc types trigger lint `deprecated_where_clause_location`
     * e.g., `impl Trait for () { type X where = (); }`

It doesn't need a `Parser` and a `ParseSess`, because the former
contains the latter.

Existing names for values of this type are `sess`, `parse_sess`,
`parse_session`, and `ps`. `sess` is particularly annoying because
that's also used for `Session` values, which are often co-located, and
it can be difficult to know which type a value named `sess` refers to.
(That annoyance is the main motivation for this change.) `psess` is nice
and short, which is good for a name used this much.

The commit also renames some `parse_sess_created` values as
`psess_created`.

Signed-off-by: David Wood <david@davidtw.co>

Currently it only checks calls to functions marked with
`#[rustc_lint_diagnostics]`. This commit changes it to check calls to
any function with an `impl Into<{D,Subd}iagMessage>` parameter. This
greatly improves its coverage and doesn't rely on people remembering to
add `#[rustc_lint_diagnostics]`.

The commit also adds `#[allow(rustc::untranslatable_diagnostic)`]
attributes to places that need it that are caught by the improved lint.
These places that might be easy to convert to translatable diagnostics.

Finally, it also:
- Expands and corrects some comments.
- Does some minor formatting improvements.
- Adds missing `DecorateLint` cases to
  `tests/ui-fulldeps/internal-lints/diagnostics.rs`.

…c-lint, r=davidtwco

Rework `untranslatable_diagnostic` lint

Currently it only checks calls to functions marked with `#[rustc_lint_diagnostics]`. This PR changes it to check calls to any function with an `impl Into<{D,Subd}iagnosticMessage>` parameter. This greatly improves its coverage and doesn't rely on people remembering to add `#[rustc_lint_diagnostics]`. It also lets us add `#[rustc_lint_diagnostics]` to a number of functions that don't have an `impl Into<{D,Subd}iagnosticMessage>`, such as `Diag::span`.

r? ``@davidtwco``

This change is primarily meant to allow rustfmt to ignore all
diagnostics when using the `SilentEmitter`. Back in PR 121301 the
`SilentEmitter` was shared between rustc and rustfmt. This changed
rustfmt's behavior from ignoring all diagnostic to emitting fatal
diagnostics.

These changes allow rustfmt to maintain it's previous behaviour when
using the SilentEmitter, while allowing rustc code to still emit fatal
diagnostics.

Stop using `box PAT` syntax for deref patterns, as it's misleading and
also causes their semantics being tangled up.

Experimental feature postfix match

This has a basic experimental implementation for the RFC postfix match (rust-lang/rfcs#3295, #121618). [Liaison is](https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Postfix.20Match.20Liaison/near/423301844) ```@scottmcm``` with the lang team's [experimental feature gate process](https://github.com/rust-lang/lang-team/blob/master/src/how_to/experiment.md).

This feature has had an RFC for a while, and there has been discussion on it for a while. It would probably be valuable to see it out in the field rather than continue discussing it. This feature also allows to see how popular postfix expressions like this are for the postfix macros RFC, as those will take more time to implement.

It is entirely implemented in the parser, so it should be relatively easy to remove if needed.

This PR is split in to 5 commits to ease review.

1. The implementation of the feature & gating.
2. Add a MatchKind field, fix uses, fix pretty.
3. Basic rustfmt impl, as rustfmt crashes upon seeing this syntax without a fix.
4. Add new MatchSource to HIR for Clippy & other HIR consumers

…c, r=davidtwco

conditionally ignore fatal diagnostic in the SilentEmitter

This change is primarily meant to allow rustfmt to ignore all diagnostics when using the `SilentEmitter`. Back in #121301 the `SilentEmitter` was shared between rustc and rustfmt. This changed rustfmt's behavior from ignoring all diagnostic to emitting fatal diagnostics, which lead to rust-lang#6109.

These changes allow rustfmt to maintain its previous behaviour when using the `SilentEmitter`, while allowing rustc code to still emit fatal diagnostics.

Cleanup: Rename `ModSep` to `PathSep`

`::` is usually referred to as the *path separator* (citation needed).

The existing name `ModSep` for *module separator* is a bit misleading since it in fact separates the segments of arbitrary path segments, not only ones resolving to modules. Let me just give a shout-out to associated items (`T::Assoc`, `<Ty as Trait>::function`) and enum variants (`Option::None`).

Motivation: Reduce friction for new contributors, prevent potential confusion.

cc `@petrochenkov`
r? nnethercote or compiler

Implement syntax for `impl Trait` to specify its captures explicitly (`feature(precise_capturing)`)

Implements `impl use<'a, 'b, T, U> Sized` syntax that allows users to explicitly list the captured parameters for an opaque, rather than inferring it from the opaque's bounds (or capturing *all* lifetimes under 2024-edition capture rules). This allows us to exclude some implicit captures, so this syntax may be used as a migration strategy for changes due to #117587.

We represent this list of captured params as `PreciseCapturingArg` in AST and HIR, resolving them between `rustc_resolve` and `resolve_bound_vars`. Later on, we validate that the opaques only capture the parameters in this list.

We artificially limit the feature to *require* mentioning all type and const parameters, since we don't currently have support for non-lifetime bivariant generics. This can be relaxed in the future.

We also may need to limit this to require naming *all* lifetime parameters for RPITIT, since GATs have no variance. I have to investigate this. This can also be relaxed in the future.

r? `@oli-obk`

Tracking issue:

- rust-lang/rust#123432

…dtwco

Disallow ambiguous attributes on expressions

This implements the suggestion in [#15701](rust-lang/rust#15701 (comment)) to disallow ambiguous outer attributes on expressions. This should resolve one of the concerns blocking the stabilization of `stmt_expr_attributes`.

And suggest adding the `#[coroutine]` to the closure

The functionality of all three crates is now available in the standard library.

Now in rust-lang#6154

…r=oli-obk

Add StaticForeignItem and use it on ForeignItemKind

This is in preparation for unsafe extern blocks that adds a safe variant for functions inside extern blocks.

r? `@oli-obk`
cc `@compiler-errors`

Remove braces when fixing a nested use tree into a single item

[Back in 2019](rust-lang/rust#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.

```rust
reuse prefix::{a, b, c}
```

It's a zero-value wrapper of `Parser::new`.

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.)

The `Input::File` and `Input::Text` cases should be very similar.
However, currently the `Input::File` case uses `catch_unwind` because,
until recently (#125815) there was a fallible version of
`new_parser_from_source_str` but only an infallible version of
`new_parser_from_file`. This difference wasn't fundamental, just an
overlooked gap in the API of `rustc_parse`.

Both of those operations are now fallible, so the `Input::File` and
`Input::Text` cases can made more similar, with no need for
`catch_unwind`. This also lets us simplify an `Option<Vec<Diag>>` to
`Vec<Diag>`.

Unsafe extern blocks

This implements RFC 3484.

Tracking issue #123743 and RFC rust-lang/rfcs#3484

This is better reviewed commit by commit.

…, r=davidtwco"

This reverts commit 57dad1d75e562ff73051c1c43b07eaf65c7dbd74, reversing
changes made to 36316df9fe6c3e246153fe6e78967643cf08c148.

…tly-2024-06-13

We need to allow `StyleEditionDefault` because it will be used to
implement `style_edition`, but that work is currently ongoing.

fixes compilation issues with the `generic-simd` feature

Can't run `cargo test --all` for `error-chain` anymore. The tests don't
compile because of `#[deny(invalid_doc_attributes)]`. Here's  the error
message:

```
error: this attribute can only be applied at the crate level
   --> tests/tests.rs:508:7
    |
508 | #[doc(test)]
    |       ^^^^
    |
    = note: read <https://doc.rust-lang.org/nightly/rustdoc/the-doc-attribute.html#at-the-crate-level> for more information
    = note: `#[deny(invalid_doc_attributes)]` on by default
help: to apply to the crate, use an inner attribute
    |
508 | #![doc(test)]
    |  +
```

The syntax changed from `expr: ty` -> `builtin # type_ascribe(expr, ty)`
For now, rustfmt will just emit the contents of the span.

Our diff-check job was failing in part due to removing `unsafe` from any
`#[unsafe(attributes)]`. To prevent that I added a quick implementation
for this.

Also formats unforamatted files in the crate.