Skip to content
This repository has been archived by the owner on Feb 12, 2022. It is now read-only.

Don't error calling possibly non-functions in pure functions #1321

Closed

Conversation

sebmarkbage
Copy link
Contributor

@sebmarkbage sebmarkbage commented Jan 11, 2018

As outlined in #1264 we know that it is safe to throw in an pure function since then the return value will be ignored and therefore its state doesn't matter. The only time it matters, is if there is a try/catch/finally around it which we already warn about.

This means that we don't have to error when calling a non-function.

I also plan to add more of these cases like this. So I took the liberty to also move this category of tests into a separate folder.

@sebmarkbage
Copy link
Contributor Author

This fixes one of the tests in #1320.

Copy link
Contributor

@hermanventer hermanventer left a comment

Choose a reason for hiding this comment

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

This looks OK to me. It would be great if you can add another test case where the runtime value of condition is actually false.

As outlined in facebookarchive#1264 we know
that it is safe to throw in an pure function since then the return value
will be ignored and therefore its state doesn't matter. The only time
it matters, is if there is a try/catch around it which we already warn
about.

This means that we don't have to error when calling a non-function.

I also plan to add more of these cases like this. So I took the liberty to
also move this category of tests into a separate folder.
@sebmarkbage
Copy link
Contributor Author

Add another test where it is expected that the resulting functions will throw.

Copy link

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

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

@sebmarkbage is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

facebook-github-bot pushed a commit that referenced this pull request Jan 17, 2018
Summary:
Builds on top of #1321

Lets $Get succeed on abstract values. Property access is not safe on abstract object values because they could be getters with side-effects or might throw.

However, this is safe in a pure function context. We just have to make sure we leak the object that might get passed to a getter.

It is also safe to coerce a non-object abstract value to an object, since all it can do is throw.
Closes #1322

Differential Revision: D6734870

Pulled By: sebmarkbage

fbshipit-source-id: bfe7a61dc312577ec4cc8926d3191dcee4e28b61
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants