-
Notifications
You must be signed in to change notification settings - Fork 27
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
feat#1533: verify general
and supplementary
registered lints
#1535
base: master
Are you sure you want to change the base?
feat#1533: verify general
and supplementary
registered lints
#1535
Conversation
I really appreciate you working on this. 🙏
I noticed this actually. :) I started a PR to run the You are welcome to ignore the failures, but if you have ideas on how to refine the regex, I would welcome them. Please note that I already made some small changes to the lint's logic: https://github.com/trailofbits/dylint/pull/1536/files#diff-655df697dba7900d7f7a61d9548c870a5068b918eabf6381760f107b35afb3a2L133-L149 Needless to say, I really appreciate you building that lint, because I am sure it will catch mistakes. I will give the present PR a more thorough review after #1536 is finalized and merged. |
Pleasure is mine I'll be here for a while, I have a lot to learn from you😊 Not a very creative idea but maybe we could change the path regex to |
You're very kind. :)
It might be worth just But I happen to know the lint triggers in other places. For example, it produces these warnings in the
Another idea, besides refining the regex, could be to cast a wider net and then filter out unwanted matches afterward. Like maybe the regex could match non-empty sequences with at least one if full_path.starts_with("https://") {
continue;
} |
Yes this seems like the best approach to deal with the url, similar to the escaping_doc_link one I guess; looks like I did not implement the lint to ignore URLs as well as I thought 🤔 |
Doing what I said literally produces a lot of false positives:
I'm struggling a little bit here. I'm not sure what the best path forward is. |
Relevant issue #1533
This test ensures that all lints defined in the "general" and "supplementary" folders are actually registered in the corresponding src/lib.rs file. The process is as follows:
([a-zA-Z_][a-zA-Z0-9_]*)::register_lints\s*\(
which captures the module name right before the literal::register_lints
call.if we were to run the test with the dylint's current state we would get this output:
Also seeing that
::register_lints
is only used inside of the general and supplementary folders, I figured that using the examples::iter function would be too broad for our check.This approach is a bit different from the initial that we initially discussed about, because we extract the existing lints with their folder names instead of extracting them from the
cargo metadata
. I'm open to feedback or alternative suggestions!