Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement issue finder for lint names #5049

Closed
wants to merge 1 commit into from

Conversation

flip1995
Copy link
Member

@flip1995 flip1995 commented Jan 15, 2020

Since we're going towards 1000 issues and simply don't have enough manpower to triage them properly and therefore the issue tracker gets kind of convoluted, I thought it would be a good idea to have one tracking issue for all lints. In the tracking issue, for every lint a list of issues mentioning this lint in its title or in the issue body would be displayed.

This is what this tool does. This tool is behind a feature, because it requires reqwest and serde, which would otherwise blow up the clippy_dev build.

Output
GITHUB_TOKEN=*** cargo run --features issues -- issues_for_lint --all --filter "2845,2846"

absurd_extreme_comparisons

approx_constant

assign_op_pattern

blacklisted_name

block_in_if_condition_expr

block_in_if_condition_stmt

bool_comparison

borrow_interior_mutable_const

borrowed_box

box_vec

boxed_local

cargo_common_metadata

cast_lossless

cast_possible_truncation

cast_ptr_alignment

cast_sign_loss

clone_on_copy

clone_on_ref_ptr

cmp_owned

cognitive_complexity

collapsible_if

comparison_chain

debug_assert_with_mut_call

declare_interior_mutable_const

deprecated_cfg_attr

derive_hash_xor_eq

doc_markdown

double_comparisons

double_neg

drop_copy

drop_ref

else_if_without_else

empty_enum

empty_loop

enum_clike_unportable_variant

enum_glob_use

enum_variant_names

eq_op

erasing_op

eval_order_dependence

exit

expect_fun_call

expl_impl_clone_on_copy

explicit_counter_loop

explicit_into_iter_loop

explicit_iter_loop

explicit_write

extend_from_slice

filter_map

filter_next

find_map

float_arithmetic

float_cmp

float_cmp_const

fn_to_numeric_cast

fn_to_numeric_cast_with_truncation

for_loop_over_option

for_loop_over_result

forget_ref

get_unwrap

identity_conversion

identity_op

if_let_redundant_pattern_matching

if_let_some_result

if_same_then_else

implicit_hasher

implicit_return

indexing_slicing

inherent_to_string

inherent_to_string_shadow_display

inline_always

integer_arithmetic

integer_division

into_iter_on_array

into_iter_on_ref

invalid_atomic_ordering

invalid_regex

invalid_upcast_comparisons

items_after_statements

large_enum_variant

len_without_is_empty

len_zero

let_and_return

let_underscore_must_use

let_unit_value

linkedlist

logic_bug

manual_mul_add

many_single_char_names

map_entry

match_bool

match_ref_pats

match_same_arms

match_wild_err_arm

min_max

missing_const_for_fn

missing_docs_in_private_items

missing_inline_in_public_items

mistyped_literal_suffixes

module_name_repetitions

modulo_one

multiple_inherent_impl

must_use_candidate

mut_from_ref

mut_mut

mutable_key_type

mutex_atomic

needless_bool

needless_borrow

needless_continue

needless_doctest_main

needless_lifetimes

needless_pass_by_value

needless_range_loop

needless_return

neg_multiply

new_ret_no_self

new_without_default

no_effect

non_ascii_literal

nonminimal_bool

not_unsafe_ptr_arg_deref

op_ref

option_and_then_some

option_map_unit_fn

option_map_unwrap_or

option_map_unwrap_or_else

option_option

option_unwrap_used

or_fun_call

out_of_bounds_indexing

overflow_check_conditional

panic

partialeq_ne_impl

possible_missing_comma

precedence

print_literal

print_with_newline

ptr_arg

question_mark

range_plus_one

redundant_clone

redundant_closure

redundant_closure_call

redundant_field_names

redundant_pattern

redundant_pattern_matching

redundant_static_lifetimes

regex_macro

replace_consts

result_map_unwrap_or_else

result_unwrap_used

reverse_range_loop

shadow_reuse

shadow_same

shadow_unrelated

should_assert_eq

should_implement_trait

similar_names

single_char_pattern

single_match

single_match_else

str_to_string

string_add

string_add_assign

string_lit_as_bytes

string_to_string

suspicious_arithmetic_impl

suspicious_else_formatting

suspicious_map

temporary_cstring_as_ptr

todo

too_many_arguments

toplevel_ref_arg

transmute_ptr_to_ptr

transmute_ptr_to_ref

trivial_regex

trivially_copy_pass_by_ref

type_complexity

type_repetition_in_bounds

unimplemented

uninit_assumed_init

unit_arg

unit_cmp

unnecessary_filter_map

unnecessary_fold

unnecessary_mut_passed

unnecessary_unwrap

unneeded_field_pattern

unreachable

unreadable_literal

unused_io_amount

unused_label

