| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Error when RPITITs' hidden types capture more lifetimes than their trait definitions
This implements a stricter set of captures rules for RPITITs. They now may only capture:
1. Lifetimes from the impl header (both the self type and any trait substs -- we may want to restrict just to the self type's lifetimes, but the PR makes that easy to do, too)
2. Lifetimes mentioned by the `impl Trait` in the trait method's definition.
Namely, they may not mention lifetimes from the method (early or late) that are not mentioned in the `impl Trait`.
cc #105258 which I think was trying to do this too, though I'm not super familiar with what exactly differs from that or why that one was broken.
cc #112194 (doesn't fix this issue per se, because it's still an open question, but I think this is objectively better than the status quo, and gets us closer to resolving that issue.)
Technically is a fix for the ICE in #108580, but it turns that issue into an error now. We can decide separately whether or not nested RPITITs should capture lifetimes from their parents.
r? ``@oli-obk``
|
|
r=compiler-errors
Better messages for next on a iterator inside for loops
Fixes #102972
|
|
fix(resolve): skip assertion judgment when NonModule is dummy
Fixes #85992
## Why #85992 panic
During `resolve_imports`, the `path_res` of the import `issue_85992_extern_2::Outcome` is pointing to `external::issue_85992_extern_2` instead of `crate::issue_85992_extern_2`. As a result `import.imported_module.set` had been executed.
Attached 1: the state of `early_resolve_ident_in_lexical_scope` during the `resolve_imports` for `use issue_85992_extern_2::Outcome` is as follows:
|iter in `visit_scopes` | `scope` | `result.binding` |
| - | - | - |
| init | - | - |
| 0 | `CrateRoot` | Err(Determined) |
| 1 | `ExternPrelude` | pointing to the `issue_85992_extern_2`(external) |
However, during finalization for `issue_85992_extern_2::Outcome`, the `innermost_result` was pointed to `crate::issue_85992_extern_2` and no ambiguity was generated, leading to a panic.
Attached 2: the state of `early_resolve_ident_in_lexical_scope` during the `finalize_import` for `use issue_85992_extern_2::Outcome` is as follows:
|iter in `visit_scopes` | `scope` | `result.binding` | `innermost_result` |
| - | - | - | - |
| init | - | - | `None` |
| 0 | `CrateRoot` | pointing to `use crate::issue_85992_extern_2` **(introdcued by dummy)** | same as `result` but with a `Some` wapper|
| 1 | `ExternPrelude` | pointing to the `issue_85992_extern_2`(external) | smae as above |
## Try to solve
Skip assertion judgment when `NonModule` is dummy
r? `@petrochenkov`
|
|
Test benchmarks with `-Z panic-abort-tests`
During test execution, when a `#[bench]` benchmark is encountered it's executed once to check whether it works. Unfortunately that was not compatible with `-Z panic-abort-tests`: the feature works by spawning a subprocess for each test, which prevents the use of dynamic tests as we cannot pass closures to child processes, and before this PR the conversion from benchmark to test was done by turning benchmarks into dynamic tests whose closures execute the benchmark once.
The approach this PR took was to add two new kinds of `TestFn`s: `StaticBenchAsTestFn` and `DynBenchAsTestFn` (:warning: **this is a breaking change** :warning:). With that change, a `StaticBenchFn` can be converted into a `StaticBenchAsTestFn` without creating dynamic tests, and making it possible to test `#[bench]` functions with `-Z panic-abort-tests`. The subprocess test runner also had to be updated to perform the conversion from benchmark to test when appropriate.
Along with the bug fix, in the first commit I refactored how tests are executed: rather than executing the test function in multiple places across `libtest`, there is now a private `TestFn::into_runnable()` method, which returns either a `RunnableTest` or `RunnableBench`, on which you can call the `run()` method. This simplified the rest of the changes in the PR.
This PR is best reviewed commit-by-commit.
Fixes https://github.com/rust-lang/rust/issues/73509
|
|
|
|
|
|
|
|
Use structured suggestion when telling user about `for<'a>`
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
|
|
Properly implement variances_of for RPITIT GAT
This fixes some of the issues found by crater run in https://github.com/rust-lang/rust/pull/112988#issuecomment-1610019572
r? ``@compiler-errors``
|
|
Encode item bounds for `DefKind::ImplTraitPlaceholder`
This was lost in a refactoring -- `hir::ItemKind::OpaqueTy` doesn't always map to `DefKind::Opaque`, specifically for RPITITs, so the check was migrated subtly wrong, and unfortunately I never had a test for this 🙃
Fixes #113155
r? ``@cjgillot``
|
|
compiler-errors:no-parent-non-lifetime-args-in-apit, r=eholk
Account for late-bound vars from parent arg-position impl trait
We should be reporting an error like we do for late-bound args coming from a parent APIT.
Fixes #113016
|
|
suggest `slice::swap` for `mem::swap(&mut x[0], &mut x[1])` borrowck error
Recently saw someone ask why this code (example slightly modified):
```rs
fn main() {
let mut foo = [1, 2];
std::mem::swap(&mut foo[0], &mut foo[1]);
}
```
triggers this error and how to fix it:
```
error[E0499]: cannot borrow `foo[_]` as mutable more than once at a time
--> src/main.rs:4:33
|
4 | std::mem::swap(&mut foo[0], &mut foo[1]);
| -------------- ----------- ^^^^^^^^^^^ second mutable borrow occurs here
| | |
| | first mutable borrow occurs here
| first borrow later used by call
|
= help: consider using `.split_at_mut(position)` or similar method to obtain two mutable non-overlapping sub-slices
```
The current help message is nice and goes in the right direction, but I think we can do better for this specific instance and suggest `slice::swap`, which makes this compile
|
|
Rollup of 7 pull requests
Successful merges:
- #111322 (Support for native WASM exceptions)
- #112086 (resolve: Remove artificial import ambiguity errors)
- #112234 (refactor `tool_doc!`)
- #112300 (Convert `run-make/coverage-reports` tests to use a custom compiletest mode)
- #112795 (Migrate some rustc_builtin_macros to SessionDiagnostic)
- #113144 (Make the `Elaboratable` trait take clauses)
- #113161 (Fix type privacy lints error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
```
error[E0637]: `&` without an explicit lifetime name cannot be used here
--> $DIR/E0637.rs:13:13
|
LL | T: Into<&u32>,
| ^ explicit lifetime name needed here
|
help: consider introducing a higher-ranked lifetime here
|
LL | T: for<'a> Into<&'a u32>,
| +++++++ ++
```
|
|
Add bidirectional where clauses on RPITIT synthesized GATs
Given the following:
```rust
struct MyStruct<'a, T>(&'a T);
trait MyTrait<'a, T> {
fn my_fn<'b, 'c, 'd, V>(item: &'c String) -> impl Sized + 'a + 'b + 'c where V: 'b, V: 'd;
}
impl<'a, T> MyTrait<'a, T> for MyStruct<'a, T> {
fn my_fn<'b, 'c, 'd, V>(_: &'c String) -> impl Sized + 'a + 'b + 'c
where
V: 'b,
V: 'd,
{
unimplemented!();
}
}
```
We need the desugaring to be:
```rust
trait MyTrait<'a, T> {
type MyFn<'bf, 'df, Vf, 'a2, 'b2, 'c2>: Sized + 'a2 + 'b2 + 'c2 where Vf: 'b2, 'a2: 'a, 'a: 'a2, 'b2: 'bf, 'bf: 'b2;
fn my_fn<'b, 'c, 'd, V>(item: &'c String) -> MyStruct<'a>::MyFn<'b, 'd, V, 'a, 'b, 'c> where V: 'b, V: 'd {
type opaque<'a3, 'b3, 'c3>;
};
}
impl<'a, T> MyIter<'a, T> for MyStruct<'a, T> {
type MyFn<'bf, 'df, Vf, 'a2, 'b2, 'c2> = impl Sized + 'a2 + 'b2 + 'c2 where Vf: b2, 'a2: 'a, 'a: 'a2, 'b2: 'bf, 'bf: 'b2;
fn my_fn<'b, 'c, 'd, V>(_: &'c String) -> MyStruct<'a>::MyFn<'a, 'b, 'c, V> where V: 'b, V: 'd {
type opaque<'a3, 'b3, 'c3>;
unimplemented!();
}
}
```
This PR adds the where clauses for the `MyFn` generated GATs.
This is a draft with a very ugly solution so we can make comments over concrete code.
r? `@compiler-errors`
|
|
|
|
|
|
|
|
compiler-errors:normalize-opaques-with-late-bound-vars-again, r=jackh726
Normalize opaques with late-bound vars again
We have a hack in the compiler where if an opaque has escaping late-bound vars, we skip revealing it even though we *could* reveal it from a technical perspective. First of all, this is weird, since we really should be revealing all opaques in `Reveal::All` mode. Second of all, it causes subtle bugs (linked below).
I attempted to fix this in #100980, which was unfortunately reverted due to perf regressions on codebases that used really deeply nested futures in some interesting ways. The worst of which was #103423, which caused the project to hang on build. Another one was #104842, which was just a slow-down, but not a hang. I took some time afterwards to investigate how to rework `normalize_erasing_regions` to take advantage of better caching, but that effort kinda fizzled out (#104133).
However, recently, I was made aware of more bugs whose root cause is not revealing opaques during codegen. That made me want to fix this again -- in the process, interestingly, I took the the minimized example from https://github.com/rust-lang/rust/issues/103423#issuecomment-1292947043, and it doesn't seem to hang any more...
Thinking about this harder, there have been some changes to the way we lower and typecheck async futures that may have reduced the pathologically large number of outlives obligations (see description of #103423) that we were encountering when normalizing opaques with bound vars the last time around:
* #104321 (lower `async { .. }` directly as a generator that implements `Future`, removing the `from_generator` shim)
* #104833 (removing an `identity_future` fn that was wrapping desugared future generators)
... so given that I can see:
* No significant regression on rust perf bot (https://github.com/rust-lang/rust/pull/107620#issuecomment-1600070317)
* No timeouts in crater run I did (https://github.com/rust-lang/rust/pull/107620#issuecomment-1605428952, rechecked failing crates in https://github.com/rust-lang/rust/pull/107620#issuecomment-1605973434)
... and given that this PR:
* Fixes #104601
* Fixes #107557
* Fixes #109464
* Allows us to remove a `DefiningAnchor::Bubble` from codegen (75a8f681837c70051e0200a14f58ae07dbe58e66)
I'm inclined to give this another shot at landing this. Best case, it just works -- worst case, we get more examples to study how we need to improve the compiler to make this work.
r? types
|
|
Fix type privacy lints error message
Type privacy lints diagnostic messages are not related to spans.
r? `@petrochenkov`
|
|
Convert `run-make/coverage-reports` tests to use a custom compiletest mode
I was frustrated by the fact that most of the coverage tests are glued together with makefiles and shell scripts, so I tried my hand at converting most of them over to a newly-implemented `run-coverage` mode/suite in compiletest.
This ~~*mostly*~~ resolves #85009, ~~though I've left a small number of the existing tests as-is because they would require more work to fix/support~~.
---
I had time to go back and add support for the more troublesome tests that I had initially skipped over, so this PR now manages to completely get rid of `run-make/coverage-reports`.
---
The patches are arranged as follows:
- Declare the new mode/suite in bootstrap
- Small changes to compiletest that will be used by the new mode
- Implement the new mode in compiletest
- Migrate most of the tests over
- Add more code to bootstrap and compiletest to support the remaining tests
- Migrate the remaining tests (with some temporary hacks to avoid re-blessing them)
- Remove the temporary hacks and re-bless the migrated tests
- Remove the unused remnants of `run-make/coverage-reports`
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #112946 (Improve cgu naming and ordering)
- #113048 (Fix build on Solaris where fd-lock cannot be used.)
- #113100 (Fix display of long items in search results)
- #113107 (add check for ConstKind::Value(_) to in_operand())
- #113119 (rustdoc: Reduce internal function visibility.)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
don't suggest `move` for borrows that aren't closures
fixes https://github.com/rust-lang/rust/issues/113087
|
|
oli-obk:what_if_an_impl_item_just_doesnt_wanna_be_impld, r=compiler-errors
Test that we require implementing trait items whose bounds don't hold in the current impl
I initially tried to make most of these pass, but that's a big can of worms, so I'm just adding them as tests, considering we have no tests for these things.
|
|
privacy: Type privacy lints fixes and cleanups
See individual commits.
Follow up to https://github.com/rust-lang/rust/pull/111801.
|
|
Make associated type bounds in supertrait position implied
`trait A: B<Assoc: C> {}` should be able to imply both `Self: B` and `<Self as B>::Assoc: C`. Adjust the way that we collect implied predicates to do so.
Fixes #112573
Fixes #112568
|
|
|
|
add check for ConstKind::Value(_) to in_operand()
Added check for valtree value to close #113012 which fixes the issue, although I am not sure if adding the check there is sound or not cc `@oli-obk`
|
|
Fix display of long items in search results
Fixes https://github.com/rust-lang/rust/issues/113060.
You can test the result [here](https://rustdoc.crud.net/imperio/search-result-long-name/lib2/index.html).
To make it a bit better, I also reduced a bit the size of the short documentation from half to 2 fifth of the width.
r? `@notriddle`
|
|
r=notriddle,fmease
Fix invalid HTML DIV tag used in HEAD
Fixes https://github.com/rust-lang/rust/issues/113067.
The issue also nicely explains the whole problem.
r? ``@notriddle``
|
|
r=fee1-dead
add note for non-exhaustive matches with guards
Associated issue: #92197
When a match statement includes guards on every match arm (and is therefore necessarily non-exhaustive), add a note to the error E0004 diagnostic noting this.
|
|
More `ImplSource` nits
Even more clean-ups, I'll put this up in parallel with the `select_in_new_trait_solver` PR.
r? ``@lcnr``
|
|
Implement proposed API for `proc_macro_span`
As proposed in [#54725 (comment)](https://github.com/rust-lang/rust/issues/54725#issuecomment-1546918161). I have omitted the byte-level API as it's already available as [`Span::byte_range`](https://doc.rust-lang.org/nightly/proc_macro/struct.Span.html#method.byte_range).
`@rustbot` label +A-proc-macros
r? `@m-ou-se`
|
|
|
|
Avoid calling queries during query stack printing
This has the side effect, that when Clippy should ICE (during an EarlyPass?) it will fill up the RAM with 2 GB/s and then freezes my Laptop. This is blocking the Clippy sync and might give some people really bad experiences, so this should be merged ASAP.
r? `@cjgillot`
cc `@Zoxc`
I only commented this on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60try_print_query_stack.60.20has.20.60ImplicitCtx.60.20during.20.60EarlyPass.60/near/363926180). I should've left a comment on the PR as well. My bad.
|
|
|
|
|
|
|
|
Validate fluent variable references in tests
Closes #101109
Under `cfg(test)`, the `fluent_messages` macro will emit a list of variables referenced by each message and its attributes. The derive attribute will now emit a `#[test]` that checks that each referenced variable exists in the structure it's applied to.
|
|
|
|
|
|
To make it easier to verify that the output snapshots have been migrated
faithfully, this change adds some temporary helper code that lets us avoid
having to completely re-bless the existing snapshots.
A later change in this PR will then re-bless the tests and remove the temporary
helper code.
|
|
|
|
mir opt + codegen: handle subtyping
fixes #107205
the same issue was caused in multiple places:
- mir opts: both copy and destination propagation
- codegen: assigning operands to locals (which also propagates values)
I changed codegen to always update the type in the operands used for locals which should guard against any new occurrences of this bug going forward. I don't know how to make mir optimizations more resilient here. Hopefully the added tests will be enough to detect any trivially wrong optimizations going forward.
|
