-Znext-solver: adapt overflow rules to avoid breakage
Do not erase overflow constraints if they are from equating the impl header when normalizing[^1].
This should be the minimal change to not break crates depending on the old project behavior of "apply impl constraints while only lazily evaluating any nested goals".
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/70, see https://hackmd.io/ATf4hN0NRY-w2LIVgeFsVg for the reasoning behind this.
Only keeping constraints on overflow for `normalize-to` goals as that's the only thing needed for backcompat. It also allows us to not track the origin of root obligations. The issue with root goals would be something like the following:
```rust
trait Foo {}
trait Bar {}
trait FooBar {}
impl<T: Foo + Bar> FooBar for T {}
// These two should behave the same, rn we can drop constraints for both,
// but if we don't drop `Misc` goals we would only drop the constraints for
// `FooBar` unless we track origins of root obligations.
fn func1<T: Foo + Bar>() {}
fn func2<T: FooBaz>() {}
```
[^1]: mostly, the actual rules are slightly different
r? ``@compiler-errors``
rustc_codegen_ssa: Don't drop `IncorrectCguReuseType` , make `rustc_expected_cgu_reuse` attr work
In [100753], `IncorrectCguReuseType` accidentally stopped being emitted by removing `diag.span_err(...)`. Begin emitting it again rather than just blindly dropping it, and adjust tests accordingly.
We assume that there are no bugs and that the currently actual CGU reuse is correct. If there are bugs, they will be discovered and fixed eventually, and the tests will then be updated.
[100753]: 706452eba7 (diff-048389738ddcbe0f9765291a29db1fed9a5f03693d4781cfb5aaa97ffb3c7f84)Closes#118972
Add check for possible CStr literals in pre-2021
Fixes [#118654](https://github.com/rust-lang/rust/issues/118654)
Adds information to errors caused by possible CStr literals in pre-2021.
The lexer separates `c"str"` into two tokens if the edition is less than 2021, which later causes an error when parsing. This error now has a more helpful message that directs them to information about editions. However, the user might also have written `c "str"` in a later edition, so to not confuse people who _are_ using a recent edition, I also added a note about whitespace.
We could probably figure out exactly which scenario has been encountered by examining spans and editions, but I figured it would be better not to overcomplicate the creation of the error too much.
This is my first code PR and I tried to follow existing conventions as much as possible, but I probably missed something, so let me know!
The old code used a heuristic to detect async functions and adjust their
coverage spans to produce better output. But there's no need to resort to a
heuristic when we can just check whether the current function is actually an
`async fn`.
Fix arm64e-apple-ios target
- [x] [Remove legacy `bitcode` defaults](https://github.com/rust-lang/rust/pull/117364)
- [x] Use LLVM features
Now we have warnings such as
```
'+paca' is not a recognized feature for this target (ignoring feature)
'+pacg' is not a recognized feature for this target (ignoring feature)
```
Because we should use LLVM features.
Yeet unnecessary param envs
We don't need to pass in param-envs around in the lexical region resolution code (or in `MatchAgainstFreshVars` in the solver), since it is only used to eval some consts in `structurally_relate_tys` which I removed.
This is in preparation for normalizing the outlives clauses in `ParamEnv` for the new trait solver.
r? lcnr
add more niches to rawvec
Previously RawVec only had a single niche in its `NonNull` pointer. With this change it now has `isize::MAX` niches since half the value-space of the capacity field is never needed, we can't have a capacity larger than isize::MAX.
match lowering: Remove the `make_target_blocks` hack
This hack was introduced 4 years ago in [`a1d0266` (#60730)](a1d0266878) to improve LLVM optimization time, specifically noticed in the `encoding` benchmark. Measurements today indicate it is no longer needed.
r? `@matthewjasper`
Make exhaustiveness usable outside of rustc
With this PR, `rustc_pattern_analysis` compiles on stable (with the `stable` feature)! `rust-analyzer` will be able to use it to provide match-related diagnostics and refactors.
Two questions:
- Should I name the feature `nightly` instead of `rustc` for consistency with other crates? `rustc` makes more sense imo.
- `typed-arena` is an optional dependency but tidy made me add it to the allow-list anyway. Can I avoid that somehow?
r? `@compiler-errors`
In config.toml we use `rust-analyzer-proc-macro-srv` for building `rust-analyzer-proc-macro-srv`,
however, when we attempt to build it from the terminal, this cannot be used because we need to
use the actual path, which is `proc-macro-srv-cli`. Remapping should end this confusion with
improving the development experience.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Subtree sync for rustc_codegen_cranelift
The main highlight is a couple of fixes around size, alignment and field offset computations for foreign and packed unsized types. As well as a fix for the signature of simd_scatter which a recent PR accidentally messed up.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Rollup of 4 pull requests
Successful merges:
- #119087 (Update books)
- #119091 (Use alias-eq in structural normalization)
- #119098 (Adjust the ignore-compare-mode-next-solver for hangs)
- #119100 (Add the function body span to StableMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
The easter egg ICE on `break rust` is weird: it's the one ICE in the
entire compiler that doesn't immediately abort, which makes it
annoyingly inconsistent.
This commit changes it to abort. As part of this, the extra notes are
now appended onto the bug dignostic, rather than being printed as
individual note diagnostics, which changes the output format a bit.
These changes don't interferes with the joke, but they do help with my
ongoing cleanups to error handling.
Add the function body span to StableMIR
We were missing the body span, which differs from the function definition span, since it covers the entire function body.
r? `@ouz-a`
Adjust the ignore-compare-mode-next-solver for hangs
Some new tests hang, some old tests don't hang.
r? lcnr or anyone in `@rust-lang/initiative-trait-system-refactor`
Use alias-eq in structural normalization
We don't need to register repeated normalizes-to goals in a loop in structural normalize, but instead we can piggyback on the fact that alias-eq will already normalize aliases until they are rigid.
This fixesrust-lang/trait-system-refactor-initiative#78.
r? lcnr