This commit replaces the new error that was being emitted in NLL type
check with a call to `report_selection_error` so that the same trait
error as before this PR is emitted.
This commit implements RFC 2203, allowing constants in array repeat
expressions.
Firstly, the check that the array repeat expression implements `Copy` is
removed and re-implemented in `rustc_mir::borrow_check::nll::type_check`
by emitting an error when the MIR contains a `Operand::Move` and the
type does not implement `Copy`.
Next, the `qualify_consts` pass is modified to construct a
`Candidate::Repeat` when it would be correct to promote a array repeat
expression.
Finally, the `promote_consts` pass is modified to promote the candidates
previously identified.
- uses a never-stable core::array::LengthAtMost32 to bound the impls
- includes a custom error message to avoid mentioning LengthAtMost32 too often
- doesn't use macros for the slice implementations to avoid #62433
Rollup of 4 pull requests
Successful merges:
- #61883 (`non_ascii_idents` lint (part of RFC 2457))
- #62042 (Support stability and deprecation checking for all macros)
- #62213 (rustdoc: set cfg(doctest) when collecting doctests)
- #62286 (Check if the archive has already been added to avoid duplicates)
Failed merges:
r? @ghost
Check if the archive has already been added to avoid duplicates
This avoids adding archives multiple times, which results in duplicate
objects in the resulting rlib, leading to symbol collision and link
failures. This could happen when crate contains multiple link attributes
that all reference the same archive.
rustdoc: set cfg(doctest) when collecting doctests
Note: This PR builds on top of https://github.com/rust-lang/rust/pull/61199; only the last commit is specific to this PR.
As discussed in https://github.com/rust-lang/rust/pull/61199, we want the ability to isolate items to only when rustdoc is collecting doctests, but we can't use `cfg(test)` because of libcore's `#![cfg(not(test))]`. This PR proposes a new cfg flag, `cfg(doctest)`, specific to this situation, rather than reusing an existing flag. I've isolated it behind a feature gate so that we can contain the effects to nightly only. (A stable workaround that can be used in lieu of `#[cfg(doctest)]` is `#[cfg(rustdoc)] #[doc(hidden)]`, at least once https://github.com/rust-lang/rust/pull/61351 lands.)
Tracking issue: https://github.com/rust-lang/rust/issues/62210
`non_ascii_idents` lint (part of RFC 2457)
RFC 2457 [declares](121bbeff50/text/2457-non-ascii-idents.md): "A `non_ascii_idents` lint is added to the compiler. This lint is allow by default."
(Part of #55467.)
r? @Manishearth
name the trait in ambiguous-associated-items fully qualified suggestion
We have the trait at this point, so we can name it in the error message, rather than using "Trait" as a (potentially confusing) placeholder.
Thanks to Yuki "@JohnTitor" Okushi for pointing out where to look (in the same file) for a closely related issue for ambiguous associated types (as opposed to items; that was #59225, except that one won't be
quite as easy to resolve, because we actually don't have the trait `DefId` at that point).
r? @petrochenkov
rustbuild: Cleanup global lint settings
Lint settings do not depend on `if let Some(target) = target` in any way, so they are moved out of that clause.
Internal lints now respect `RUSTC_DENY_WARNINGS`.
Crate name treatment is cleaned up a bit.
cc https://github.com/rust-lang/rust/pull/61545 @flip1995
r? @Mark-Simulacrum
First question mark in doctest
We have had `?` for `Result`s in doctests for some time, but so far haven't used them in doctests. With this PR, I want to start the de-`unwrap`ping of doctests – and the discussion on where to do so.
There is one downside, which is that the code can no longer be copied into a plain `main()` method, on the other hand, there should be a workable error if one does this.
