feat(compiler-cli): explain why an expression cannot be used in AOT compilations #37587

JoostK · 2020-06-15T11:20:53Z

During AOT compilation, the value of some expressions need to be known at
compile time. The compiler has to ability to statically evaluate expressions
the best it can, but there can be occurrences when an expression cannot be
evaluated statically. For instance, the evaluation could depend on a dynamic
value or syntax is used that the compiler does not understand. Alternatively,
it is possible that an expression could be statically evaluated but the
resulting value would be of an incorrect type.

In these situations, it would be helpful if the compiler could explain why it
is unable to evaluate an expression. To this extend, the static interpreter
in Ivy keeps track of a trail of DynamicValues which follow the path of nodes
that were considered all the way to the node that causes an expression to be
considered dynamic. Up until this commit, this rich trail of information was
not surfaced to a developer so the compiler was of little help to explain
why static evaluation failed, resulting in situations that are hard to debug
and resolve.

This commit adds much more insight to the diagnostic that is produced for static
evaluation errors. For dynamic values, the trail of DynamicValue instances
is presented to the user in a meaningful way. If a value is available but not
of the correct type, the type of the resolved value is shown.

Resolves FW-2155

The text was updated successfully, but these errors were encountered:

JoostK · 2020-06-15T18:16:34Z

packages/compiler-cli/src/ngtsc/partial_evaluator/src/diagnostics.ts

+    if (maxDepth === 0) {
+      return 'Array';
+    }
+    return `[${value.map(v => describeResolvedType(v, maxDepth - 1)).join(', ')}]`;


I choose to display arrays as a tuple representation (e.g. [string, string, number]), but we may as well choose to show them as array with a union type (e.g. (string | number)[]). Alternatively, we could limit the number of entries to include.

packages/compiler-cli/src/ngtsc/partial_evaluator/src/diagnostics.ts

alxhub

👍 really clean implementation - this is going to be awesome!

gkalpak

A couple of optional nits and a couple of commit message typos. Otherwise looks great 💯

2nd commit: has to ability to statically evaluate --> has the ability to statically evaluate (?)
3rd commit: a function calls --> a function call

gkalpak · 2020-06-17T14:00:48Z

packages/compiler-cli/src/ngtsc/partial_evaluator/src/dynamic.ts

