check for non-defining uses of RPIT
This PR requires defining uses of RPIT and the async functions return type to use unique generic parameters as type and const arguments, (mostly) fixing #111935. This changes the following snippet to an error (it compiled since 1.62):
```rust
fn foo<T>() -> impl Sized {
let _: () = foo::<u8>(); //~ ERROR non-defining use of `impl Sized`
}
```
Since 1.62 we only checked that the generic arguments of opaque types are unique parameters for TAIT and ignored RPITs, so this PR changes the behavior here to be consistent.
For defining uses which do not have unique params as arguments it is unclear how the hidden type should map to the generic params of the opaque. In the following snippet, should the hidden type of `foo<T>::opaque` be `T` or `u32`.
```rust
fn foo<T>() -> impl Sized {
let _: u32 = foo::<u32>();
foo::<T>()
}
```
There are no crater regressions caused by this change.
---
The same issue exists for lifetime arguments which is not fixed by this PR, currently resulting in an ICE in mir borrowck (I wasn't able to get an example which didn't ICE, it might be possible):
```rust
fn foo<'a: 'a>() -> impl Sized {
let _: &'static () = foo::<'static>();
//~^ ICE opaque type with non-universal region substs
foo::<'a>()
}
```
Fixing this for lifetimes as well is blocked on https://github.com/rust-lang/rust/issues/113916. Due to this issue, functions returning an RPIT with lifetime parameters equal in the region constraint graph would always result in an error, resulting in breakage found via crater: https://github.com/rust-lang/rust/pull/112842#issuecomment-1610057887
```rust
trait Trait<'a, 'b> {}
impl Trait<'_, '_> for () {}
struct Type<'a>(&'a ());
impl<'a> Type<'a> {
// `'b == 'a`
fn do_stuff<'b: 'a>(&'b self) -> impl Trait<'a, 'b> {
// This fails as long there is something in the body
// which adds the outlives constraints to the constraint graph.
//
// This is the case for nested closures.
(|| ())()
}
}
```
Select obligations before processing wf obligation in `compare_method_predicate_entailment`
We need to select obligations before processing the WF obligation for the `IMPLIED_BOUNDS_ENTAILMENT` lint, since it skips over type variables.
Fixes#114783
r? `@jackh726`
TAITs do not constrain generic params
Fixes#108425
Not sure if I should rework those two failing tests. I guess `tests/ui/type-alias-impl-trait/coherence.rs` could just have the type parameter removed from it? IDK what `tests/ui/type-alias-impl-trait/coherence_generalization.rs` is even testing, though.
r? `@aliemjay`
cc `@lcnr` `@oli-obk` (when he's back from 🌴)
Rollup of 5 pull requests
Successful merges:
- #94667 (Add `Iterator::map_windows`)
- #114069 (Allow using external builds of the compiler-rt profile lib)
- #114354 (coverage: Store BCB counter info externally, not directly in the BCB graph)
- #114625 (CI: use smaller machines in PR runs)
- #114777 (Migrate GUI colors test to original CSS color format)
r? `@ghost`
`@rustbot` modify labels: rollup
* remove `impl Provider for Error`
* rename `Demand` to `Request`
* update docstrings to focus on the conceptual API provided by `Request`
* move `core::any::{request_ref, request_value}` functions into `core::error`
* move `core::any::tag`, `core::any::Request`, an `core::any::TaggedOption` into `core::error`
* replace `provide_any` feature name w/ `error_generic_member_access`
* move `core::error::request_{ref,value} tests into core::tests::error module
* update unit and doc tests
CI: use smaller machines in PR runs
mingw-check job-linux-16c -> job-linux-4c
~job-linux-4c 20 min in auto job
~job-linux-16c 13 min in pr job
with current pr regressed to almost 21 min, it's ok.
mingw-check-tidy job-linux-16c -> job-linux-4c small enough, so reduce to minimal
~ job-linux-16c 3 min
with current pr regressed to almost 5 min, it's ok.
x86_64-gnu-tools job-linux-16c this is top job by time in PR, so don't touch it
~ job-linux-8c 1.30 hour in auto job
~ job-linux-16c 1 hour in pr job (affected by #114613, actual time ~ 30 min)
x86_64-gnu-llvm-15 job-linux-16c don't change too
~ job-linux-8c 1.30 hour in auto job
~ job-linux-16c 30 min in pr job
Noticed while working on https://github.com/rust-lang/rust/pull/114621, so current time affected by always rebuilded docker images (but pr images always rebuilded before too, so nvm)
coverage: Store BCB counter info externally, not directly in the BCB graph
When deciding how to instrument the underlying MIR for coverage, the `InstrumentCoverage` pass builds a simplified “Basic Counter Block” graph, and then allocates coverage counters/expressions to various nodes/edges in the BCB graph as necessary. Those counters/expressions are then injected into the function's MIR.
The awkward thing here is that the code for doing this needs `&mut` access to the graph, in order to associate coverage info with individual nodes, even though it isn't making any structural changes to the graph itself. That makes it harder to understand and modify the instrumentation code.
In addition, the graph alone can't hold all the information that is needed. There ends up being an extra vector of “intermediate expressions” that needs to be passed around separately anyway.
---
This PR simplifies things by instead storing all of that temporary coverage information in a number of side-tables inside `CoverageCounters`.
This makes it easier to see all of the information produced by the make-counters step, and how it is used by the inject-into-mir step.
---
Looking at the combined changes is possible, but I recommend reviewing the commits individually, because the big changes are mostly independent of each other (despite being conceptually related).
Allow using external builds of the compiler-rt profile lib
This changes the bootstrap config `target.*.profiler` from a plain bool
to also allow a string, which will be used as a path to the pre-built
profiling runtime for that target. Then `profiler_builtins/build.rs`
reads that in a `LLVM_PROFILER_RT_LIB` environment variable.
Add `Iterator::map_windows`
Tracking issue: #87155.
This is inherited from the old PR #82413.
Unlike #82413, this PR implements the `MapWindows` to be lazy: only when pulling from the outer iterator, `.next()` of the inner iterator will be called.
## Implementaion Steps
- [x] Implement `MapWindows` to keep the iterators' [*Laziness*](https://doc.rust-lang.org/std/iter/index.html#laziness) contract.
- [x] Fix the known bug of memory access error.
- [ ] Full specialization of iterator-related traits for `MapWindows`.
- [x] `Iterator::size_hint`,
- [x] ~`Iterator::count`~,
- [x] `ExactSizeIterator` (when `I: ExactSizeIterator`),
- [x] ~`TrustedLen` (when `I: TrustedLen`)~,
- [x] `FusedIterator`,
- [x] ~`Iterator::advance_by`~,
- [x] ~`Iterator::nth`~,
- [ ] ...
- [ ] More tests and docs.
## Unresolved Questions:
- [ ] Is there any more iterator-related traits should be specialized?
- [ ] Is the double-space buffer worth?
- [ ] Should there be `rmap_windows` or something else?
- [ ] Taking GAT for consideration, should the mapper function be `FnMut(&[I::Item; N]) -> R` or something like `FnMut(ArrayView<'_, I::Item, N>) -> R`? Where `ArrayView` is mentioned in https://github.com/rust-lang/generic-associated-types-initiative/issues/2.
- It can save memory, only the same size as the array window is needed,
- It is more efficient, which requires less data copies,
- It is possibly compatible with the GATified version of `LendingIterator::windows`.
- But it prevents the array pattern matching like `iter.map_windows(|_arr: [_; N]| ())`, unless we extend the array pattern to allow matching the `ArrayView`.
copy the correct version of LLVM into the stage0 sysroot
In some cases(see https://github.com/rust-lang/rust/issues/109314), when the stage0
compiler relies on more recent version of LLVM than the beta compiler, it may not
be able to locate the correct LLVM in the sysroot. This situation typically occurs
when we upgrade LLVM version while the beta compiler continues to use an older version.
Fixes#109314
Extract a create_wrapper_function for use in allocator shim writing
This deduplicates some logic and makes it easier to follow what wrappers are produced. In the future it may allow moving the code to determine which wrappers to create to cg_ssa.
All of them are not exported from rustc_interface and used only during
global_ctxt(). Inlining them makes it easier to follow the order of
queries and slightly reduces line count.
Also consider `mem::transmute` with the `invalid_reference_casting` lint
This PR extend the `invalid_reference_casting` lint with regard to the `std::mem::transmute` function.
```
error: casting `&T` to `&mut T` is undefined behavior, even if the reference is unused, consider instead using an `UnsafeCell`
--> $DIR/reference_casting.rs:27:16
|
LL | let _num = &mut *std::mem::transmute::<_, *mut i32>(&num);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
*I encourage anyone reviewing this PR to do so [without whitespaces](https://github.blog/2011-10-21-github-secrets/#whitespace).*
rustc: Move `features` from `Session` to `GlobalCtxt`
Removes one more piece of mutable state.
Follow up to #114622.
The rule I used for passing feature in function signatures:
- if a crate already depends on `rustc_middle`, then `Session` is replaced with `TyCtxt`
- otherwise session and features are passed as a pair `sess: &Session, features: &Features`
The code in `rustc_lint` is ultimately used for implementing a trait from `rustc_expand`, so it also doesn't use tcx despite the dependency on `rustc_middle`.
Update cargo
21 commits in d78bbf4bde3c6b95caca7512f537c6f9721426ff..7e9de3f4ec3708f500bec142317895b96131e47c
2023-08-03 12:58:25 +0000 to 2023-08-13 00:47:32 +0000
- feat: remove `--keep-going` from `cargo test/bench` (rust-lang/cargo#12478)
- chore: window-sys should be a platform-specific dependency (rust-lang/cargo#12483)
- docs: make the env var source of rerun-if-env-changed clearer (rust-lang/cargo#12482)
- doc: note the backward compatible `.cargo/credential` file exists (rust-lang/cargo#12479)
- Fix elided lifetime in associated const (rust-lang/cargo#12475)
- prompt the use of `--nocapture` flag if `cargo test` process is terminated via a signal. (rust-lang/cargo#12463)
- cargo-credential: reset stdin & stdout to the Console (rust-lang/cargo#12469)
- Fix cargo remove incorrectly removing used patches (rust-lang/cargo#12454)
- chore(gh): Expand update window (rust-lang/cargo#12466)
- Fix panic when enabling http.debug for certain strings (rust-lang/cargo#12468)
- fix(cli): Make `--help` easier to browse (rust-lang/cargo#11905)
- fix: preserve jobserver file descriptors on rustc invocation to get `TargetInfo` (rust-lang/cargo#12447)
- refactor: migrate to `tracing` (rust-lang/cargo#12458)
- docs: add example for cargo-credential (rust-lang/cargo#12461)
- Bail out an error when using cargo:: in custom build script (rust-lang/cargo#12332)
- Fix printing multiple warning messages for unused fields in [registries] table (rust-lang/cargo#12439)
- Update windows dependencies (rust-lang/cargo#12453)
- Rustfmt a let-else statement (rust-lang/cargo#12451)
- Add allow(internal_features) (rust-lang/cargo#12450)
- Update pretty_env_logger to 0.5 (rust-lang/cargo#12445)
- Remove build metadata from libgit2-sys dependency (rust-lang/cargo#12444)
r? `@ghost`
normalize in `trait_ref_is_knowable` in new solver
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/51
Alternatively we could avoid normalizing the self type and do this at the end of the `assemble_candidates_via_self_ty` stack by splitting candidates into:
- applicable without normalizing self type
- applicable for aliases, even if they can be normalized
- applicable for stuff which cannot get normalized further
I don't think this would have any significant benefits and it also seems non-trivial to avoid normalizing only the self type in `trait_ref_is_knowable`.
r? `@compiler-errors`
Storing coverage counter information in `CoverageCounters` has a few advantages
over storing it directly inside BCB graph nodes:
- The graph doesn't need to be mutable when making the counters, making it
easier to see that the graph itself is not modified during this step.
- All of the counter data is clearly visible in one place.
- It becomes possible to use a representation that doesn't correspond 1:1 to
graph nodes, e.g. storing all the edge counters in a single hashmap instead of
several.
remove builtin `Copy` and `Clone` impl for float and int infer
it's only change is whether `{integer}: Copy` is ambiguous, this has the following properties
- these goals get proven earlier, potentially resulting in slightly better perf
- it causes inconsistent behavior and ICE if there do not exist impls for all integers, causing issues when using `#[no_core]`
- it means `Clone` has user-facing differences from other traits from `core` with the new solver because it can potentially guide inference there
- it's just very sus™ to have a builtin impl which applies during type inference but not afterwards
CI: fix Docker layer caching
As reported by `@klensy` on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/docker.20images.20always.20rebuilded), Github Actions have recently updated their Docker version from 20.x to 23.x, which enabled the BuildKit build backend by default.
This broke our way of performing Docker layer caching on CI, which immediately made all non-PR CI builds (including try builds) ~1 hour longer (Docker caching didn't work on PR builds before, so it wasn't affected). The moment this started happening can be seen [here](https://github.com/rust-lang-ci/rust/actions?page=2&query=branch%3Aauto+is%3Asuccess).
The problem is with the following command:
```
docker history -q rust-ci | \
grep -v missing | \
xargs docker save | \
gzip | \
$upload
```
which returns the intermediate layers as `<missing>`, if BuildKit is enabled. This was investigated by `@klensy` in https://github.com/rust-lang/rust/pull/114621. Thanks for that!
I will continue experimenting with how we can enable the cache with BuildKit in https://github.com/rust-lang/rust/pull/114762, but for the time being, I think that we should just hotfix this.
This PR reverts the build backend back to the old one, which fixes the caching. However, we also have to bust the cache of all Dockerfiles, otherwise caching would only start kicking in for them the next time they are updated (or the next time GH updates their docker version). Because when the Docker version was updated the last time, the Dockerfiles were cached on S3 with basically an empty cache, and unless we bust it, even after reverting to the old build engine, the CI script would just download the empty cache and rebuild the Dockerfile from scratch, thus nullifying our fix.
r? `@Mark-Simulacrum`