unused_self

unused_unit

use_debug

use_self

used_underscore_binding

useless_attribute

useless_format

useless_let_if_seq

useless_transmute

useless_vec

vec_box

while_immutable_condition

while_let_loop

while_let_on_iterator

wrong_pub_self_convention

wrong_self_convention

zero_prefixed_literal

zero_ptr

I'm pretty satisfied with the output. Some lint names that are too generic, like panic or exit, need some extra work though.


Usage:

Prints all issues where the specified lint is mentioned either in the title or in the description

USAGE:
    clippy_dev issues_for_lint [FLAGS] [OPTIONS] --name <name>

FLAGS:
        --all        Create a list for all lints
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
        --filter <filter>    Comma separated list of issue numbers, that should be filtered out
    -n, --name <name>        The name of the lint

Your thoughts about having such a tracking issue?

changelog: none

@flip1995 flip1995 added S-needs-discussion Status: Needs further discussion before merging or work can be started S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Jan 15, 2020
|| body.contains(&name)
|| body.contains(&separated_name)
|| body.contains(&dash_separated_name))
})
Copy link

@apiraino apiraino Jan 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how about also checking the issue labels? If at some point in the future issues are then properly labeled with a lint-*, that could make easier to sort them

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, we would then need over 300 labels for all of the lints and the issues had to be labeled correctly. Labeling issues by hand wouldn't be feasible. Maybe we could write an automation for such a labeling. But as long, as we don't have such a system in place, I don't think adding this to this tool makes much sense.

But The lint-*/L-* label idea is definitely interesting! Maybe we could add the labels of the issues in the output of this tool 🤔

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could add the labels of the issues in the output of this tool

that's a great idea imo 👍

As a positive side effect, people can easily start using the right label when reporting, decreasing in time the amount of "unlabeled" linting issues.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, but I'm not sure it makes sense, as a starting point, I'd force feed the issueing ticketing system with all the labels with a quick cURL, so people can be instructed to use them immediately and we truncate immediately the input of "unlabeled" linting issues

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing is, that "normal" users can't label their issue by them self, but Collaborators/Members have to do this. There is also @rustbot, but we can't check this automatically. We'd could write a GitHub Actions Workflow, that scans a new issue for a lint name and labels it accordingly.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can have issue templates that have a default label. I have some examples here: https://github.com/jyn514/rcc/tree/master/.github/ISSUE_TEMPLATE

Copy link

@apiraino apiraino Feb 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I'm wrong, for issue templates to be useful we need to have the user be able to automatically apply one label out of dozens hundreds and that would require having dozens hundreds of templates, therefore a scary list of templates when the user creates the issue :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we're soon completely migrated to GHA, we could implement the labeler workflow for issues and PRs, that would do that. But the question, if we want to have hundreds of labels still stands.

Copy link
Member

@phansch phansch Feb 21, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we can automate the label creation, I would not be against it personally but that's probably for another PR

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. So, I'd add a check for the issue label here (because imo it's a sensible default) and then we find a way to manage the issue creation workflow.

@phansch phansch self-requested a review February 21, 2020 06:44
Copy link
Member

@phansch phansch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks good to me in general 👍 I think somewhere there should also be some instructions on how to generate the issue text. I assume it's cargo --feature issues dev issues_for_lint --name foobar?

}

fn next_link(response: &Response) -> Option<String> {
if let Some(links) = response.headers().get("Link").and_then(|l| l.to_str().ok()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if let Some(links) = response.headers().get("Link").and_then(|l| l.to_str().ok()) {
if let Some(links) = response.headers().get(reqwest::headers::LINK).and_then(|l| l.to_str().ok()) {


fn next_link(response: &Response) -> Option<String> {
if let Some(links) = response.headers().get("Link").and_then(|l| l.to_str().ok()) {
if let Some(cap) = NEXT_PAGE_RE.captures_iter(links).next() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, is there no way to do this without a regex?

header::AUTHORIZATION,
header::HeaderValue::from_str(&format!("token {}", github_token))?,
);
headers.insert(header::USER_AGENT, header::HeaderValue::from_static("ghost"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be nice to give the user agent a slightly more descriptive name such as 'rust-clippy issue finder'

Ok(issues)
}

fn filter_issues<'a>(issues: &'a [Issue], name: &str, filter: &'a [u32]) -> impl Iterator<Item = &'a Issue> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth adding some unit tests for this function

@flip1995
Copy link
Member Author

I think that we could really use automatic issue triage, but this probably won't lead to anything.

@flip1995 flip1995 closed this May 25, 2020
@flip1995 flip1995 added S-inactive-closed Status: Closed due to inactivity and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels May 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive-closed Status: Closed due to inactivity S-needs-discussion Status: Needs further discussion before merging or work can be started
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants