Unconditionally register alias-relate in projection goal
Follow-up to #118725, which subtly broke closure signature inference on combinators like `Result::map` which I noticed in syn.
Essentially, instead of using `eq` which will eagerly infer `?1 := <?2 as Trait>::Assoc`, we can directly emit an alias-relate goal, which will stay ambiguous for as long as `?2` is ambiguous.
This also more closely models the conceptual framing that projects-to acts like an alias-relate when solving, and like a normalizes-to when in a param env.
r? lcnr
[rustdoc] Use Map instead of Object for source files and search index
It's cleaner and is also easier to manipulate `Map` rather than `Object` types.
r? `@notriddle`
Add -Zunpretty=stable-mir output test
As strongly suggested here https://github.com/rust-lang/rust/pull/118364#issuecomment-1827974148 this adds output test for `-Zunpretty=stable-mir`, added test shows almost all the functionality of the current printer.
r? `@compiler-errors`
Add inline const and other possible curly brace expressions to expr_trailing_brace
Add tests for `}` before `else` in `let...else` error
Change to explicit cases for expressions with optional values when being checked for trailing braces
Add tests for more complex cases of `}` before `else` in `let..else` statement
Move other possible `}` cases into separate arm and add FIXME for future reference
Stop allowing `rustc::potential_query_instability` on all of
`rustc_mir_build` and instead allow it on a case-by-case basis if it is
safe to do so. In this crate there was no instance of the lint
remaining.
There are a number of fixes here:
* if-unchanged is supposed to be the default for channel=dev, but
actually used different logic. Make sure it is the same.
* If no llvm section was specified at all, different logic was
also used. Go through the standard helper.
* Some more assertions should depend on if_unchanged.
fix --dry-run when the change-id warning is printed
previously:
```
Building bootstrap
Compiling bootstrap v0.0.0 (/home/jyn/src/rust2/src/bootstrap)
Finished dev [unoptimized] target(s) in 4.23s
thread 'main' panicked at src/bin/main.rs:147:17:
fs::write(warned_id_path, latest_change_id.to_string()) failed with No such file or directory (os error 2)
```
fix dynamic size/align computation logic for packed types with dyn trait tail
This logic was never updated to support `packed(N)` where `N > 1`, and it turns out to be wrong for that case.
Fixes https://github.com/rust-lang/rust/issues/80925
`@bjorn3` I have not looked at cranelift; I assume it basically copied the size-of-val logic and hence could use much the same patch.
It's unclear why this is used here. All entries in the third column of
`UNICODE_ARRAY` are covered by `ASCII_ARRAY`, so if the lookup fails
it's a genuine compiler bug. It was added way back in #29837, for no
clear reason.
This commit changes it to `span_bug`, which is more typical.
It's necessary for `derive(Diagnostic)`, but is best avoided elsewhere
because there are clearer alternatives.
This required adding `Handler::struct_almost_fatal`.
cache param env canonicalization
Canonicalize ParamEnv only once and store it. Then whenever we try to canonicalize `ParamEnvAnd<'tcx, T>` we only have to canonicalize `T` and then merge the results.
Prelimiary results show ~3-4% savings in diesel and serde benchmarks.
Best to review commits individually. Some commits have a short description.
Initial implementation had a soundness bug (https://github.com/rust-lang/rust/pull/117749#issuecomment-1840453387) due to cache invalidation:
- When canonicalizing `Ty<'?0>` we first try to resolve region variables in the current InferCtxt which may have a constraint `?0 == 'static`. This means that we register `Ty<'?0> => Canonical<Ty<'static>>` in the cache, which is obviously incorrect in another inference context.
- This is fixed by not doing region resolution when canonicalizing the query *input* (vs. response), which is the only place where ParamEnv is used, and then in a later commit we *statically* guard against any form of inference variable resolution of the cached canonical ParamEnv's.
r? `@ghost`
This doesn't change behavior.
It should prevent unintentional resolution of inference variables
during canonicalization, which previously caused a soundness bug.
See PR description for more.
Enable stack probes on aarch64 for LLVM 18
I tested this on `aarch64-unknown-linux-gnu` with LLVM main (~18).
cc #77071, to be closed once we upgrade our LLVM submodule.
