Skip to content

JS: introduce 'Util::describeExpression'#390

Merged
semmle-qlci merged 2 commits into
masterfrom
unknown repository
Nov 5, 2018
Merged

JS: introduce 'Util::describeExpression'#390
semmle-qlci merged 2 commits into
masterfrom
unknown repository

Conversation

@ghost

@ghost ghost commented Oct 31, 2018

Copy link
Copy Markdown

As discussed recently, it may be clearer to mention the kind of an expression in an alert message, instead of just using the generic "this expression is bad".

This PR introduce utility for doing just that: Util::describeExpression. I have put it to use in js/trivial-conditional, we can use it in other queries later.

The evalution shows that performance does not degrade.

Ping @max as he may have an opinion on this.

@ghost ghost added the JS label Oct 31, 2018
@ghost ghost self-requested a review as a code owner October 31, 2018 11:15
@ghost

ghost commented Oct 31, 2018

Copy link
Copy Markdown
Author

Not that @max. Sorry about that!
Ping @xiemaisi

asger-semmle
asger-semmle previously approved these changes Oct 31, 2018

@asger-semmle asger-semmle left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I like this. 👍

if sel instanceof VarAccess then
msg = capitalize(description) + " always evaluates to " + cv + " here."
else
msg = "This " + description + " always evaluates to " + cv + "."

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

In general we could get messages like:

This property 'f' always evaluates to true.

In general I think "named" expressions should belong in the former category.

Property 'f' always evaluates to true here.

We could add a boolean flag to describeExpression indicating whether it is named.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Hmm, on the other hand, if we decided to name calls, then they would go in the other category,

This call to `isFoo` always evaluates to true.
Call to `isFoo` always evaluates to true here.

Natural langauge sucks.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

The problem is the two kinds of messages. How about we conflate them to the latter, with variables being described as "read of variable 'v'":

Examples:

This comparison always evaluate to true.
This expression always evaluate to true.
This read of variable 'v' always evaluate to true.
This read of property 'p' always evaluate to true.
This call to 'f' always evaluate to true.
This property read always evaluate to true.
This call always evaluate to true.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I would prefer This use of instead of This read of.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Done + some additional features. I am not sure I like messages with the callee name though: they are long, and the callee name is not a link.

xiemaisi
xiemaisi previously approved these changes Nov 5, 2018

@xiemaisi xiemaisi left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

LGTM as well, but conflicts.

@ghost

ghost commented Nov 5, 2018

Copy link
Copy Markdown
Author

Rebased.

@semmle-qlci semmle-qlci merged commit 5c9939b into github:master Nov 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants