-
Notifications
You must be signed in to change notification settings - Fork 1.7k
JS: classify generated data files #108
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach seems plausible; how many projects have you tried this out on?
e.getFile() = f and | ||
e.isImpure() and | ||
// ... except for variable initializers | ||
not e instanceof VariableDeclarator |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean we consider VariableDeclarator
s to be impure? That seems undesirable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but that seems right to me.
They do modify the scope object after all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, but modelling it seems overkill, particularly since we don't even model the scope object. Also, that modification isn't observable in any way, is it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I could go either way on this. On the one hand, shadowing variables in enclosing scopes and creation of properties on the global object are easily observable side effects, but on the other hand, I see what you mean regarding the expressive power of our analysis.
Do you want a change in this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right, of course, there are observable side effects, but I would still hesitate to ascribe them to the declarator, so on the whole I'd be in favour of changing this. It seems like a fairly minor and harmless change that would make this predicate look a bit less confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
Do we skip the full dist-compare for this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Yes, we do.
This has been tested on 203 projects with 38 results, which are all true positives. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Amended with updated expected output for |
Apologies, I only just realised I misremembered what a In that case of course it doesn't make sense to treat it as pure. Could you remove the second commit, please? (Sorry about that.) |
Done. |
Allow associating comments with fields
Fixes ODASA-7301 by identifying data files as side effect free files that are full of primitive literals.
Example results: