This repr-hint makes a struct/enum hide any niche within from its
surrounding type-construction context.
It is meant (at least initially) as an implementation detail for
resolving issue 68303. We will not stabilize the repr-hint unless
someone finds motivation for doing so.
(So, declaration of `no_niche` feature lives in section of file
where other internal implementation details are grouped, and
deliberately leaves out the tracking issue number.)
incorporated review feedback, and fixed post-rebase.
Towards unified `fn` grammar
Part of https://github.com/rust-lang/rust/pull/68728.
- Syntactically, `fn` items in `extern { ... }` blocks can now have bodies (`fn foo() { ... }` as opposed to `fn foo();`). As above, we use semantic restrictions instead.
- Syntactically, `fn` items in free contexts (directly in a file or a module) can now be without bodies (`fn foo();` as opposed to `fn foo() { ... }`. As above, we use semantic restrictions instead, including for non-ident parameter patterns.
- We move towards unifying the `fn` front matter; this is fully realized in https://github.com/rust-lang/rust/pull/68728.
r? @petrochenkov
Step stage0 to bootstrap from 1.42
This also includes a commit which fixes the rustfmt downloading logic to redownload when the rustfmt channel changes, and bumps rustfmt to a more recent version.
This function has a variable `changed` that is erroneously used for two
related-but-different purpose:
- to detect if the current element has changed;
- to detect if any elements have changed.
As a result, its use for the first purpose is broken, because if any
prior element changed then the code always thinks the current element
has changed. This is only a performance bug, not a correctness bug,
because we frequently end up calling `assign_unpacked` unnecessarily to
overwrite the element with itself.
This commit adds `any_changed` to correctly distinguish between the two
purposes. This is a small perf win for some benchmarks.
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
Remove `rustc_error_codes` deps except in `rustc_driver`
Remove dependencies on `rustc_error_codes` in all crates except for `rustc_driver`.
This has some benefits:
1. Adding a new error code when hacking on the compiler only requires rebuilding at most `rustc_error_codes`, `rustc_driver`, and the reflexive & transitive closure of the crate where the new error code is being added and its reverse dependencies. This improves time-to-UI-tests (TTUT).
2. Adding an error description to an error code only requires rebuilding `rustc_error_codes` and `rustc_driver`. This should substantially improve TTUT.
r? @petrochenkov
cc @rust-lang/wg-diagnostics
