-
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
Rust: Improve lines-of-code counts. #17588
Conversation
In general using A pretty simple way to deal with this problem is to ignore the start line for top-level items. That would under count in cases like fn
my_function() {...} but that would be extremely rare. |
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.
Changes look good to me. However, you could implement special handling of top-level items to avoid counting doc comments as a line.
Merged main, resolved conflicts and excluded top-level AST elements from the count (for now).
True, but notably this has proven to be a good enough approximation in other languages. Multi-line string literals should be pretty rare, and we might even add special logic for them if it turns out to be a thing that bothers us. |
I think I'm seeing this in the wild - things other than |
…es caused by attached comments.
Done. @aibaars I'd appreciate your thoughts on this. |
With the latest changes we finally get an under-count rather than an over-count of lines of code compared to |
That would probably work. We could include the start line for I suspect that the following node kinds may all start with a comment:
|
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.
Looks good to me. Perhaps include the start-line of BlockExpr and any other things that may start with a single {
on a line.
I think I'd rather merge this now, further improvements can follow later if necessary. When can I anticipate the locations themselves being fixed? If it might be in the next few weeks, I'm inclined not to spend any more time iterating on workarounds. |
Improve lines-of-code counts:
Module
from the count, which was spuriously adding +1 LOC inmain.rs
.println!
in the tests, since these should be deterministically (if not correctly) extracted now.@aibaars - also note that we have a spuriously located
MacroRules
(onmy_macro.rs
line 1) andStruct
(onmy_struct.rs
line 2), which I discovered while debugging this query. I haven't done anything about them, I believe the right fix would be in the extractor.Obviously types are still not extracted, which is also affecting the counts.