| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
match exhaustiveness: Expand or-patterns as a separate step
To compute exhaustiveness, we must expand or-patterns. Previously, we expanded them at the same time that we pushed patterns into the matrix. This made it harder to track pattern reachability, because the or-pattern itself would never show up in the matrix so we had to recover missing information.
This PR changes that: we no longer expand or-patterns as we push them into the matrix. Instead, if we find an or-pattern in the matrix we expand them in a step very much like the specialization we already do. This simplifies a bunch of things, and should greatly simplify the implementation of https://github.com/rust-lang/rust/issues/127870.
r? `@compiler-errors`
|
|
|
|
|
|
Clean up a few minor refs in `format!` macro, as it has a performance cost. Apparently the compiler is unable to inline `format!("{}", &variable)`, and does a run-time double-reference instead (format macro already does one level referencing). Inlining format args prevents accidental `&` misuse.
|
|
|
|
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
|
|
This section of code depends on `rustc_apfloat` rather than our internal
types, so this is one potential ICE that we should be able to melt now.
This also fixes some missing range and match handling in `rustc_middle`.
|
|
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
|
|
We already do this for a number of crates, e.g. `rustc_middle`,
`rustc_span`, `rustc_metadata`, `rustc_span`, `rustc_errors`.
For the ones we don't, in many cases the attributes are a mess.
- There is no consistency about order of attribute kinds (e.g.
`allow`/`deny`/`feature`).
- Within attribute kind groups (e.g. the `feature` attributes),
sometimes the order is alphabetical, and sometimes there is no
particular order.
- Sometimes the attributes of a particular kind aren't even grouped
all together, e.g. there might be a `feature`, then an `allow`, then
another `feature`.
This commit extends the existing sorting to all compiler crates,
increasing consistency. If any new attribute line is added there is now
only one place it can go -- no need for arbitrary decisions.
Exceptions:
- `rustc_log`, `rustc_next_trait_solver` and `rustc_type_ir_macros`,
because they have no crate attributes.
- `rustc_codegen_gcc`, because it's quasi-external to rustc (e.g. it's
ignored in `rustfmt.toml`).
|
|
|
|
|
|
|
|
* instead simply set the primary message inside the lint decorator functions
* it used to be this way before [#]101986 which introduced `msg` to prevent
good path delayed bugs (which no longer exist) from firing under certain
circumstances when lints were suppressed / silenced
* this is no longer necessary for various reasons I presume
* it shaves off complexity and makes further changes easier to implement
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=compiler-errors
pattern analysis: Require enum indices to be contiguous
We had a cfg-hack to allow rust-analyzer to use non-contiguous indices for its enum variants. Unfortunately this no longer works if r-a uses the in-tree version of the crate.
This PR removes the hack, and on the r-a side we'll have to use contiguous indices but that's not too hard.
r? `@compiler-errors`
|
|
|
|
Only change is https://github.com/davidbarsky/tracing-tree/pull/76
dedupes tracing-log
dupes nu-ansi-term
|
|
|
|
pattern analysis: add a custom test harness
There are two features of the pattern analysis code that are hard to test: the newly-added pattern complexity limit, and the computation of arm intersections. This PR adds some crate-specific tests for that, including an unmaintainable but pretty macro to help construct patterns.
r? `````@compiler-errors`````
|
|
Co-authored-by: Deadbeef <ent3rm4n@gmail.com>
|
|
|
|
|
|
|
|
never patterns: suggest `!` patterns on non-exhaustive matches
When a match is non-exhaustive we now suggest never patterns whenever it makes sense.
r? ``@compiler-errors``
|
|
pattern analysis: remove `MaybeInfiniteInt::JustAfterMax`
It was inherited from before half-open ranges, but it doesn't pull its weight anymore. We lose a tiny bit of diagnostic precision as can be seen in the test. I'm generally in favor of half-open ranges over explicit `x..=MAX` ranges anyway.
|
|
It was inherited from before half-open ranges, but it doesn't pull its
weight anymore. We lose a tiny bit of diagnostic precision.
|
|
|
|
|
|
The old name came from a time where I wanted to reuse it for
differentiating wildcards from bindings. I don't plan to do this
anymore.
|
|
|
|
|
|
|
|
|
|
|
|
Right now this is just `self.fields.len()` but that'll change in the
next commit. `arity` will be useful for the `Debug` impl.
|
|
To match `derive(LintDiagnostic)`.
|
|
To match `derive(Subdiagnostic)`.
Also rename `add_to_diagnostic{,_with}` as `add_to_diag{,_with}`.
|
|
|
|
|
|
pattern analysis: abort on arity mismatch
This is one more PR replacing panics by `Err()` aborts. I recently audited all the `unwrap()` calls, but I had forgotten about array accesses. (Again [discovered by rust-analyzer](https://github.com/rust-lang/rust-analyzer/issues/16746)).
r? ```@compiler-errors```
|
|
|
|
As this can cause panics on array accesses later.
|
|
recursion in pattern matching
|
