use implied bounds when checking opaque types
During opaque type inference, we check for the well-formedness of the hidden type in the opaque type's own environment, not the one of the defining site, which are different in the case of TAIT.
However in the case of associated-type-impl-trait, we don't use implied bounds from the impl header. This caused us to reject the following:
```rust
trait Service<Req> {
type Output;
fn call(req: Req) -> Self::Output;
}
impl<'a, Req> Service<&'a Req> for u8 {
type Output= impl Sized; // we can't prove WF of hidden type `WF(&'a Req)` although it's implied by the impl
//~^ ERROR type parameter Req doesn't live long enough
fn call(req: &'a Req) -> Self::Output {
req
}
}
```
although adding an explicit bound would make it pass:
```diff
- impl<'a, Req> Service<&'a Req> for u8 {
+ impl<'a, Req> Service<&'a Req> for u8 where Req: 'a, {
```
I believe it should pass as we already allow the concrete type to be used:
```diff
impl<'a, Req> Service<&'a Req> for u8 {
- type Output= impl Sized;
+ type Output= &'a Req;
```
Fixes#95922
Builds on #105982
cc ``@lcnr`` (because implied bounds)
r? ``@oli-obk``
Shrink `SelectionError` a lot
`SelectionError` used to be 80 bytes (on 64 bit). That's quite big. Especially because the selection cache contained `Result<_, SelectionError>. The Ok type is only 32 bytes, so the 80 bytes significantly inflate the size of the cache.
Most variants of the `SelectionError` seem to be hard errors, only `Unimplemented` shows up in practice (for cranelift-codegen, it occupies 23.4% of all cache entries). We can just box away the biggest variant, `OutputTypeParameterMismatch`, to get the size down to 16 bytes, well within the size of the Ok type inside the cache.
Use proper impl self type for alias impl in rustdoc
We don't want to use `type_of(type_alias)`, we want to use `type_of(impl)` -- this will give us the self type of the impl *properly substituted* in the case that it's an alias.
Fixes#111420
vec-shrink-panik: update expectations to work on LLVM 17
For some reason, the called function is `cleanup` on LLVM 17 instead of `filter`.
r? `@Amanieu`
Isolate coverage FFI type layouts from their underlying LLVM C++ types
I noticed that several of the types used to send coverage information through FFI are not properly isolated from the layout of their corresponding C++ types in the LLVM API.
This PR adds more explicitly-defined FFI struct/enum types in `CoverageMappingWrapper.cpp`, so that Rust source files in `rustc_codegen_ssa` and `rustc_codegen_llvm` aren't directly exposed to LLVM C++ types.
Fix mishandled `--check-cfg` arguments order
This PR fixes a bug in `--check-cfg` where the order of `--check-cfg=names(a)` and `--check-cfg=values(a,…)` would trip the compiler.
Fixes https://github.com/rust-lang/rust/issues/111291
cc `@taiki-e` `@petrochenkov`
Prevent ICE with broken borrow in closure
r? `@Nilstrieb`
Fixes#108683
This solution isn't ideal, I'm hoping to find a way to continue compilation without ICEing.
Optimize dataflow-const-prop place-tracking infra
Optimization opportunities found while investigating https://github.com/rust-lang/rust/pull/110719
Computing places breadth-first ensures that we create short projections before deep projections, since the former are more likely to be propagated.
The most relevant is the pre-computation of flooded places. Callgrind showed `flood_*` methods and especially `preorder_preinvoke` were especially hot. This PR attempts to pre-compute the set of `ValueIndex` that `preorder_invoke` would visit.
Using this information, we make some `PlaceIndex` inaccessible when they contain no `ValueIndex`, allowing to skip computations for those places.
cc `@jachris` as original author
Include the current Crate name in the measureme output name
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/measureme.20flamegraph.20panics/near/356367013
cc `@andjo403`
Currently, attempting to use `MIRIFLAGS=-Zmiri-measureme=miri cargo miri test` on a crate with multiple test targets (which is very common) will produce a corrupted measureme output file, because the various interpreter processes will stomp each other's output.
This change does not entirely prevent this, but the various test targets seem to always have different crate names, so if nothing else this will make the broken measureme files much harder to encounter by accident, while also making it clear what they are all for.
Don't force include Windows goop when documenting
Why do we need to include all the windows bits on non-windows platforms? Let's try not doing that.
Possible alternative to #111394, if it works.
Switch to `EarlyBinder` for `thir_abstract_const` query
Part of the work to finish https://github.com/rust-lang/rust/issues/105779.
This PR adds `EarlyBinder` to the return type of the `thir_abstract_const` query and removes `bound_abstract_const`.
r? `@compiler-errors`
Fix incorrect implication of transmuting slices
transmute<&[u8]> would be useful and as a beginner it is confusing to see documents casually confuse the types of &[u8] and [u8; SZ]
Encode types in SMIR
The first commit makes sure we can actually store a Ty<'tcx> (with the lifetime) in the thread local and get it back out. The second commit then introduces types.
r? `@spastorino`
Make alias bounds sound in the new solver (take 2)
Make alias bounds sound in the new solver (in a way that does not require coinduction) by only considering them for projection types whose corresponding trait refs come from a param-env candidate.
That is, given `<T as Trait>::Assoc: Bound`, we only *really* need to consider the alias bound if `T: Trait` is satisfied via a param-env candidate. If it's instead satisfied, e.g., via an user provided impl candidate or a , then that impl should have a concrete type to which we could otherwise normalize `<T as Trait>::Assoc`, and that concrete type is then responsible to prove the `Bound` on it.
Similar consideration is given to opaque types, since we only need to consider alias bounds if we're *not* in reveal-all mode, since similarly we'd be able to reveal the opaque types and prove any bounds that way.
This does not remove that hacky "eager projection replacement" logic from object bounds, which are somewhat like alias bounds. But removing this eager normalization behavior (added in #108333) would require full coinduction to be enabled. Compare to #110628, which does remove this object-bound custom logic but requires coinduction to be sound.
r? `@lcnr`
Support linking to rust dylib with --crate-type staticlib
This allows for example dynamically linking libstd, while statically linking the user crate into an executable or C dynamic library. For this two unstable flags (`-Z staticlib-allow-rdylib-deps` and `-Z staticlib-prefer-dynamic`) are introduced. Without the former you get an error. The latter is the equivalent to `-C prefer-dynamic` for the staticlib crate type to indicate that dynamically linking is preferred when both options are available, like for libstd. Care must be taken to ensure that no crate ends up being merged into two distinct staticlibs that are linked together. Doing so will cause a linker error at best and undefined behavior at worst. In addition two distinct staticlibs compiled by different rustc may not be combined under any circumstances due to some rustc private symbols not being mangled.
To successfully link a staticlib, `--print native-static-libs` can be used while compiling to ask rustc for the linker flags necessary when linking the staticlib. This is an existing flag which previously only listed native libraries. It has been extended to list rust dylibs too. Trying to locate libstd yourself to link against it is not supported and may break if for example the libstd of multiple rustc versions are put in the same directory.
For an example on how to use this see the `src/test/run-make-fulldeps/staticlib-dylib-linkage/` test.
Update cargo
10 commits in 569b648b5831ae8a515e90c80843a5287c3304ef..26b73d15a68fb94579f6d3590585ec0e9d81d3d5
2023-05-05 15:49:44 +0000 to 2023-05-09 20:28:03 +0000
- Update the semver-check script to be able to run in any directory. (rust-lang/cargo#12117)
- Semver: Note that it is not a breaking change to make an unsafe function safe (rust-lang/cargo#12116)
- Add more documentation for artifact-dependencies. (rust-lang/cargo#12110)
- changelog: move registry query fixes to the right place (rust-lang/cargo#12086)
- Disallow RUSTUP_TOOLCHAIN in the [env] table. (rust-lang/cargo#12107)
- Disallow RUSTUP_HOME in the [env] table. (rust-lang/cargo#12101)
- Fix redacting tokens in http debug. (rust-lang/cargo#12095)
- Fix self_signed_should_fail for macOS. (rust-lang/cargo#12097)
- Update git2 (rust-lang/cargo#12096)
- do not try an exponential number of package names (rust-lang/cargo#12083)
r? `@ghost`
Implement SSA-based reference propagation
Rust has a tendency to create a lot of short-lived borrows, in particular for method calls. This PR aims to remove those short-lived borrows with a const-propagation dedicated to pointers to local places.
This pass aims to transform the following pattern:
```
_1 = &raw? mut? PLACE;
_3 = *_1;
_4 = &raw? mut? *_1;
```
Into
```
_1 = &raw? mut? PLACE;
_3 = PLACE;
_4 = &raw? mut? PLACE;
```
where `PLACE` is a direct or an indirect place expression.
By removing indirection, this pass should help both dest-prop and const-prop to handle more cases.
This optimization is distinct from const-prop and dataflow const-prop since the borrow-reborrow patterns needs to preserve borrowck invariants, especially the uniqueness property of mutable references.
The pointed-to places are computed using a SSA analysis. We suppose that removable borrows are typically temporaries from autoref, so they are by construction assigned only once, and a SSA analysis is enough to catch them. For each local, we store both where and how it is used, in order to efficiently compute the all-or-nothing property. Thanks to `Derefer`, we only have to track locals, not places in general.
---
There are 3 properties that need to be upheld for this transformation to be legal:
- place constness: `PLACE` must refer to the same memory wherever it appears;
- pointer liveness: we must not introduce dereferences of dangling pointers;
- `&mut` borrow uniqueness.
## Constness
If `PLACE` is an indirect projection, if its of the form `(*LOCAL).PROJECTIONS` where:
- `LOCAL` is SSA;
- all projections in `PROJECTIONS` are constant (no dereference and no indexing).
If `PLACE` is a direct projection of a local, we consider it as constant if:
- the local is always live, or it has a single `StorageLive` that dominates all uses;
- all projections are constant.
# Liveness
When performing a substitution, we must take care not to introduce uses of dangling locals.
Using a dangling borrow is UB. Therefore, we assume that for any use of `*x`, where `x` is a borrow, the pointed-to memory is live.
Limitations:
- occurrences of `*x` in an `&raw mut? *x` are accepted;
- raw pointers are allowed to be dangling.
In those 2 case, we do not substitute anything, to be on the safe side.
**Open question:** we do not differentiate borrows of ZST and non-ZST. The UB rules may be
different depending on the layout. Having a different treatment would effectively prevent this
pass from running on polymorphic MIR, which defeats the purpose of MIR opts.
## Uniqueness
For `&mut` borrows, we also need to preserve the uniqueness property:
we must avoid creating a state where we interleave uses of `*_1` and `_2`.
To do it, we only perform full substitution of mutable borrows:
we replace either all or none of the occurrences of `*_1`.
Some care has to be taken when `_1` is copied in other locals.
```
_1 = &raw? mut? _2;
_3 = *_1;
_4 = _1
_5 = *_4
```
In such cases, fully substituting `_1` means fully substituting all of the copies.
For immutable borrows, we do not need to preserve such uniqueness property,
so we perform all the possible substitutions without removing the `_1 = &_2` statement.
Rollup of 6 pull requests
Successful merges:
- #97320 (Stabilize const_ptr_read)
- #110770 (Limit lifetime of format_args!() with inlined args.)
- #111021 (Move some tests)
- #111215 (Various changes to name resolution of anon consts)
- #111242 (support set `rpath` option for each target independently)
- #111282 (Remove some `assume`s from slice iterators that don't do anything)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Remove some `assume`s from slice iterators that don't do anything
Because the start pointer is iterators is already a `NonNull`, we emit the appropriate `!nonnull` metadata when loading the pointer to tell LLVM that it's non-null.
Probably the best way to see that it's the metadata that's important (and not the `assume`) is to observe that LLVM actually *removes* the `assume` from the optimized IR: <https://rust.godbolt.org/z/KhE6G963n>.
(I also checked that, yes, the if-not-ZST `assume` on `end` is still doing something: it's how there's a `!nonnull` metadata on its load, even though it's an ordinary raw pointer. The codegen test added in this PR fails if the other `assume` is removed.)
support set `rpath` option for each target independently
Currently the `rpath` option is a global config and it's effect on all targets.
But sometimes when developers edit the rustc code and try to release rust toolchains themselves, they may not want to add `rpath` in all targets to avoid dynamically linked shared object library privilege escalation attack.
This PR supports set `rpath` option for each target independently .
Common developers are not aware of the existence of this configuration option and do not affect the existing development process. This configuration option takes effect only after developers explicitly sets .
r? ``@albertlarsan68``
Various changes to name resolution of anon consts
Sorry this PR is kind of all over the place ^^'
Fixes#111012
- Rewrites anon const nameres to all go through `fn resolve_anon_const` explicitly instead of `visit_anon_const` to ensure that we do not accidentally resolve anon consts as if they are allowed to use generics when they aren't. Also means that we dont have bits of code for resolving anon consts that will get out of sync (i.e. legacy const generics and resolving path consts that were parsed as type arguments)
- Renames two of the `LifetimeRibKind`, `AnonConst -> ConcreteAnonConst` and `ConstGeneric -> ConstParamTy`
- Noticed while doing this that under `generic_const_exprs` all lifetimes currently get resolved to errors without any error being emitted which was causing a bunch of tests to pass without their bugs having been fixed, incidentally fixed that in this PR and marked those tests as `// known-bug:`. I'm fine to break those since `generic_const_exprs` is a very unstable incomplete feature and this PR _does_ make generic_const_exprs "less broken" as a whole, also I can't be assed to figure out what the underlying causes of all of them are. This PR reopens#77357#83993
- Changed `generics_of` to stop providing generics and predicates to enum variant discriminant anon consts since those are not allowed to use generic parameters
- Updated the error for non 'static lifetime in const arguments and the error for non 'static lifetime in const param tys to use `derive(Diagnostic)`
I have a vague idea why const-arg-in-const-arg.rs, in-closure.rs and simple.rs have started failing which is unfortunate since these were deliberately made to work, I think lifetime resolution being broken just means this regressed at some point and nobody noticed because the tests were not testing anything :( I'm fine breaking these too for the same reason as the tests for #77357#83993. I couldn't get `// known-bug` to work for these ICEs and just kept getting different stderr between CI and local `--bless` so I just removed them and will create an issue to track re-adding (and fixing) the bugs if this PR lands.
r? `@cjgillot` cc `@compiler-errors`
