Skip to content

Conversation

@erik-krogh
Copy link
Contributor

@erik-krogh erik-krogh commented Jan 14, 2022

Flags some bad style I recently encountered during a code-review.

I also went ahead and fixed all the alerts found in JS. (Except for this one, and the alerts in shared files).

Most of the time the fix is to somehow inline the field into the charpred.
But the right way to inline the field can vary a lot, so I'm not writing an automated patch for this.

I think that for some of the issues (e.g. this one) the problem is that the field should have been used somewhere.

@erik-krogh erik-krogh force-pushed the fieldOnlyUsedInCharPred branch 3 times, most recently from eadee88 to cbd2a25 Compare January 19, 2022 21:46
@erik-krogh erik-krogh force-pushed the fieldOnlyUsedInCharPred branch from cbd2a25 to 708c18d Compare January 20, 2022 08:41
@erik-krogh erik-krogh marked this pull request as ready for review January 20, 2022 09:07
@erik-krogh erik-krogh requested review from a team as code owners January 20, 2022 09:07
@erik-krogh erik-krogh added the no-change-note-required This PR does not need a change note label Jan 20, 2022
@aschackmull
Copy link
Contributor

I think that for some of the issues (e.g. this one) the problem is that the field should have been used somewhere.

That code is fine. The field can just be deleted there, if we want.

@aschackmull
Copy link
Contributor

It's an instance of a harmless pattern that appears to also occur many other places: When a class wraps an IPA-injector, all the columns from the IPA case are added as fields, and it may well be that not all of those needs to be referenced in member predicates.

@aschackmull
Copy link
Contributor

We may want to exclude that pattern from this query.

@aschackmull
Copy link
Contributor

Results look better now. 👍

Copy link

@kaeluka kaeluka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me — but I've left two comments where I'm a bit uncertain.

private newtype TValueNumber =
TVariableValueNumber(VarDecl var) { variableAccessValueNumber(_, var) } or
TFieldValueNumber(VarDecl var) { fieldAccessValueNumber(_, var) } or
TFieldValueNumber(FieldDecl var) { fieldAccessValueNumber(_, var) } or
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this an unrelated drive-by bugfix?

Copy link
Contributor

@MathiasVP MathiasVP Mar 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think var instanceof FieldDecl was implied by fieldAccessValueNumber already. So this is just making the branch more readable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I was trying to make it clear when something is a FieldDecl and when something is a VarDecl.

There is a lot of drive-by "Make FieldDecl and it's uses better"-fixes in this PR.

Copy link

@kaeluka kaeluka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes to the javascript analyses look good to me! 👍

@erik-krogh erik-krogh merged commit 4734f19 into github:main Mar 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

JS no-change-note-required This PR does not need a change note QL-for-QL

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants