Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upfix(ivy): avoid infinite recursion when evaluation source files #33772
Conversation
When ngtsc comes across a source file during partial evaluation, it would determine all exported symbols from that module and evaluate their values greedily. This greedy evaluation strategy introduces unnecessary work and can fall into infinite recursion when the evaluation result of an exported expression would circularly depend on the source file. This would primarily occur in CommonJS code, where the `exports` variable can be used to refer to an exported variable. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending up evaluating the `exports` variable again. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending u evaluating the `exports` variable again. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending up evaluating the `exports` variable again. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending up evaluating the `exports` variable again. This went on for some time until all stack frames were exhausted. This commit introduces a `ResolvedModule` that delays the evaluation of its exports until they are actually requested. This avoids the circular dependency when evaluating `exports`, thereby fixing the issue. Fix #33734
This comment has been minimized.
This comment has been minimized.
VladimirAmiorkov
commented
Nov 18, 2019
•
What is the simplest way of building an Angular with this PR? I want to test if #33734 is resolved by it. |
This comment has been minimized.
This comment has been minimized.
@VladimirAmiorkov You can find instructions here on using artifacts from CircleCI for this PR: |
This comment has been minimized.
This comment has been minimized.
VladimirAmiorkov
commented
Nov 18, 2019
•
Thanks for this info. Looking at the builds and the note that the artefacts may not be averrable I feel like they already are not. I checked here https://circleci.com/gh/angular/angular/524826#artifacts but cant seem to find any artefacts, that build was 6 days ago so maybe I am late to get them :) . Or maybe I dont have access to the "Artefacts" tab, this is what I see on this PR and all others I have checked. |
This comment has been minimized.
This comment has been minimized.
@VladimirAmiorkov, you can find the latest artifacts from this PR here: https://circleci.com/gh/angular/angular/524805#artifacts (Hint: It's the |
This comment has been minimized.
This comment has been minimized.
(FWIW, I tried this with #33734 and I got a different error, so I guess the "Maximum call stack size exceeded" error is fixed |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
ngbot
bot
commented
Nov 20, 2019
This comment has been minimized.
This comment has been minimized.
merge-assistance: size failure is unrelated. |
When ngtsc comes across a source file during partial evaluation, it would determine all exported symbols from that module and evaluate their values greedily. This greedy evaluation strategy introduces unnecessary work and can fall into infinite recursion when the evaluation result of an exported expression would circularly depend on the source file. This would primarily occur in CommonJS code, where the `exports` variable can be used to refer to an exported variable. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending up evaluating the `exports` variable again. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending u evaluating the `exports` variable again. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending up evaluating the `exports` variable again. This variable would be resolved to the source file itself, thereby greedily evaluating all exported symbols and thus ending up evaluating the `exports` variable again. This went on for some time until all stack frames were exhausted. This commit introduces a `ResolvedModule` that delays the evaluation of its exports until they are actually requested. This avoids the circular dependency when evaluating `exports`, thereby fixing the issue. Fix #33734 PR Close #33772
JoostK commentedNov 12, 2019
When ngtsc comes across a source file during partial evaluation, it
would determine all exported symbols from that module and evaluate their
values greedily. This greedy evaluation strategy introduces unnecessary
work and can fall into infinite recursion when the evaluation result of
an exported expression would circularly depend on the source file. This
would primarily occur in CommonJS code, where the
exports
variable canbe used to refer to an exported variable. This variable would be
resolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the
exports
variableagain. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending u
evaluating the
exports
variable again. This variable would beresolved to the source file itself, thereby greedily evaluating all
exported symbols and thus ending up evaluating the
exports
variableagain. This variable would be resolved to the source file itself,
thereby greedily evaluating all exported symbols and thus ending up
evaluating the
exports
variable again. This went on for some timeuntil all stack frames were exhausted.
This commit introduces a
ResolvedModule
that delays the evaluation ofits exports until they are actually requested. This avoids the circular
dependency when evaluating
exports
, thereby fixing the issue.Fix #33734