These would incorrectly leave `current` as `None` after a failed attempt
to remove an element (due to the cursor already being at the start/end).

up to now, it had been assumed the stack guard setting default is not
touched in the field but some user might just want to disable it or
increase it. checking it once at runtime should be enough.

LLVM 18 requires the evex512 feature to allow use of zmm registers.
LLVM automatically sets it when using a generic CPU, but not when
`-C target-cpu` is specified. This will result either in backend
legalization crashes, or code unexpectedly using ymm instead of
zmm registers.

For now, make sure that `avx512*` features imply `evex512`. Long
term we'll probably have to deal with the AVX10 mess somehow.

When encountering a verbose/multipart suggestion that has changes
that are only caused by different capitalization of ASCII letters that have
little differenciation, expand the message to highlight that fact (like we
already do for inline suggestions).

The logic to do this was already present, but implemented incorrectly.

`cook_lexer_literal` can emit an error about an invalid int literal but
then return a non-`Err` token. And then `integer_lit` has to account for
this to avoid printing a redundant error message.

This commit changes `cook_lexer_literal` to return `Err` in that case.
Then `integer_lit` doesn't need the special case, and
`LitError::LexerError` can be removed.

This will be helpful for subsequent commits.

And use the result in `cook_common` to decide whether to return an error
token.

This mostly works well, and eliminates a couple of delayed bugs.

One annoying thing is that we should really also add an
`ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's
difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`,
so we have to fake it.

To avoid some unwrapping.

…om-raw, r=m-ou-se

Document requirements for unsized {Rc,Arc}::from_raw

This seems to be implied due to these types supporting operation-less unsized coercions. Taken together with the [established behavior of a wide to thin pointer cast](rust-lang/reference#1451) it would enable unsafe downcasting of these containers.

Note that the term "data pointer" is adopted from rust-lang/rfcs#3559

See also this [internals thread](https://internals.rust-lang.org/t/can-unsafe-smart-pointer-downcasts-be-correct/20229/2).

…, r=m-ou-se

Fix BTreeMap's Cursor::remove_{next,prev}

These would incorrectly leave `current` as `None` after a failed attempt to remove an element (due to the cursor already being at the start/end).

…pages_fbsd, r=m-ou-se

std::thread update freebsd stack guard handling.

up to now, it had been assumed the stack guard setting default is not touched in the field but some user might just want to disable it or increase it. checking it once at runtime should be enough.

Implicitly enable evex512 if avx512 is enabled

LLVM 18 requires the evex512 feature to allow use of zmm registers. LLVM automatically sets it when using a generic CPU, but not when `-C target-cpu` is specified. This will result either in backend legalization crashes, or code unexpectedly using ymm instead of zmm registers.

For now, make sure that `avx512*` features imply `evex512`. Long term we'll probably have to deal with the AVX10 mess somehow.

Fixes rust-lang#121081.

r? `@Amanieu`

…iler-errors

Ignore unsized types when trying to determine the size of the original type

Fixes rust-lang#121074 a regression from rust-lang#118983

…, r=michaelwoerister

Fix msg for verbose suggestions with confusable capitalization

When encountering a verbose/multipart suggestion that has changes that are only caused by different capitalization of ASCII letters that have little differenciation, expand the message to highlight that fact (like we already do for inline suggestions).

The logic to do this was already present, but implemented incorrectly.

…-errors

Continue compilation even if inherent impl checks fail

We should not be hiding errors behind unrelated errors

…ease

Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.

Similar to recent work doing the same for `ExprKind::Err` (rust-lang#120586) and `TyKind::Err` (rust-lang#121109).

r? `@oli-obk`