In order to mitigate the Stale Data Read for xAPIC vulnerability completely, reading userspace from an SGX enclave must be aligned and in 8-bytes chunks.

References:

 - https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00657.html
 - https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/stale-data-read-from-xapic.html

…ebank

Parser will not suggest invalid expression when use public

Fixes rust-lang#100165

…on, r=cuviper

Mitigate stale data reads on SGX platform

Intel disclosed the Stale Data Read vulnerability yesterday. In order to mitigate this issue completely, reading userspace from an SGX enclave must be aligned and in 8-bytes chunks. This PR implements this mitigation

References:
 - https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00657.html
 - https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/stale-data-read-from-xapic.html

cc: `@jethrogb`

…er-errors

suggest `once_cell::Lazy` for non-const statics

Addresses rust-lang#100410

Some questions:
 - removing the `if` seems to include too many cases (e.g. calls to non-const functions inside a `const fn`), but this code excludes the following case:
```rust
const FOO: Foo = non_const_fn();
```
Should we suggest `once_cell` in this case as well?
 - The original issue mentions suggesting `AtomicI32` instead of `Mutex<i32>`, should this PR address that as well?

…=davidtwco

Migrate "invalid variable declaration" errors to SessionDiagnostic

After seeing the great blog post on Inside Rust, I decided to try my hand at this. Just one diagnostic for now to get used to the workflow and to check if this is the way to do it or if there are any problems.

…enkov

Add `rustc --print rustc-path`

Related:

- rust-lang/cargo#10986
- rust-lang/rustup#3035

Goal:

Like the original rust-lang/rustup#2958, the goal is to enable `cargo` to call `rustc` directly, rather than through the `rustup` shim.

Solution:

`cargo` asks `rustc` to tell it what executable to run. Sometime early in compilation, `cargo` will run `$(RUSTC_WRAPPER) $(RUSTC ?: rustc) --print rustc-path`[^1]. Further calls to `rustc` to do execution will use the resolved printed executable path rather than continuing to call the "input `rustc` path," which will allow it to bypass the `rustup` shim.

The cargo side is rust-lang/cargo#10998.

[^1]: This can potentially be combined with other `--print`s, as well!

This is a tiny patch, so I've implemented it as insta-stable; this will need signoff probably from both the compiler and cargo teams. I'm working on the cargo side of the patch currently, but wanted to get this up ASAP.

cc `@davidlattimore` `@bjorn3` `@rust-lang/cargo` `@rust-lang/compiler` (sorry for the big ping list 😅)

…bol-diagnostic, r=compiler-errors

Migrate typeck's `used` expected symbol diagnostic to `SessionDiagnostic`

r? `@davidtwco`

…errors

Add the diagnostic translation lints to crates that don't emit them

Some of these have a note saying that they should build on a stable compiler, does that mean they shouldn't get these lints? Or can we cfg them out on those?

…-session-diagnostic, r=davidtwco

Migrate ast lowering to session diagnostic

I migrated the whole rustc_ast_lowering crate to session diagnostic *except* the for the use of `span_fatal` at /compiler/rustc_ast_lowering/src/expr.rs#L1268 because `#[fatal(...)]` is not yet supported (see rust-lang#100694).