…cause of the bound that binds the parameter's type

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.

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

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.

Actually taint InferCtxt when a fulfillment error is emitted

And avoid checking the global error counter

fixes rust-lang#122044
fixes rust-lang#123255
fixes rust-lang#123276
fixes rust-lang#125799

Fix `feature = "nightly"` in the new trait solver

r? lcnr

…orn3,Urgau

Clarify that anonymous consts still do introduce a new scope

See rust-lang#120363 (comment)

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.

…scottmcm

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.

…eral_maybe_minus, r=compiler-errors

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``