This should reduce confusion, since these classes are specifically
*not* part of kernel. I also went ahead and renamed a few classes
that aren't shadow classes but are related to the shadow classes,
e.g. KernelTypeInferrer -> ShadowTypeInferrer.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/3004923002 .
It turns out that it is easier to calculate whether or not checks are
needed at the site of the declaration of the interface target, not at
the call site. Accordingly, it makes sense to put the annotations on
the interface target declarations as well. This lets us get rid of a
clumsy annotation format that referred to arguments by number, in
favor of simply annotating the formal parameters themselves.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/3010613003 .
This merges functionality and removes several Token classes
making the Token hierarchy more compact.
* merge BeginTokenWithComment into BeginToken
* merge KeywordTokenWithComment into KeywordToken
* merge StringTokenWithComment into StringToken
* merge TokenWithComment into SimpleToken
R=ahe@google.com
Review-Url: https://codereview.chromium.org/3010533002 .
Rather than have multple fine grained error codes for each type
of modifier in each situation, this CL adds a new analyzer
ParserErrorCode.EXTRANEOUS_MODIFIER parallel to the fast parser
error code and updates the AstBuilder to generate that error
rather than ParserErrorCode.ABSTRACT_CLASS_MEMBER.
My goal is to review each analyzer error code similar to
ParserErrorCode.ABSTRACT_CLASS_MEMBER and map each to the same
ParserErrorCode.EXTRANEOUS_MODIFIER error code.
R=paulberry@google.com
Review-Url: https://codereview.chromium.org/2999303002 .
Context: this prevents us from using other schemes in unit tests, and causes
issues when processign a URI with no scheme, that happens to be supported by the
underlying file-system (e.g. PhysicalFileSystem will make it a `file:*` URI if
no scheme was present).
This is necessary to fix dartbug.com/30141
Review-Url: https://codereview.chromium.org/3006483002 .
Otherwise the canonicalizer grows without limit, and if the user
edits files, we constantly parse new strings, so constantly add new
entries into the cananonicalizer. Basically, it is not friendly for
long running processes. I'm not quite sure why we need to makes it
static anyway, if it can be used only for the same file content. Once
we're done with a file, that is it, we don't need its entries.
Anyway, this fixes a leak in Analysis Server.
R=ahe@google.com, brianwilkerson@google.com, danrubel@google.com, paulberry@google.com
BUG=
Review-Url: https://codereview.chromium.org/3003753002 .
We haven't quite figured out how we want to store the need for these
type checks in the kernel representation, and I'm hoping that my
coding work can help inform that decision. So for the moment the
annotation is simply stored in the front_end wrapper
(KernelVariableDeclaration). This is enough to get simple tests to
pass.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/3000353002 .
The tests in this CL illustrate the major use cases where runtime
checks are required. They are not exhaustive. In a later CL I will
copy over some of analyzer's internal unit tests, which are much more
thorough.
So far these tests only pass when tested via analyzer, since analyzer
currently is the only platform that does the necessary analysis to
figure out which checks are needed. In follow up CLs I will begin
introducing code into front_end to determine which checks are needed,
and to record this information in the kernel representation.
R=danrubel@google.com, sigmund@google.com
Review-Url: https://codereview.chromium.org/3002893002 .
Refactor the AstBuilder to use scriptTag, directives, and declarations
fields rather than pushing top level nodes on a generic stack
and later popping and sorting objects from the that generic stack.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2995963002 .
When dartfmt is run as part of tests to verify that code generation is
up to date, the directory containing the resolved executable is
sometimes .../out/Release.../, but dartfmt is located in
.../out/Release.../dart-sdk/bin/dartfmt. So we need to look in both
the resolved executable directory and in dart-sdk/bin for dartfmt.
R=devoncarew@google.com
Review-Url: https://codereview.chromium.org/3002713002 .
Konstantin Shcheglov