Fix for serializing annotations.

Fix for serializing annotations.

Instead of using artificial TypeName nodes we just pass all the required
information. This helps to avoid the situation when we mutate the AST
because we re-parent nodes in annotation.

It would be nice if annotations used the same AST structure as
instance creation :-(

R=paulberry@google.com
BUG=

Committed: https://github.com/dart-lang/sdk/commit/4c76af4511c074a476ba680f1e145ebbae009aad

[Paul Berry, 2016-05-02 20:35:48]

lgtm

https://codereview.chromium.org/1943013002/diff/1/pkg/analyzer/lib/src/summar...
File pkg/analyzer/lib/src/summary/summarize_const_expr.dart (right):

https://codereview.chromium.org/1943013002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/summarize_const_expr.dart:107: * [name] in the
class identified by [typeName].
Can you include some documentation of [type] and [typeArguments]?  In
particular:

- If the constructor invocation specifies type arguments, is it necessary for
the caller to ensure that type.typeArguments == typeArguments?
- Under what circumstances is it permissible to pass type=null?  (I assume it's
when the type is unresolved, as with [serializeType], below?)

https://codereview.chromium.org/1943013002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/summarize_const_expr.dart:131: * Return
[EntityRefBuilder] that corresponds to the [name] with the given
I think you mean "...to the [type] with the given [name] and [arguments]."

[scheglov, 2016-05-02 20:54:36]

Description was changed from

==========
Fix for serializing annotations.

Instead of using artificial TypeName nodes we just pass all the required
information. This helps to avoid the situation when we mutate the AST
because we re-parent nodes in annotation.

It would be nice if annotations used the same AST structure as
instance creation :-(

R=paulberry@google.com
BUG=
==========

to

==========
Fix for serializing annotations.

Instead of using artificial TypeName nodes we just pass all the required
information. This helps to avoid the situation when we mutate the AST
because we re-parent nodes in annotation.

It would be nice if annotations used the same AST structure as
instance creation :-(

R=paulberry@google.com
BUG=

Committed:
https://github.com/dart-lang/sdk/commit/4c76af4511c074a476ba680f1e145ebbae009aad
==========

[scheglov, 2016-05-02 20:54:37]

Committed patchset #1 (id:1) manually as
4c76af4511c074a476ba680f1e145ebbae009aad (presubmit successful).

[scheglov, 2016-05-02 20:55:04]

https://codereview.chromium.org/1943013002/diff/1/pkg/analyzer/lib/src/summar...
File pkg/analyzer/lib/src/summary/summarize_const_expr.dart (right):

https://codereview.chromium.org/1943013002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/summarize_const_expr.dart:107: * [name] in the
class identified by [typeName].
On 2016/05/02 20:35:48, Paul Berry wrote:
> Can you include some documentation of [type] and [typeArguments]?  In
> particular:
> 
> - If the constructor invocation specifies type arguments, is it necessary for
> the caller to ensure that type.typeArguments == typeArguments?
> - Under what circumstances is it permissible to pass type=null?  (I assume
it's
> when the type is unresolved, as with [serializeType], below?)

Done.

https://codereview.chromium.org/1943013002/diff/1/pkg/analyzer/lib/src/summar...
pkg/analyzer/lib/src/summary/summarize_const_expr.dart:131: * Return
[EntityRefBuilder] that corresponds to the [name] with the given
On 2016/05/02 20:35:48, Paul Berry wrote:
> I think you mean "...to the [type] with the given [name] and [arguments]."

Acknowledged.