Fix breakage due to rust-lang/rust#58079
The rustc change added HirId to a few nodes. As I understand it, the plan is
to remove the NodeId from these nodes eventually. Where the NodeId was
not being matched, I used `..` to try and avoid further breakage. Where it
was, I used `_` to make the fix easier when NodeId is removed.
The rustc change added HirId to a few nodes. As I understand it, the plan is
to remove the NodeId from these nodes eventually. Where the NodeId was
not being matched, I used `..` to try and avoid further breakage. Where it
was, I used `_` to make the fix easier when NodeId is removed.
Rather than looking for a fixed --emit arg set, just check to see
if we're emitting metadata at all. This makes it more robust to
being invoked by tools other than cargo (or if cargo changes its
invocation).
Issue #3663
Adding lint test for excessive LOC.
This is a WIP for #2377. Just wanted to pull in because I had a few questions:
1. Is it okay that I'm approaching this via counting by looking at each line in the snippet instead of looking at the AST tree? If there's another way to do it, I want to make sure I'm doing the correct way, but I wasn't sure since the output AST JSON doesn't seem to contain whitespace.
2. My function is definitely going to trigger the lint, so also wanted to see if there was something obvious I could do to reduce it.
3. Are the two tests fine, or is there something obvious I'm missing?
4. Obviously bigger question - am I approaching the line count correctly. Current strategy is count a line if it contains some code, so skip if it's just comments or empty.
Travis: Don't run integration tests on every PR commit
This does not save Clippy any time but it makes sure that the concurrent
build limit is not reached as quickly for the `rust-lang` Travis
account.
I can't create a permalink to the discussion somehow, so here's an
excerpt from the Infra channel:
```
[11:57 PM] pietroalbini: there is a clippy build (20 jobs) and a packed_simd one (42 builders) and a rustc one which isn't scheduling atm
[11:58 PM] pietroalbini: I don't think there is a way to prioritize rustc builds in the queue on travis, right?
[12:22 AM] alexcrichton: pietro: I don't think so no
[12:22 AM] alexcrichton: If it's a problem we should cull builds on other projects
[12:22 AM] alexcrichton: The rust repo is the #1 priority
```
Since the integration tests are rarely failing these days, I think it's
fine to not run them on every commit.
If needed, it's also still possible to do a complete test run with `@bors try`.
Fix ICE in vec_box lint and add run-rustfix
Includes https://github.com/rust-lang/rust-clippy/pull/3726
`hir::Ty` doesn't seem to know anything about type bounds and
`cx.tcx.type_of(def_id)` caused an ICE when it was passed a generic type
with a bound:
```
src/librustc_typeck/collect.rs:1311: unexpected non-type Node::GenericParam: Type { default: None, synthetic: None }
```
Converting it to a proper `Ty` fixes the ICE and catches a few more places
where the lint applies.
Fixes#3720
`hir::Ty` doesn't seem to know anything about type bounds and
`cx.tcx.type_of(def_id)` caused an ICE when it was passed a generic type
with a bound:
```
src/librustc_typeck/collect.rs:1311: unexpected non-type Node::GenericParam: Type { default: None, synthetic: None }
```
Converting it to a proper `Ty` fixes the ICE and catches a few more
places where the lint applies.
This does not save Clippy any time but it makes sure that the concurrent
build limit is not reached as quickly for the `rust-lang` Travis
account.
I can't create a permalink to the discussion somehow, so here's an
excerpt from the Infra channel:
```
[11:57 PM] pietroalbini: there is a clippy build (20 jobs) and a packed_simd one (42 builders) and a rustc one which isn't scheduling atm
[11:58 PM] pietroalbini: I don't think there is a way to prioritize rustc builds in the queue on travis, right?
[12:22 AM] alexcrichton: pietro: I don't think so no
[12:22 AM] alexcrichton: If it's a problem we should cull builds on other projects
[12:22 AM] alexcrichton: The rust repo is the #1 priority
```
Since the integration tests are rarely failing these days, I think it's
fine to not run them on every commit.
If needed, it's also still possible to do a `try` build with `@bors try`.
