| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 3 pull requests
Successful merges:
- #106601 (Suggest `;` after bare `match` expression E0308)
- #116975 (Move `invalid-llvm-passes` test to `invalid-compile-flags` folder)
- #117019 (fix spans for removing `.await` on `for` expressions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix spans for removing `.await` on `for` expressions
We need to use a span with the outer syntax context of a desugared `for` expression to join it with the `.await` span.
fixes https://github.com/rust-lang/rust/issues/117014
|
|
Move `invalid-llvm-passes` test to `invalid-compile-flags` folder
Nowadays there is an `invalid-compile-flags` folder, thus move this one there.
|
|
Suggest `;` after bare `match` expression E0308
Fix #72634.
|
|
|
|
Lint `non_exhaustive_omitted_patterns` by columns
This is a rework of the `non_exhaustive_omitted_patterns` lint to make it more consistent. The intent of the lint is to help consumers of `non_exhaustive` enums ensure they stay up-to-date with all upstream variants. This rewrite fixes two cases we didn't handle well before:
First, because of details of exhaustiveness checking, the following wouldn't lint `Enum::C` as missing:
```rust
match Some(x) {
Some(Enum::A) => {}
Some(Enum::B) => {}
_ => {}
}
```
Second, because of the fundamental workings of exhaustiveness checking, the following would treat the `true` and `false` cases separately and thus lint about missing variants:
```rust
match (true, x) {
(true, Enum::A) => {}
(true, Enum::B) => {}
(false, Enum::C) => {}
_ => {}
}
```
Moreover, it would correctly not lint in the case where the pair is flipped, because of asymmetry in how exhaustiveness checking proceeds.
A drawback is that it no longer makes sense to set the lint level per-arm. This will silently break the lint for current users of it (but it's behind a feature gate so that's ok).
The new approach is now independent of the exhaustiveness algorithm; it's a separate pass that looks at patterns column by column. This is another of the motivations for this: I'm glad to move it out of the algorithm, it was akward there.
This PR is almost identical to https://github.com/rust-lang/rust/pull/111651. cc `@eholk` who reviewed it at the time. Compared to then, I'm more confident this is the right approach.
|
|
Rollup of 8 pull requests
Successful merges:
- #114521 (std: freebsd build update.)
- #116911 (Suggest relaxing implicit `type Assoc: Sized;` bound)
- #116917 (coverage: Simplify the injection of coverage statements)
- #116961 (Typo suggestion to change bindings with leading underscore)
- #116964 (Add stable Instance::body() and RustcInternal trait)
- #116974 (coverage: Fix inconsistent handling of function signature spans)
- #116990 (Mention `into_iter` on borrow errors suggestions when appropriate)
- #116995 (Point at assoc fn definition on type param divergence)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Point at assoc fn definition on type param divergence
When the number of type parameters in the associated function of an impl and its trait differ, we now *always* point at the trait one, even if it comes from a foreign crate. When it is local, we point at the specific params, when it is foreign, we point at the whole associated item.
Fix #69944.
|
|
Mention `into_iter` on borrow errors suggestions when appropriate
If we encounter a borrow error on `vec![1, 2, 3].iter()`, suggest `into_iter`.
Fix #68445.
|
|
coverage: Fix inconsistent handling of function signature spans
While doing some more cleanup of `spans`, I noticed a strange inconsistency in how function signatures are handled. Normally the function signature span is treated as though it were executable as part of the start of the function, but in some cases the signature span disappears entirely from coverage, for no obvious reason.
This is caused by the fact that spans created by `CoverageSpan::for_fn_sig` don't add the span to their `merged_spans` field (unlike normal statement/terminator spans). In cases where the span-processing code looks at those merged spans, it thinks the signature span is no longer visible and deletes it.
Adding the signature span to `merged_spans` resolves the inconsistency.
(Prior to #116409 this wouldn't have been possible, because there was no case in the old `CoverageStatement` enum representing a signature. Now that `merged_spans` is just a list of spans, that's no longer an obstacle.)
|
|
Add stable Instance::body() and RustcInternal trait
The `Instance::body()` returns a monomorphized body.
For that, we had to implement visitor that monomorphize types and constants. We are also introducing the RustcInternal trait that will allow us to convert back from Stable to Internal.
Note that this trait is not yet visible for our users as it depends on Tables. We should probably add a new trait that can be exposed.
The tests here are very simple, and I'm planning on creating more exhaustive tests in the project-mir repo. But I was hoping to get some feedback here first.
r? ```@oli-obk```
|
|
Typo suggestion to change bindings with leading underscore
When encountering a binding that isn't found but has a typo suggestion for a binding with a leading underscore, suggest changing the binding definition instead of the use place.
Fix #60164.
|
|
coverage: Simplify the injection of coverage statements
This is a follow-up to #116046 that I left out of that PR because I didn't want to make it any larger.
After the various changes we've made to how coverage data is stored and transferred, the old code structure for injecting coverage statements into MIR is built around a lot of constraints that don't exist any more. We can simplify it by replacing it with a handful of loops over the BCB node/edge counters and the BCB spans.
---
`@rustbot` label +A-code-coverage
|
|
Suggest relaxing implicit `type Assoc: Sized;` bound
Fix #85378.
|
|
std: freebsd build update.
since freebsd 11 had been removed, minimum is now 12.
|
|
Miri subtree update
r? `@ghost`
|
|
|
|
Automatic Rustup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When the number of type parameters in the associated function of an impl
and its trait differ, we now *always* point at the trait one, even if it
comes from a foreign crate. When it is local, we point at the specific
params, when it is foreign, we point at the whole associated item.
Fix #69944.
|
|
rename Generator to Coroutine
implements https://github.com/rust-lang/compiler-team/issues/682
While I did an automated replacement, I went through all changes manually to avoid renaming things like "id generators", "code generator", ...
I renamed files where that was necessary due to the contents referring to the crate name itself (mir opt, codegen or debuginfo tests), or required by tidy (feature gate docs)
* [x] rename various remaining abbreviated references to generators.
* [x] rename files
* [x] rename folders
* [x] add renamed feature: `generators`, ...
r? `@ghost`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Restructure `rustc_type_ir` a bit
1. Split `sty` into new `ty_kind`/`region_kind`/`const_kind` modules, so that when we uplift more kinds (e.g. `PredicateKind`, `ClauseKind`, and `ExistentialPredicate`), they can live in their own simple-to-understand files.
2. Split up the `structural_impls` module, which is a kitchen sink of random impls -- move `TypeFoldable` and `TypeVisitable` impls into existing `fold` and `visit` modules, respectively.
3. Move the `DebugWithInfcx` trait and blanket impls into a new `debug` module, and `TypeFlags` definition into a new `flags` module.
5. Move `Interner` trait into a new `interner` module. I expect this file to get a lot larger as we make the interner more powerful for the trait solver refactor.
r? `@ghost` for now, will assign once #116946 lands
|
|
If we encounter a borrow error on `vec![1, 2, 3].iter()`, suggest
`into_iter`.
Fix #68445.
|
|
When encountering a binding that isn't found but has a typo suggestion
for a binding with a leading underscore, suggest changing the binding
definition instead of the use place.
Fix #60164.
|
|
|
|
|
|
|
|
Fix typo in atomic docs
Maybe rustdoc or tidy should lint hanging backticks like this.
|
|
since freebsd 11 had been removed, minimum is now 12.
|
|
Move where doc comment meant as comment check
The new place makes more sense and covers more cases beyond individual statements.
```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found doc comment `//!foo
--> $DIR/doc-comment-in-stmt.rs:25:22
|
LL | let y = x.max(1) //!foo
| ^^^^^^ expected one of `.`, `;`, `?`, `else`, or an operator
|
help: add a space before `!` to write a regular comment
|
LL | let y = x.max(1) // !foo
| +
```
Fix #65329.
|
|
Nowadays there is an `invalid-compile-flags` folder, thus move this
one there.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
