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.
Use builtin FFX isolation for Fuchsia test runner
FFX has new builtin support for isolating the daemon's environment. This switches the manual isolation originally written to that new builtin feature.
r? ````@tmandry````
tidy: remove ENTRY_LIMIT maximum checking and set it to 900
Removes checking of `ENTRY_LIMIT` towards an actually reached maximum, and sets it to 900.
The number 900 is safely below github's limit of 1000 entries for a directory.
PRs to move tests can still decrease the sizes of various directories,
but adjusting the limit won't be neccessary any more. In fact, such reduction PRs are a great idea so that no unrelated PR is hitting the limit: ideally there would always be a (manually maintained) safety margin between the actually reached maximum and `ENTRY_LIMIT`, for all directories.
In general, the limit is a bad tool to direct people to put tests into
fitting directories because when those are available, usually the limit
is not hit, while the limit is hit in directories that have a weak
substructure themselves. I got into this situation myself when writing #110694: tests/ui/parser is hitting the limit, but has few directories of its own.
Suggested by ```@petrochenkov``` in https://github.com/rust-lang/rust/pull/110694#discussion_r1177694339.
r? ```@petrochenkov```
Replace generic thread parker with explicit no-op parker
With #98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation.
````@rustbot```` label +T-libs +T-libs-api +A-atomic
r? rust-lang/libs
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!
Implement tuple<->array convertions via `From`
This PR adds the following impls that convert between homogeneous tuples and arrays of the corresponding lengths:
```rust
impl<T> From<[T; 1]> for (T,) { ... }
impl<T> From<[T; 2]> for (T, T) { ... }
/* ... */
impl<T> From<[T; 12]> for (T, T, T, T, T, T, T, T, T, T, T, T) { ... }
impl<T> From<(T,)> for [T; 1] { ... }
impl<T> From<(T, T)> for [T; 2] { ... }
/* ... */
impl<T> From<(T, T, T, T, T, T, T, T, T, T, T, T)> for [T; 12] { ... }
```
IMO these are quite uncontroversial but note that they are, just like any other trait impls, insta-stable.
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).
Rollup of 11 pull requests
Successful merges:
- #107978 (Correctly convert an NT path to a Win32 path in `read_link`)
- #110436 (Support loading version information from xz tarballs)
- #110791 (Implement negative bounds for internal testing purposes)
- #110874 (Adjust obligation cause code for `find_and_report_unsatisfied_index_impl`)
- #110908 (resolve: One more attempt to simplify `module_children`)
- #110943 (interpret: fail more gracefully on uninit unsized locals)
- #111062 (Don't bail out early when checking invalid `repr` attr)
- #111069 (remove pointless `FIXME` in `bootstrap::download`)
- #111086 (Remove `MemEncoder`)
- #111097 (Avoid ICEing miri on layout query cycles)
- #111112 (Add some triagebot notifications for nnethercote.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid ICEing miri on layout query cycles
Miri has special logic for catching panics during interpretation. Raising a fatal error in rustc uses unwinding to abort compilation. Thus miri ends up catching that fatal error and thinks it saw an ICE. While we should probably change that to ignore `Fatal` payloads, I think it's also neat to continue compilation after a layout query cycle 😆
Query cycles now (in addition to reporting an error just like before), return `Err(Cycle)` instead of raising a fatal error. This allows the interpreter to wind down via the regular error paths.
r? `@RalfJung` for a first round, feel free to reroll for the compiler team once the miri side looks good
remove pointless `FIXME` in `bootstrap::download`
The suggestion given by `FIXME` to use `CompilerMetadata` for `download_toolchain` in `bootstrap::download` can result in more confusion. This is because `stamp_key` is not always a date; it can also be a commit hash. Additionally, unlike in `download_beta_toolchain`, in the `download_ci_rustc` function, `version` and `commit` values are calculated separately.
Don't bail out early when checking invalid `repr` attr
Fixes#111051
An invalid repr delays a bug. If there are other invalid attributes on the item, we emit a warning and exit without re-checking the repr here, so no error is emitted and the delayed bug ICEs
Implement negative bounds for internal testing purposes
Implements partial support the `!` negative polarity on trait bounds. This is incomplete, but should allow us to at least be able to play with the feature.
Not even gonna consider them as a public-facing feature, but I'm implementing them because would've been nice to have in UI tests, for example in #110671.
Support loading version information from xz tarballs
This is intended to allow us to move recompression from xz (produced in CI) to gz after an initial manifest run, which produces a list of actually required artifacts. The rest are then deleted, which means that we can avoid recompressing them, saving a bunch of time.
This is essentially untested and more might be needed, will run a patched promote-release against try artifacts from this PR. If we do go ahead with this we'll either need to backport this patch to beta/stable, wait for it to propagate, or temporarily recompress to gzip but not xz tarballs (or similar).
r? `@pietroalbini`
Correctly convert an NT path to a Win32 path in `read_link`
This can be done by simply changing the `\??\` prefix to `\\?\`.
Currently it strips off the prefix which could lead to the wrong path being returned (e.g. if it's not a drive path or if the path contains trailing spaces, etc).
r? libs
