try to downgrade Arc -> Lrc -> Rc -> no-Rc in few places
Expecting this be not slower on non-parallel compiler and probably faster on parallel (checked that this PR builds on it).
check array type of repeat exprs is wf
Fixes#111091
Also makes sure that we actually renumber regions in the length of repeat exprs which we previously weren't doing and would cause ICEs in `adt_const_params` + `generic_const_exprs` from attempting to prove the wf goals when the length was an unevaluated constant with `'erased` in the `ty` field of `Const`
The duplicate errors are caused by the fact that `const_arg_to_const`/`array_len_to_const` in `FnCtxt` adds a `WellFormed` goal for the created `Const` which is also checked by the added `WellFormed(array_ty)`. I don't want to change this to just emit a `T: Sized` goal for the element type since that would ignore `ConstArgHasType` wf requirements and generally uncomfortable with the idea of trying to sync up `wf::obligations` for arrays and the code in hir typeck for repeat exprs.
r? `@compiler-errors`
correctly recurse when expanding anon consts
recursing with `super_fold_with` is wrong in case `bac` is itself normalizable, the test that was supposed to test for this being wrong did not actually test for this in reality because of the usage of `{ (N) }` instead of `{{ N }}`. The former resulting in a simple `ConstKind::Param` instead of `ConstKind::Unevaluated`. Tbh generally this test seems very brittle and it will be a lot easier to test once we have normalization of assoc consts since then we can just test that `T::ASSOC` normalizes to some `U::OTHER` which normalizes to some third thing.
r? `@compiler-errors`
Don't suffix `RibKind` variants
This PR
- Removes `use RibKind::*`
- Renames `RibKind::{SomethingRibKind => Something}`
It seems unnecessary to have "RibKind" in the end of all variants, if we can just use it as a normal enum. Additionally previously it was weird that `MacroDefinition` is the only unsuffixed variant.
Encode def span for foreign return-position `impl Trait` in trait
Fixes#111031, yet another def-span encoding issue :/
Includes a smaller repro than the issue, but I can confirm it ICEs:
```
query stack during panic:
#0 [def_span] looking up span for `rpitit::Foo::bar::{opaque#0}`
#1 [object_safety_violations] determining object safety of trait `rpitit::Foo`
#2 [check_is_object_safe] checking if trait `rpitit::Foo` is object safe
#3 [typeck] type-checking `main`
#4 [used_trait_imports] finding used_trait_imports `main`
#5 [analysis] running analysis passes on this crate
```
Luckily since this only affects nightly, this desn't need to be backported.
Explicitly reject negative and reservation drop impls
Fixes#110858
It doesn't really make sense for a type to have a `!Drop` impl. Or at least, I don't want us to implicitly assign a meaning to it by the way the compiler *currently* handles it (incompletely), and rather I would like to see a PR (or an RFC...) assign a meaning to `!Drop` if we actually wanted one for it.
`MemEncoder` was recently removed, leaving `FileEncoder` as the only
encoder. So this prefix is no longer needed, and `write_leb128!` matches
the existing `read_leb128!`.
In #110927 the encode/decode methods for `i8`, `char`, `bool`, and `str`
were made inherent. This commit removes some unnecessary implementations
of these methods that were missed in that PR.
Add cross-language LLVM CFI support to the Rust compiler
This PR adds cross-language LLVM Control Flow Integrity (CFI) support to the Rust compiler by adding the `-Zsanitizer-cfi-normalize-integers` option to be used with Clang `-fsanitize-cfi-icall-normalize-integers` for normalizing integer types (see https://reviews.llvm.org/D139395).
It provides forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space). For more information about LLVM CFI and cross-language LLVM CFI support for the Rust compiler, see design document in the tracking issue #89653.
Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and -Zsanitizer-cfi-normalize-integers, and requires proper (i.e., non-rustc) LTO (i.e., -Clinker-plugin-lto).
Thank you again, ``@bjorn3,`` ``@nikic,`` ``@samitolvanen,`` and the Rust community for all the help!
When we're adding a method to a type DIE, we only want a DW_AT_declaration
there, because LLVM LTO can't unify type definitions when a child DIE is a
full subprogram definition. Now the subprogram definition gets added at the
CU level with a specification link back to the abstract declaration.
This commit adds cross-language LLVM Control Flow Integrity (CFI)
support to the Rust compiler by adding the
`-Zsanitizer-cfi-normalize-integers` option to be used with Clang
`-fsanitize-cfi-icall-normalize-integers` for normalizing integer types
(see https://reviews.llvm.org/D139395).
It provides forward-edge control flow protection for C or C++ and Rust
-compiled code "mixed binaries" (i.e., for when C or C++ and Rust
-compiled code share the same virtual address space). For more
information about LLVM CFI and cross-language LLVM CFI support for the
Rust compiler, see design document in the tracking issue #89653.
Cross-language LLVM CFI can be enabled with -Zsanitizer=cfi and
-Zsanitizer-cfi-normalize-integers, and requires proper (i.e.,
non-rustc) LTO (i.e., -Clinker-plugin-lto).
