Rollup of 5 pull requests
Successful merges:
- #126620 (Actually taint InferCtxt when a fulfillment error is emitted)
- #126649 (Fix `feature = "nightly"` in the new trait solver)
- #126652 (Clarify that anonymous consts still do introduce a new scope)
- #126703 (reword the hint::blackbox non-guarantees)
- #126708 (Minimize `can_begin_literal_maybe_minus` usage)
r? `@ghost`
`@rustbot` modify labels: rollup
Minimize `can_begin_literal_maybe_minus` usage
`can_begin_literal_maybe_minus` is used in a few confusing ways. This PR makes them clearer.
r? ``@spastorino``
reword the hint::blackbox non-guarantees
People were tripped up by the "precludes", interpreting it that this function must not ever be used in cryptographic contexts rather than the std lib merely making zero promises about it being fit-for-purpose.
What remains unchanged is that if someone does try to use it *despite the warnings* then it is on them to pin their compiler versions and verify the assembly of every single binary build they do.
Clarify that anonymous consts still do introduce a new scope
See https://github.com/rust-lang/rust/issues/120363#issuecomment-2177064702
This error message is misleading: it's trying to say that `const _ : () = ...` is a workaround for the lint, but by saying that anonymous constants are treated as being in the parent scope, it makes them appear useless for scope-hiding.
They *are* useful for scope-hiding, they are simply treated as part of the parent scope when it comes to this lint.
Actually taint InferCtxt when a fulfillment error is emitted
And avoid checking the global error counter
fixes#122044fixes#123255fixes#123276fixes#125799
When we have long code skips, we write `...` in the line number gutter.
For suggestions, we were "centering" the `...` with the line, but that was consistent with what we do in every other case.
In #120699 I moved some code dealing with `has_future_breakage` earlier
in `emit_diagnostic`. Issue #126521 identified a case where that
reordering was invalid (leading to an assertion failure) for some `Expect`
diagnostics.
This commit partially undoes the change, by moving the handling of
unstable `Expect` diagnostics earlier again. This makes
`emit_diagnostic` a bit uglier, but is necessary to fix the problem.
Fixes#126521.
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
This makes their intent and expected location clearer. We see some
examples where these comments were not clearly separate from `use`
declarations, which made it hard to understand what the comment is
describing.
We currently use `can_begin_literal_maybe_minus` in a couple of places
where only string literals are allowed. This commit introduces a
more specific function, which makes things clearer. It doesn't change
behaviour because the two functions affected (`is_unsafe_foreign_mod`
and `check_keyword_case`) are always followed by a call to `parse_abi`,
which checks again for a string literal.
It's clearer this way, because the `Interpolated` cases in
`can_begin_const_arg` and `is_pat_range_end_start` are more permissive
than the `Interpolated` cases in `can_begin_literal_maybe_minus`.
Implement `array::repeat`
See rust-lang/libs-team#310.
I've decided to make the function use the input value as last element instead of cloning it to every position and dropping it, and to make this part of the API so that callers are not surprised by this behaviour.
TODO: open a tracking issue. I'll wait for the ACP to be accepted, first.
`@rustbot` label +T-libs-api +T-libs
r? libs
People were tripped up by the "precludes", interpreting it that this function
must not ever be used in cryptographic contexts rather than the std lib merely
making zero promises about it being fit-for-purpose.
What remains unchanged is that if someone does try to use it *despite the warnings*
then it is on them to pin their compiler versions and verify the assembly of every
single binary build they do.
Apparently MIR borrowck cares about at least one of these for checking variance.
In runtime MIR, though, there's no need for them as `PtrToPtr` does the same thing.
(Banning them simplifies passes like GVN that no longer need to handle multiple cast possibilities.)
This removes the ICE codepaths for `f16` and `f128` in Clippy.
`rustc_apfloat` is used as a dependency for the parsing of these types,
since their `FromStr` implementation will not be available in the
standard library for a while.
Rework doc-test attribute documentation example
This PR change the doc-test attribute documentation example to prefer a more neutral example `deny(dead_code)`, instead of `deny(warnings)`, which is less susceptible to breakage across Rust version.
r? ```@GuillaumeGomez```
