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
buf_lint_test: unused import is not reported #32
Comments
@alexeagle Has this been fixed? Not finding any recent changes that would indicate that it has been. |
Ha thats funny, in a private repo I commented "when they fix " and GitHub triggered the auto close when that merged |
@sushain97, @alexeagle: this is still an issue. Sadly, the We could reproduce the unused import checks that the compiler does (though it's not necessarily trivial to implement due to how public imports work, and it is more cumbersome to implement with a compiled descriptor vs. with source due to how custom options are represented). But another thing we're looking into is how to possibly plug buf into the proto_library rule in place of protoc; buf can then include metadata about unused imports in the file descriptors that the plugin receives (just as it does when using There is actually a similar issue related to the warning about a file missing a syntax declaration. Unfortunately, this one cannot be solved by the plugin trying to reproduce a check that the compiler performs. This is a check that only the compiler can detect because a descriptor always has a syntax value, even if the original source file did not. So the approach we're exploring for unused imports would also allow us to address this (since the buf compiler can include metadata in the file descriptor set regarding whether the syntax declaration actually existed in source). |
Based on the above comment, I happened to peek into the underlying Buf compiler code here and was able to write a custom test rule prototype that does unused import checks (example here). Sharing it here in case anyone else would find it helpful (note: my example was quickly put together, so might be rough around the edges) |
@jhump does your team want to take that solution and upstream it? Otherwise anyone finding this issue will use @smocherla-brex solution which is ready-to-go (thanks for posting that!!) |
@alexeagle, I'm looking into a fix in the protoc-gen-buf-lint plugin itself, to do this check in a more integrated/transparent way. The linked solution is rather heavy-weight, re-doing the compile from source. It should be much more efficient to instead examine the edges of the graph in the descriptors provided in the code gen request. |
This will address bufbuild/rules_buf#32. The problem is that the code generator request does not include the stored unused dependencies. So, since the check doesn't see that information, it never complains (even if the file does have unused imports, and the compiler that originally produced the descriptor set warned about them). So, just for `protoc-gen-buf-lint`, we introduce a new step to re-compute the unused dependencies and store them in the image proto. This is woven into `bufimage`, because that's the place where we have the information needed to do this. This basically emulates the checks that the compiler does. The compiler populates the set of used imports while resolving all symbols in the file, during linking. So we basically do that, too, by visiting all references and marking associated imports as used.
…ld#1835) This will address bufbuild/rules_buf#32. The problem is that the code generator request does not include the stored unused dependencies. So, since the check doesn't see that information, it never complains (even if the file does have unused imports, and the compiler that originally produced the descriptor set warned about them). So, just for `protoc-gen-buf-lint`, we introduce a new step to re-compute the unused dependencies and store them in the image proto. This is woven into `bufimage`, because that's the place where we have the information needed to do this. This basically emulates the checks that the compiler does. The compiler populates the set of used imports while resolving all symbols in the file, during linking. So we basically do that, too, by visiting all references and marking associated imports as used.
FYI - this is fixed for us. I recently used it to eliminate well over 7 million log lines of spam 🎉 |
Yeah, sorry I didn't post here a few months ago. This was fixed in the |
This may be the same root cause as #22
I made this patch to repro at HEAD:
but the
buf_lint_test
still passes:Note that the
proto_library
rule wrote a warning in the action that created the Descriptor Set, but there's no test failure so the warning is easily ignored by developers.The text was updated successfully, but these errors were encountered: