| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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.
|
|
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.
|
|
Suggest relaxing implicit `type Assoc: Sized;` bound
Fix #85378.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
Add a test showing failing closure signature inference in new solver
Been thinking a bit about how to make this test pass... but we don't actually have any good tests exercising this behavior in the suite.
r? lcnr
|
|
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.
|
|
Fix duplicate labels emitted in `render_multispan_macro_backtrace()`
This PR replaces the `Vec` used to store labels with an `FxIndexSet` in order to eliminate duplicates
Fixes #116836
|
|
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.
|
|
Implement rustc part of RFC 3127 trim-paths
This PR implements (or at least tries to) [RFC 3127 trim-paths](https://github.com/rust-lang/rust/issues/111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes.
`@rustbot` label: +F-trim-paths
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This check is made `needs-unwind`, as the panic=abort case is a strictly
simpler version.
|
|
|
|
|
|
|
|
|
|
|
|
Only check in a single place if a pass is enabled.
Fixes https://github.com/rust-lang/rust/issues/116294
|
|
Add `-Zstack-protector` test for Windows targets
Add variants of the `stack-protector-heuristics-effect.rs` test for 32-bit and 64-bit MSVC Windows and update the original test to run on GNU Windows targets.
I added two tests instead of trying to modify the original because:
- MSVC uses a different function name (`__security_check_cookie` to perform the test rather than doing the test inline and calling `__stack_chk_fail`).
- LLVM's stack protection pass doesn't currently support generating checks for [frames with funclet based EH personality](https://github.com/llvm/llvm-project/blob/37fd3c96b917096d8a550038f6e61cdf0fc4174f/llvm/lib/CodeGen/StackProtector.cpp#L103C1-L109C4).
- 32-bit Windows uses classic EH while 64-bit Windows uses table-based EH which results in slightly different codegen.
[CI run with test passing on {i686,x86_64}-{msvc,mingw}](https://github.com/rust-lang/rust/actions/runs/6275450644/job/17042958375?pr=116037)
|
|
Tweak wording of type errors involving type params
Fix #78206.
|
