I added this function in 53481a5

Also change `executables` to true for linux-kernel and windows-uwp-gnu targets

rustc_target: Flip the default for `TargetOptions::executables` to true

This flag is true for most targets and the remaining targets may be mistakes.

…stebank

Fix last `let_chains` blocker

In order to forbid things like `let x = (let y = 1);` or `if let a = 1 && { let x = let y = 1; } {}`, the parser **HAS** to know the context of `let`.

This context thing is not a surprise in the parser because you can see **a lot** of ad hoc fixes mixing parsing logic with validation logic creating code that looks more like spaghetti with tomato sauce.

To make things even greater, a new ad hoc fix was added to only allow `let`s in a valid `let_chains` context by checking the previously processed token. This was the only solution I could think of and believe me, I thought about it for a long time 👍

In the long term, it should be preferable to segregate different responsibilities or create a more robust and cleaner parser framework.

cc rust-lang#94927
cc rust-lang#53667

…-to-floating-point-number, r=compiler-errors

Suggest adding a missing zero to a floating point number

fixes rust-lang#98836

Some more `EarlyBinder` cleanups

First commit has a couple unrelated cleanups, but otherwise each commit is self-explanatory

r? rust-lang/types

use PlaceRef::iter_projections to fix old FIXME

I added this function in 53481a5

…x, r=Dylan-DPC

Put back UI test regex

I just realized I overwrote these two commits in rust-lang#99055 when force pushing to fix the stdout output...

r? `@Dylan-DPC`