"Crate features" isn't a thing in Rust, but you do need to add this line
to your crate root.

Fixes #28944

Previously, `/**/` was incorrectly regarded as a doc comment because it
starts with `/**` and ends with `*/`. However, this caused an ICE
because some code assumed that the length of a doc comment is at least
5. This commit adds an additional check to `is_block_doc_comment` that
tests the length of the input.

Fixes #28844.

and some unrelated test cleanups

Added tests illustrating when and when not to use the UGEH attribute w.r.t. types in negative position.

Fixes #28839

Sorry I didn’t get this in the last PR (#28864), I hadn’t thought of it.

(It is not *exactly* the text from the RFC, but the only thing it adds
is a call to a no-op function that is just an attempt to make it clear
where the potential for impl specialization comes from.)

One just checks that we are feature-gating the UGEH attribute (as
usual for attributes associated with unstable features).

The other is adapted from the RFC 1238 text, except that it has been
extended somewhat to actually *illustrate* the scenario that we are
trying to prevent, namely observing the state of data, from safe code,
after the destructor for that data has been executed.

This turned up as part of #3170.  When constructing an `undef` value to
return in the error case, we were trying to get the element type of the
Rust-level value being indexed instead of the underlying array; when
indexing a slice, that's not an array and the LLVM assertion failure
reflects this.

The regression test is a lightly altered copy of `const-array-oob.rs`.

also, ensure that callers are checked.

looks like some mix of #18653 and `projection_must_outlive`, but
that needs to be investigated further (crater run?)

By RFC1214:
Before calling a fn, we check that its argument and return types are WF. This check takes place after all higher-ranked lifetimes have been instantiated. Checking the argument types ensures that the implied bounds due to argument types are correct. Checking the return type ensures that the resulting type of the call is WF.

The previous code only checked the trait-ref, which was not enough
in several cases.

As this is a soundness fix, it is a [breaking-change].

Fixes #28609

Fixes #28776

Fixes #27890
Fixes #28099
Fixes #28113

The behavior here isn't really ideal, but we can't really do much better
given the current state of constant evaluation.

Fixes #28670, and probably a bunch of duplicates.

This lint warning was originally intended to help against misuse of the old Rust
`int` and `uint` types in FFI bindings where the Rust `int` was not equal to the
C `int`. This confusion no longer exists (as Rust's types are now `isize` and
`usize`), and as a result the need for this lint has become much less over time.

Additionally, starting with [the RFC for libc][rfc] it's likely that `isize` and
`usize` will be quite common in FFI bindings (e.g. they're the definition of
`size_t` and `ssize_t` on many platforms).

[rfc]: https://github.com/rust-lang/rfcs/pull/1291

This commit disables these lints to instead consider `isize` and `usize` valid
types to have in FFI signatures.

Fixes #28568

different supertraits can suffer from the same object-safety violation,
leading to duplication in the error message. Avoid it.

Fixes #20692

Because of type inference, duplicate obligations exist and cause duplicate
errors. To avoid this, only display the first error for each (predicate,span).

The inclusion of the span is somewhat bikesheddy, but *is* the more
conservative option (it does not remove some instability, as duplicate
obligations are ignored by `duplicate_set` under some inference conditions).

Fixes #28098
cc #21528 (is it a dupe?)

Fixes #28576

This adds a new target property, `target_vendor` which can be used as a
matcher for conditional compilation. The vendor is part of the autoconf
target triple: <arch><sub>-<vendor>-<os>-<env>

The default value for `target_vendor` is "unknown".

Matching against the `target_vendor` with `#[cfg]` is currently feature
gated as `cfg_target_vendor`.

walk_expr includes call to visit_expr for subexpressions.

Closes #28091.

I assume the expected error changed during the development of pull
request #28321 and that wasn't noticed because the test was
accidentally not running.