Skip to content

Fix interpretation of Typed trees #3852

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

Merged
merged 1 commit into from
Jan 18, 2018

Conversation

nicolasstucki
Copy link
Contributor

No description provided.

Copy link
Contributor

@liufengyun liufengyun left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -111,10 +111,13 @@ class Interpreter(implicit ctx: Context) {
val env2 = bindings.foldLeft(env)((acc, x) => interpretStat(x, acc))
interpretTreeImpl(expansion, env2)

case Typed(expr, _) =>
interpretTreeImpl(expr, env)
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need a check here? Maybe not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What kind of check? This is a fully typed tree, we evaluate it's erased version.

Copy link
Contributor

Choose a reason for hiding this comment

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

I was thinking to check the type, but it's not the semantics of the language. So ignore the comment.

@@ -0,0 +1,2 @@
true
false
Copy link
Contributor

Choose a reason for hiding this comment

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

How can I be sure the output is from compile-time, not run-time?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because the inline def has a top level ~ it can always be inlined. Then the inlined tree is interpreted to evaluate the Expr[T] which is then spliced in (see #3853 for a bit of info on that regard).
In short a macro call is guaranteed to be inlined or the compilation fails.

@liufengyun
Copy link
Contributor

liufengyun commented Jan 17, 2018 via email

@nicolasstucki
Copy link
Contributor Author

It is only when inlining a ~ that the interpreter is used. Any other uncalled method would not cover this use case.

@liufengyun
Copy link
Contributor

I mean in the test it's possible to move println(isZero(0)) out of the main method.

@liufengyun liufengyun merged commit e6babac into scala:master Jan 18, 2018
@liufengyun liufengyun deleted the fix-interpreting-typed-trees branch January 18, 2018 09:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants