| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Declare DebruijnIndex via newtype_index macro
Part of #49887
Declare `DebruijnIndex` via the `newtype_index` macro.
|
|
Add existential type definitions
Note: this does not allow creating named existential types, it just desugars `impl Trait` to a less (but still very) hacky version of actual `existential type` items.
r? @nikomatsakis
|
|
|
|
|
|
Use scope tree depths to speed up `nearest_common_ancestor`.
This patch adds depth markings to all entries in the `ScopeTree`'s
`parent_map`. This change increases memory usage somewhat, but permits a
much faster algorithm to be used:
- If one scope has a greater depth than the other, the deeper scope is
moved upward until they are at equal depths.
- Then we move the two scopes upward in lockstep until they match.
This avoids the need to keep track of which scopes have already been
seen, which was the major part of the cost of the old algorithm. It also
reduces the number of child-to-parent moves (which are hash table
lookups) when the scopes start at different levels, because it never
goes past the nearest common ancestor the way the old algorithm did.
Finally, the case where one of the scopes is the root is now handled in
advance, because that is moderately common and lets us skip everything.
This change speeds up runs of several rust-perf benchmarks, the best by
6%.
A selection of the bigger improvements:
```
clap-rs-check
avg: -2.6% min: -6.6% max: 0.0%
syn-check
avg: -2.2% min: -5.0% max: 0.0%
style-servo-check
avg: -2.9%? min: -4.8%? max: 0.0%?
cargo-check
avg: -1.3% min: -2.8% max: 0.0%
sentry-cli-check
avg: -1.0% min: -2.1% max: 0.0%
webrender-check
avg: -0.9% min: -2.0% max: 0.0%
style-servo
avg: -0.9%? min: -1.8%? max: -0.0%?
ripgrep-check
avg: -0.7% min: -1.8% max: 0.1%
clap-rs
avg: -0.9% min: -1.6% max: -0.2%
regex-check
avg: -0.2% min: -1.3% max: 0.1%
syn
avg: -0.6% min: -1.3% max: 0.1%
hyper-check
avg: -0.5% min: -1.1% max: 0.0%
```
The idea came from multiple commenters on my blog and on Reddit. Thank you!
r? @nikomatsakis
|
|
When encountering a named or anonymous sup requirement (for example,
`&'a self`) and a `'static` impl Trait return type, suggest adding the
`'_` lifetime constraing to the return type.
|
|
|
|
This patch adds depth markings to all entries in the `ScopeTree`'s
`parent_map`. This change increases memory usage somewhat, but permits a
much faster algorithm to be used:
- If one scope has a greater depth than the other, the deeper scope is
moved upward until they are at equal depths.
- Then we move the two scopes upward in lockstep until they match.
This avoids the need to keep track of which scopes have already been
seen, which was the major part of the cost of the old algorithm. It also
reduces the number of child-to-parent moves (which are hash table
lookups) when the scopes start at different levels, because it never
goes past the nearest common ancestor the way the old algorithm did.
Finally, the case where one of the scopes is the root is now handled in
advance, because that is moderately common and lets us skip everything.
This change speeds up runs of several rust-perf benchmarks, the best by
6%.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
remove notion of Implicit derefs from mem-cat
`PointerKind` is included in `LoanPath` and hence forms part of the equality check; this led to having two unequal paths that both represent `*x`, depending on whether the `*` was inserted automatically or explicitly. Bad mojo.
Fixes #51117
r? @eddyb
|
|
`PointerKind` is included in `LoanPath` and hence forms part of the
equality check; this led to having two unequal paths that both
represent `*x`, depending on whether the `*` was inserted
automatically or explicitly. Bad mojo. The `note` field, in contrast,
is intended more-or-less primarily for this purpose of adding extra
data.
|
|
nikomatsakis:issue-51008-false-positive-lifetime-must-be-declared, r=cramertj
reset anonymous-lifetime-mode as we enter `()` scopes
Background:
The anonymous lifetime mode is used to prohibit elided lifetimes where
they didn't used to be permitted, and instead require that `'_` be
used. For example:
```rust
impl Trait for Ref<T> { .. }
// ^^^^^^ ERROR: should be `Ref<'_, T>`
```
When we are parsing the parts of the impl header, we enter into an alternate mode called `CreateParameter`. In this mode, we give an error for things like `Ref<T>`, but for elided lifetimes in a reference type like `&T` we make the elided lifetime into an in-band lifetime:
https://github.com/rust-lang/rust/blob/4f99f37b7e213d69a489884f651adfc6d217cef5/src/librustc/hir/lowering.rs#L4017-L4035
This was not intended to change behavior because we only enter into that mode in contexts where elision was not historically permitted. However, the problem is that we fail to reset the mode when we enter into bounds like `Fn(&u32)`, where elision *was* allowed -- the same occurs for fn types like `fn(&u32`). This PR restores the original mode in those contexts.
Fixes #51008
r? @cramertj
|
|
Background:
The anonymous lifetime mode is used to prohibit elided lifetimes where
they didn't used to be permitted, and instead require that `'_` be
used. For example:
```rust
impl Trait for Ref<T> { .. }
// ^^^^^^ ERROR: should be `Ref<'_, T>`
```
When we are parsing the parts of the impl header, we enter into an
alternate mode called `CreateParameter`. In this mode, we give an
error for things like `Ref<T>`, but for elided lifetimes in a
reference type like `&T` we make the elided lifetime into an in-band
lifetime:
https://github.com/rust-lang/rust/blob/4f99f37b7e213d69a489884f651adfc6d217cef5/src/librustc/hir/lowering.rs#L4017-L4035
This was not intended to change behavior because we only enter into
that mode in contexts where elision was not historically
permitted. However, the problem is that we fail to reset the mode when
we enter into bounds like `Fn(&u32)`, where elision *was* allowed --
the same occurs for fn types like `fn(&u32`). This PR restores the
original mode in those contexts.
|
|
|
|
Refactor DebruijnIndex to be 0-based
Fixes #49813
|
|
Co-authored-by: csmoe <35686186+csmoe@users.noreply.github.com>
|
|
Co-authored-by: csmoe <35686186+csmoe@users.noreply.github.com>
|
|
Co-authored-by: csmoe <35686186+csmoe@users.noreply.github.com>
|
|
Michael Woerister pointed out that `hir_to_node_id` (introduced in
August 2017's 28ddd7a4e) supersedes the functionality of
`find_node_for_hir_id` (just a hash lookup compared to that linear
search).
|
|
Changing the `each_binding` utility method to take the `HirId` of a
binding pattern rather than its `NodeId` seems like a modest first step
in support of the `HirId`ification initiative #50928. (The inspiration
for choosing this in particular came from the present author's previous
work on diagnostics issued during liveness analysis, which is the most
greatly affected module in this change.)
|
|
add suggestion applicabilities to librustc and libsyntax
A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means).
r? @Manishearth
cc @killercup @estebank
|
|
|
|
|
|
implement Ord for OutlivesPredicate and other types
It became necessary while implementing https://github.com/rust-lang/rust/pull/50070 to have `Ord` implemented for `OutlivesPredicate`.
This PR implements `Ord` for `OutlivesPredicate` as well as other types needed for the implementation.
|
|
Shrink `LiveNode`.
`Liveness::users` is a vector that is occasionally enormous. For
example, doing a "clean incremental" check build of `inflate`, there is
one instance that represents 5,499 live nodes and 1087 vars, which
requires 5,977,413 entries. At 24 bytes per entry, that is 143MB.
This patch changes LiveNode from a usize to a u32. On 64-bit machines
that halves the size of these entries, significantly reducing peak
memory usage and memory traffic, and speeding up "clean incremental"
builds of `inflate` by about 10%.
|
|
|
|
`Liveness::users` is a vector that is occasionally enormous. For
example, doing a "clean incremental" check build of `inflate`, there is
one instance that represents 5,499 live nodes and 1087 vars, which
requires 5,977,413 entries. At 24 bytes per entry, that is 143MB.
This patch changes LiveNode from a usize to a u32. On 64-bit machines
that halves the size of these entries, significantly reducing peak
memory usage and memory traffic, and speeding up "clean incremental"
builds of `inflate` by about 10%.
|
|
|
|
Consider this a down payment on #50723. To recap, an `Applicability`
enum was recently (#50204) added, to convey to Rustfix and other tools
whether we think it's OK for them to blindly apply the suggestion, or
whether to prompt a human for guidance (because the suggestion might
contain placeholders that we can't infer, or because we think it has a
sufficiently high probability of being wrong even though it's—
presumably—right often enough to be worth emitting in the first place).
When a suggestion is marked as `MaybeIncorrect`, we try to use comments
to indicate precisely why (although there are a few places where we just
say `// speculative` because the present author's subjective judgement
balked at the idea that the suggestion has no false positives).
The `run-rustfix` directive is opporunistically set on some relevant UI
tests (and a couple tests that were in the `test/ui/suggestions`
directory, even if the suggestions didn't originate in librustc or
libsyntax). This is less trivial than it sounds, because a surprising
number of test files aren't equipped to be tested as fixed even when
they contain successfully fixable errors, because, e.g., there are more,
not-directly-related errors after fixing. Some test files need an
attribute or underscore to avoid unused warnings tripping up the "fixed
code is still producing diagnostics" check despite the fixes being
correct; this is an interesting contrast-to/inconsistency-with the
behavior of UI tests (which secretly pass `-A unused`), a behavior which
we probably ought to resolve one way or the other (filed issue #50926).
A few suggestion labels are reworded (e.g., to avoid phrasing it as a
question, which which is discouraged by the style guidelines listed in
`.span_suggestion`'s doc-comment).
|
|
zackmdavis:and_the_case_of_the_unused_field_pattern_3_straight_to_video, r=estebank
in which the unused shorthand field pattern debacle/saga continues
In e4b1a79 (#47922), we corrected erroneous suggestions for unused
shorthand field pattern bindings, suggesting `field: _` where the
previous suggestion of `_field` wouldn't even have compiled
(#47390). Soon, it was revealed that this was insufficient (#50303), and
the fix was extended to references, slices, &c. (#50327) But even this
proved inadequate, as the erroneous suggestions were still being issued
for patterns in local (`let`) bindings (#50804). Here, we yank the
shorthand-detection and variable/node registration code into a new
common function that can be called while visiting both match arms and
`let` bindings.
Resolves #50804.
r? @estebank
|
