clippy: Fix warnings in generated code #31721
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes some clippy warnings from the code generated by
CodegenRust.py
. It specifically gets rids of all errors from these files.Due to the nature of the generated code, some allowances had to be made, sometimes because of false positives, and sometimes because "fixing" the warning would be very inefficient or require changing how everything generates. The allows and their reasoning are the following:
approx_constant
: Values defined in.webidl
files could be related to constants such as pi. In rust it would be better to use defined types such asf64::consts::PI
, but because these are taken from other files they should stay as numeric values.let_unit_value
: InCGCallGenerator
the value ofresult
can take the()
type. This is intended, and while specific allows could be placed for every let binding easily, this generates too many lines so it may be better to allow it for the entire file. There is also discussion regarding this lint in let_unit_value should be allowed when I explicitly write "let () = ..." rust-lang/rust-clippy#9048.needless_return
: InCGPerSignatureCall
, the call towrap_return_value
can be straightforward, so a simpletrue
at the end could suffice, but it could also contain nested matches, soreturn true;
becomes necessary. Distinguishing between all the possible cases seems overly complicated whenreturn true;
works and isn't much more verbose. The other instances of returning were addressed.too_many_arguments
: Like in other cases, some functions generate with too many arguments. It seems counterproductive to check every function to know if it has more than x arguments and add an allow for it automatically when it can be permitted for every file.unnecessary_cast
: This is specifically forMethodDefiner::generateArray
. There is a comment specifying that it's not easy to tell whether the methodinfo is aJSJitInfo
or aJSTypedMethodJitInfo
, so we cast them both toJSJitInfo
and rely on the compiler doing the conversion. This creates manyunnecessary_cast
warnings forJSJitInfo
, but it is documented and not trivial to fix../mach build -d
does not report any errors./mach test-tidy
does not report any errors