@@ -55,6 +56,11 @@ export const enum DynamicValueReason {
   */
  INVALID_EXPRESSION_TYPE,

+  /**
+   * A function call could not be evaluated as its body is not a single return statement.


Nit: The current wording makes it sound as if the call has a body 😇

Suggested change

* A function call could not be evaluated as its body is not a single return statement.

* A function call could not be evaluated as the function's body is not a single return statement.

gkalpak · 2020-06-17T14:00:48Z

packages/compiler-cli/src/ngtsc/partial_evaluator/src/diagnostics.ts

+  } else if (value instanceof ResolvedModule) {
+    return 'module';
+  } else if (value instanceof EnumValue) {
+    return value.enumRef.debugName ?? '(anonymous)';


Would it make sense to include something to show it is an enum value?

Enum values are essentially just References, but refer to a particular member of that enum. As we're just printing the type here, only the information from the reference is used. As such, it's displayed as other References would be. We could include the kind of declaration for any Reference, e.g. show class MyCmp and enum ViewEncapsulation, but I kept the notation as close as TS's native representation of types.

What might make sense to do is to extend createValueHasWrongTypeError such that it creates a ts.DiagnosticRelationInformation pointing to the declaration of the enum, as it does for References.

gkalpak · 2020-06-17T14:00:48Z

packages/compiler-cli/src/ngtsc/partial_evaluator/src/diagnostics.ts

+    }
+    return `[${value.map(v => describeResolvedType(v, maxDepth - 1)).join(', ')}]`;
+  } else if (value instanceof DynamicValue) {
+    return 'dynamic';


Nit: I am wondering whether dynamic is somewhat ambiguous for the user. Would something like not statically analyzable be more helpful?

Good point, changed as proposed. I also went over all others and added parenthesis to some to indicate that these are not actual types.

alxhub · 2020-06-17T18:25:06Z

Presubmit

…dInformation` Previously, an anonymous type was used for creating a diagnostic with related information. The anonymous type would then be translated into the necessary `ts.DiagnosticRelatedInformation` shape within `makeDiagnostic`. This commit switches the `makeDiagnostic` signature over to taking `ts.DiagnosticRelatedInformation` directly and introduces `makeRelatedInformation` to easily create such objects. This is done to aid in making upcoming work more readable.

…ompilations During AOT compilation, the value of some expressions need to be known at compile time. The compiler has the ability to statically evaluate expressions the best it can, but there can be occurrences when an expression cannot be evaluated statically. For instance, the evaluation could depend on a dynamic value or syntax is used that the compiler does not understand. Alternatively, it is possible that an expression could be statically evaluated but the resulting value would be of an incorrect type. In these situations, it would be helpful if the compiler could explain why it is unable to evaluate an expression. To this extend, the static interpreter in Ivy keeps track of a trail of `DynamicValue`s which follow the path of nodes that were considered all the way to the node that causes an expression to be considered dynamic. Up until this commit, this rich trail of information was not surfaced to a developer so the compiler was of little help to explain why static evaluation failed, resulting in situations that are hard to debug and resolve. This commit adds much more insight to the diagnostic that is produced for static evaluation errors. For dynamic values, the trail of `DynamicValue` instances is presented to the user in a meaningful way. If a value is available but not of the correct type, the type of the resolved value is shown. Resolves FW-2155

This commit introduces a dedicated `DynamicValue` kind to indicate that a value cannot be evaluated statically as the function body is not just a single return statement. This allows more accurate reporting of why a function call failed to be evaluated, i.e. we now include a reference to the function declaration and have a tailor-made diagnostic message.

…n AOT compilations

alxhub · 2020-06-19T00:18:24Z

Take 2

…ompilations (#37587) During AOT compilation, the value of some expressions need to be known at compile time. The compiler has the ability to statically evaluate expressions the best it can, but there can be occurrences when an expression cannot be evaluated statically. For instance, the evaluation could depend on a dynamic value or syntax is used that the compiler does not understand. Alternatively, it is possible that an expression could be statically evaluated but the resulting value would be of an incorrect type. In these situations, it would be helpful if the compiler could explain why it is unable to evaluate an expression. To this extend, the static interpreter in Ivy keeps track of a trail of `DynamicValue`s which follow the path of nodes that were considered all the way to the node that causes an expression to be considered dynamic. Up until this commit, this rich trail of information was not surfaced to a developer so the compiler was of little help to explain why static evaluation failed, resulting in situations that are hard to debug and resolve. This commit adds much more insight to the diagnostic that is produced for static evaluation errors. For dynamic values, the trail of `DynamicValue` instances is presented to the user in a meaningful way. If a value is available but not of the correct type, the type of the resolved value is shown. Resolves FW-2155 PR Close #37587

…all (#37587) This commit introduces a dedicated `DynamicValue` kind to indicate that a value cannot be evaluated statically as the function body is not just a single return statement. This allows more accurate reporting of why a function call failed to be evaluated, i.e. we now include a reference to the function declaration and have a tailor-made diagnostic message. PR Close #37587

…dInformation` (angular#37587) Previously, an anonymous type was used for creating a diagnostic with related information. The anonymous type would then be translated into the necessary `ts.DiagnosticRelatedInformation` shape within `makeDiagnostic`. This commit switches the `makeDiagnostic` signature over to taking `ts.DiagnosticRelatedInformation` directly and introduces `makeRelatedInformation` to easily create such objects. This is done to aid in making upcoming work more readable. PR Close angular#37587

…ompilations (angular#37587) During AOT compilation, the value of some expressions need to be known at compile time. The compiler has the ability to statically evaluate expressions the best it can, but there can be occurrences when an expression cannot be evaluated statically. For instance, the evaluation could depend on a dynamic value or syntax is used that the compiler does not understand. Alternatively, it is possible that an expression could be statically evaluated but the resulting value would be of an incorrect type. In these situations, it would be helpful if the compiler could explain why it is unable to evaluate an expression. To this extend, the static interpreter in Ivy keeps track of a trail of `DynamicValue`s which follow the path of nodes that were considered all the way to the node that causes an expression to be considered dynamic. Up until this commit, this rich trail of information was not surfaced to a developer so the compiler was of little help to explain why static evaluation failed, resulting in situations that are hard to debug and resolve. This commit adds much more insight to the diagnostic that is produced for static evaluation errors. For dynamic values, the trail of `DynamicValue` instances is presented to the user in a meaningful way. If a value is available but not of the correct type, the type of the resolved value is shown. Resolves FW-2155 PR Close angular#37587

…all (angular#37587) This commit introduces a dedicated `DynamicValue` kind to indicate that a value cannot be evaluated statically as the function body is not just a single return statement. This allows more accurate reporting of why a function call failed to be evaluated, i.e. we now include a reference to the function declaration and have a tailor-made diagnostic message. PR Close angular#37587

…nction call (angular#37587)" This reverts commit ce879fc. Reason for revert: failing tests on Windows (related to file paths).

…in AOT compilations (angular#37587)" This reverts commit 712f1bd. Reason for revert: failing tests on Windows (related to file paths).

…icRelatedInformation` (angular#37587)" This reverts commit d2fb552. Reason for revert: failing tests on Windows (related to file paths).

angular-automatic-lock-bot · 2020-07-26T16:14:48Z

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}

…dInformation` (#37587) Previously, an anonymous type was used for creating a diagnostic with related information. The anonymous type would then be translated into the necessary `ts.DiagnosticRelatedInformation` shape within `makeDiagnostic`. This commit switches the `makeDiagnostic` signature over to taking `ts.DiagnosticRelatedInformation` directly and introduces `makeRelatedInformation` to easily create such objects. This is done to aid in making upcoming work more readable. PR Close #37587

…dInformation` (angular#37587) Previously, an anonymous type was used for creating a diagnostic with related information. The anonymous type would then be translated into the necessary `ts.DiagnosticRelatedInformation` shape within `makeDiagnostic`. This commit switches the `makeDiagnostic` signature over to taking `ts.DiagnosticRelatedInformation` directly and introduces `makeRelatedInformation` to easily create such objects. This is done to aid in making upcoming work more readable. PR Close angular#37587

…ompilations (angular#37587) During AOT compilation, the value of some expressions need to be known at compile time. The compiler has the ability to statically evaluate expressions the best it can, but there can be occurrences when an expression cannot be evaluated statically. For instance, the evaluation could depend on a dynamic value or syntax is used that the compiler does not understand. Alternatively, it is possible that an expression could be statically evaluated but the resulting value would be of an incorrect type. In these situations, it would be helpful if the compiler could explain why it is unable to evaluate an expression. To this extend, the static interpreter in Ivy keeps track of a trail of `DynamicValue`s which follow the path of nodes that were considered all the way to the node that causes an expression to be considered dynamic. Up until this commit, this rich trail of information was not surfaced to a developer so the compiler was of little help to explain why static evaluation failed, resulting in situations that are hard to debug and resolve. This commit adds much more insight to the diagnostic that is produced for static evaluation errors. For dynamic values, the trail of `DynamicValue` instances is presented to the user in a meaningful way. If a value is available but not of the correct type, the type of the resolved value is shown. Resolves FW-2155 PR Close angular#37587

…all (angular#37587) This commit introduces a dedicated `DynamicValue` kind to indicate that a value cannot be evaluated statically as the function body is not just a single return statement. This allows more accurate reporting of why a function call failed to be evaluated, i.e. we now include a reference to the function declaration and have a tailor-made diagnostic message. PR Close angular#37587

JoostK added feature state: WIP target: major comp: compiler labels Jun 15, 2020

ngbot bot added this to the needsTriage milestone Jun 15, 2020

googlebot added the cla: yes label Jun 15, 2020

JoostK force-pushed the explain-dynamic-values branch from 554c97c to 7dd2242 Jun 15, 2020

JoostK reviewed Jun 15, 2020

View changes

JoostK added action: review and removed state: WIP labels Jun 15, 2020

JoostK marked this pull request as ready for review Jun 15, 2020

pullapprove bot requested review from alxhub and gkalpak Jun 15, 2020

alxhub reviewed Jun 15, 2020

View changes

packages/compiler-cli/src/ngtsc/partial_evaluator/src/diagnostics.ts Show resolved Hide resolved

Loading

alxhub reviewed Jun 15, 2020

View changes

packages/compiler-cli/src/ngtsc/partial_evaluator/src/diagnostics.ts Outdated Show resolved Hide resolved

Loading

alxhub reviewed Jun 15, 2020

View changes

packages/compiler-cli/src/ngtsc/partial_evaluator/src/diagnostics.ts Show resolved Hide resolved

Loading

alxhub approved these changes Jun 15, 2020

View changes

JoostK force-pushed the explain-dynamic-values branch from 7dd2242 to 03b3bb6 Jun 15, 2020

gkalpak approved these changes Jun 17, 2020

View changes

gkalpak added action: cleanup and removed action: review labels Jun 17, 2020

JoostK force-pushed the explain-dynamic-values branch from 03b3bb6 to df5bd6f Jun 17, 2020

JoostK added action: merge action: presubmit and removed action: cleanup labels Jun 17, 2020

petebacondarwin assigned aikidave Jun 18, 2020

JoostK added 3 commits Jun 18, 2020

fixup! feat(compiler-cli): explain why an expression cannot be used i…

3f8660b

…n AOT compilations

JoostK force-pushed the explain-dynamic-values branch from df5bd6f to 3f8660b Jun 18, 2020

JoostK removed the action: presubmit label Jun 24, 2020

AndrewKushnir closed this in d2fb552 Jun 25, 2020

AndrewKushnir mentioned this pull request Jun 25, 2020

Revert "feat(compiler-cli): explain why an expression cannot be used in AOT compilations #37587" #37761

Closed

angular-automatic-lock-bot bot locked and limited conversation to collaborators Jul 26, 2020

angular / angular Public

feat(compiler-cli): explain why an expression cannot be used in AOT compilations #37587

feat(compiler-cli): explain why an expression cannot be used in AOT compilations #37587

JoostK commented Jun 15, 2020

JoostK Jun 15, 2020

alxhub left a comment

gkalpak left a comment

gkalpak Jun 17, 2020

gkalpak Jun 17, 2020

JoostK Jun 17, 2020

gkalpak Jun 17, 2020

JoostK Jun 17, 2020

alxhub commented Jun 17, 2020

alxhub commented Jun 19, 2020

angular-automatic-lock-bot bot commented Jul 26, 2020

	* A function call could not be evaluated as its body is not a single return statement.
	* A function call could not be evaluated as the function's body is not a single return statement.

angular / angular Public

feat(compiler-cli): explain why an expression cannot be used in AOT compilations #37587

feat(compiler-cli): explain why an expression cannot be used in AOT compilations #37587

Conversation

JoostK commented Jun 15, 2020

JoostK Jun 15, 2020

Choose a reason for hiding this comment

alxhub left a comment

gkalpak left a comment

gkalpak Jun 17, 2020

Choose a reason for hiding this comment

gkalpak Jun 17, 2020

Choose a reason for hiding this comment

JoostK Jun 17, 2020

Choose a reason for hiding this comment

gkalpak Jun 17, 2020

Choose a reason for hiding this comment

JoostK Jun 17, 2020

Choose a reason for hiding this comment

alxhub commented Jun 17, 2020

alxhub commented Jun 19, 2020

angular-automatic-lock-bot bot commented Jul 26, 2020