-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add tool unreachable
#13783
Add tool unreachable
#13783
Conversation
ae0cf74
to
bc288a1
Compare
bc288a1
to
1a3679f
Compare
I have used some simple tools for working with the output of this command. They are not part of the tool itself to keep it simple and separate concerns. $ sort -t $'\t' -k3 -gr < unreachable.tsv | head # print the methods with most loc
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/interpreter/value.cr:15:3 Crystal::Repl::Value#value 54 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/codegen/codegen.cr:29:5 Crystal::Program#evaluate 42 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/syntax/to_s.cr:781:5 Crystal::ToSVisitor#visit 35 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/tools/playground/agent.cr:11:3 Crystal::Playground::Agent#i 33 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/semantic/cleanup_transformer.cr:1112:5 Crystal::CleanupTransformer#simple_constant? 31 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/semantic/type_declaration_processor.cr:332:11 Crystal::TypeDeclarationProcessor#check_non_nilable_for_generic_module 27 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/tools/playground/agent.cr:61:11 Crystal::Playground::Agent#send 12 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/semantic/main_visitor.cr:606:5 Crystal::MainVisitor#first_time_accessing_meta_type_var? 12 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/semantic/ast.cr:502:5 Crystal::MetaVar#inspect 12 lines
/home/johannes/src/crystal-lang/crystal/src/compiler/crystal/semantic/type_declaration_processor.cr:360:11 Crystal::TypeDeclarationProcessor#has_syntax_nil? 11 lines # delete all reported methods
tac unreachable.tsv | while read -r line; do
fileinfo=$(echo "$line" | cut -f1)
path=$(echo "$fileinfo" | cut -d: -f1)
line=$(echo "$fileinfo" | cut -d: -f2)
column=$(echo "$fileinfo" | cut -d: -f3)
sed -i -E "${line},/^$(printf %*s $(expr $column - 1))end/d" "$path"
done In case you have multiple entry points, you can run the tool multiple times and combine the results to figure out methods that are called in neither: comm -12 --nocheck-order unreachable1.tsv unreachable2.tsv |
CR | ||
end | ||
|
||
# TODO: Should abstract Foo#bar be reported as well? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe so. Otherwise we might never find that the method is no longer needed. But I would understand if not reported.
If the entry point is specs those might mark it as used, but without specs then it could be pointed out.
If only the abstract is there when building the source, should we get an abstract check error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If only the abstract is there when building the source, should we get an abstract check error?
Yes, that's how it works currently. If an abstract method is never called, the tool reports all implementations as unreachable. But not the abstract def. Then after removing all the reported implementations, you'll get an abstract check error.
I think that's good enough for an MVP implementation.
Another use case we might not be checking is macro expanded methods. It's more complex. If a |
And detecting if a macro definition is never used is also something we could consider adding in the future |
Co-authored-by: Brian J. Cardiff <bcardiff@gmail.com>
@bcardiff Currently the tool does not consider any defs that have been expanded from a macro (because the location is a virtual file). So yeah we're missing out on Testing other features than defs (macros, constants, types) for being unused would be further feature enhancements. They also may need some more careful planning and are out of scope for this PR. |
I agree. It sounds to me like we have a new tool 🚀 |
Co-authored-by: Sijawusz Pur Rahnama <sija@sija.pl>
Co-authored-by: Sijawusz Pur Rahnama <sija@sija.pl>
db67d1e
to
37574b5
Compare
The specs are failing in Windows |
The failure on Windows was due to #13831. The latest commit should fix that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I leave a minor comment and a question.
Co-authored-by: Beta Ziliani <beta@manas.tech>
Co-authored-by: Brian J. Cardiff <bcardiff@gmail.com> Co-authored-by: Sijawusz Pur Rahnama <sija@sija.pl> Co-authored-by: Beta Ziliani <beta@manas.tech>
This adds a compiler tool to identify methods that are never called.
It's based off earlier work by @bcardiff presented in #3801 (comment) (although a majority of the code has changed since that poc).
I have tested this on the compiler source code. There are no false positives, so I'm quite certain that we're good there.
Asserting recall is much more difficult. I cannot be sure about whether some unused definitions might be missed. But it seems to be pretty complete.
Resolves #3801