The `x86_64-pc-nto-qnx710` and `i586-pc-nto-qnx700` targets have `pc` in
their target triple names, but the vendor was set to the default
`"unknown"`.

- remove a redundant check, because we always emit the "better diagnostic" now
- clean up the comments a bit

As part of the "arbitrary self types v2" project, we are going to
replace the current `Receiver` trait with a new mechanism based on a
new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard.
Options considered included:
* HardCodedReceiver (because it should only be used for things in the
  standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary.
Assuming the new mechanism proceeds to stabilization as intended, the
legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library,
we suspect it may be in use elsehwere, so we're landing this change
separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a
patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
rust-lang/rfcs#3519
rust-lang#44874

r? @wesleywiser

 double_parens
 filter_map_identity
 needless_question_mark
 redundant_guards

…esleywiser

Rename Receiver -> LegacyReceiver

As part of the "arbitrary self types v2" project, we are going to replace the current `Receiver` trait with a new mechanism based on a new, different `Receiver` trait.

This PR renames the old trait to get it out the way. Naming is hard. Options considered included:
* HardCodedReceiver (because it should only be used for things in the standard library, and hence is sort-of hard coded)
* LegacyReceiver
* TargetLessReceiver
* OldReceiver

These are all bad names, but fortunately this will be temporary. Assuming the new mechanism proceeds to stabilization as intended, the legacy trait will be removed altogether.

Although we expect this trait to be used only in the standard library, we suspect it may be in use elsehwere, so we're landing this change separately to identify any surprising breakages.

It's known that this trait is used within the Rust for Linux project; a patch is in progress to remove their dependency.

This is a part of the arbitrary self types v2 project,
rust-lang/rfcs#3519
rust-lang#44874

r? `@wesleywiser`

…wesleywiser

Fix `target_vendor` in QNX Neutrino targets

The `x86_64-pc-nto-qnx710` and `i586-pc-nto-qnx700` targets have `pc` in their target triple names, but the vendor was set to the default `"unknown"`.

CC target maintainers `@flba-eb,` `@gh-tr,` `@jonathanpallant` and `@japaric`

misc cleanups

…ype-err, r=lcnr

Deeply normalize `TypeTrace` when reporting type error in new solver

Normalize the values that come from the `TypeTrace` for various type mismatches.

Side-note: We can't normalize the `TypeError` itself bc it may come from instantiated binders, so it may reference values from within the probe...

r? lcnr

…piler-errors

minor `*dyn` cast cleanup

Small follow-up to rust-lang#130234 to remove a redundant check and clean up comments. No functional changes.

Also, explain why casts cannot drop the principal even though coercions can, and add a test because apparently we didn't have one already.

r? `@WaffleLapkin` or `@compiler-errors`

…mpiler-errors

Prevent overflowing enum cast from ICEing

Fixes rust-lang#131902

…jieyouxu

Don't allow test revisions that conflict with built in cfgs

Fixes rust-lang#128964

Sorry `@heysujal` I started working on this about 1 minute before your comment by complete coincidence 😅

…-errors,Swatinem

coverage: Pass coverage mappings to LLVM as separate structs

Instead of trying to cram *N* different kinds of coverage mapping data into a single list for FFI, pass *N* different lists of simpler structs.

This avoids the need to fill unused fields with dummy values, and avoids the need to tag structs with their underlying kind. It also lets us call the dedicated LLVM constructors for each different mapping type, instead of having to go through the complex general-purpose constructor.

Even though this adds multiple new structs to the FFI surface area, the resulting C++ code is simpler and shorter.

---

I've structured this mostly as a single atomic patch, rather than a series of incremental changes, because that avoids the need to make fiddly fixes to code that is about to be deleted anyway.

…rcote,Mark-Simulacrum

HashStable for rustc_feature::Features: stop hashing compile-time constant

It seems like back in rust-lang@542bc75 this was added as "hash the boolean value of each lang feature", but then in rust-lang@1487bd6 this got split into first hashing a sequence of `bool`s (representing all the features) and then hashing all the feature names... but the list of feature names is a compile-time constant, so it seems entirely unnecessary to hash them?

Cc `@Mark-Simulacrum` who wrote the second of the commits mentioned above.
Cc `@nnethercote`

…ieyouxu

Print safety correctly in extern static items

Fixes rust-lang#132080

r? spastorino or anyone really