Issue 3753. Support for @deprecated annotation

Issue 3753. Support for @deprecated annotation
http://code.google.com/p/dart/issues/detail?id=3753


R=brianwilkerson@google.com
BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=9264

[Brian Wilkerson, 2012-06-29 16:17:49]

LGTM. Comments can be addressed in a separate CL.

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
File compiler/java/com/google/dart/compiler/resolver/AbstractNodeElement.java
(right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
compiler/java/com/google/dart/compiler/resolver/AbstractNodeElement.java:1: //
Copyright (c) 2011, the Dart project authors.  Please see the AUTHORS file
nit: copyright year

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
File compiler/java/com/google/dart/compiler/resolver/Element.java (right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
compiler/java/com/google/dart/compiler/resolver/Element.java:1: // Copyright (c)
2011, the Dart project authors.  Please see the AUTHORS file
nit: copyright year

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
File compiler/java/com/google/dart/compiler/type/TypeAnalyzer.java (right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
compiler/java/com/google/dart/compiler/type/TypeAnalyzer.java:1228: if
(methodElement != null && methodElement.getMetadata().isDeprecated()) {
This needs to be copied into visitBinaryExpression,
visitFunctionObjectInvocation, visitRedirectConstructorInvocation,
visitSuperConstructorInvocation, and visitUnaryExpression. It might be possible
to move it into checkInvocation and cover all of those cases in one place, but I
haven't looked that deeply.

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/javatests/com...
File
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java
(right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/javatests/com...
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java:2932:
"// @deprecated",
Does deprecating a class implicitly deprecate everything inside it? If so, then
the deprecated markers inside this class are not needed (although we should test
them inside a class that isn't also deprecated). If not, then I'm not sure why
the implicit constructor is deprecated.

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
File
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java
(right):

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java:99:
private static final class DynamicTypeHighlighting extends SemanticHighlighting
{
Should this subclass DefaultSemanticHighlighting?

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java:149:
private static class FieldHighlighting extends SemanticHighlighting {
Should this subclass DefaultSemanticHighlighting?

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java:206:
private static class StaticFieldHighlighting extends FieldHighlighting {
Should this subclass DefaultSemanticHighlighting?

[scheglov, 2012-06-29 20:11:56]

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
File compiler/java/com/google/dart/compiler/resolver/AbstractNodeElement.java
(right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
compiler/java/com/google/dart/compiler/resolver/AbstractNodeElement.java:1: //
Copyright (c) 2011, the Dart project authors.  Please see the AUTHORS file
On 2012/06/29 16:17:49, Brian Wilkerson wrote:
> nit: copyright year

Done.

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
File compiler/java/com/google/dart/compiler/resolver/Element.java (right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
compiler/java/com/google/dart/compiler/resolver/Element.java:1: // Copyright (c)
2011, the Dart project authors.  Please see the AUTHORS file
On 2012/06/29 16:17:49, Brian Wilkerson wrote:
> nit: copyright year

Done.

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
File compiler/java/com/google/dart/compiler/type/TypeAnalyzer.java (right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/java/com/goog...
compiler/java/com/google/dart/compiler/type/TypeAnalyzer.java:1228: if
(methodElement != null && methodElement.getMetadata().isDeprecated()) {
On 2012/06/29 16:17:49, Brian Wilkerson wrote:
> This needs to be copied into visitBinaryExpression,
> visitFunctionObjectInvocation, visitRedirectConstructorInvocation,
> visitSuperConstructorInvocation, and visitUnaryExpression. It might be
possible
> to move it into checkInvocation and cover all of those cases in one place, but
I
> haven't looked that deeply.

Done.

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/javatests/com...
File
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java
(right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/javatests/com...
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java:2932:
"// @deprecated",
On 2012/06/29 16:17:49, Brian Wilkerson wrote:
> Does deprecating a class implicitly deprecate everything inside it? If so,
then
> the deprecated markers inside this class are not needed (although we should
test
> them inside a class that isn't also deprecated). If not, then I'm not sure why
> the implicit constructor is deprecated.

Constructor invocation has form: Type[.nameOfConstructor](args).
I.e. we add warning for type reference.
We could not declare local variable, for example "new
DeprecatedType().doSomething()" and in this case it still would be nice to show
that "DeprecatedType" is deprecated.

I don't think that we should propagate deprecation flag to the type members.
It would show to much deprecation warnings.
Just one warning at the place of declaration (or creation) is enough.
Of course, if you want specify type annotation, you will not see it.
But if you don't specify types, you probably care even less about deprecation.

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
File
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java
(right):

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java:99:
private static final class DynamicTypeHighlighting extends SemanticHighlighting
{
On 2012/06/29 16:17:49, Brian Wilkerson wrote:
> Should this subclass DefaultSemanticHighlighting?

Done.

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java:149:
private static class FieldHighlighting extends SemanticHighlighting {
On 2012/06/29 16:17:49, Brian Wilkerson wrote:
> Should this subclass DefaultSemanticHighlighting?

Done.

https://chromiumcodereview.appspot.com/10703046/diff/1/editor/tools/plugins/c...
editor/tools/plugins/com.google.dart.tools.ui/src/com/google/dart/tools/ui/internal/text/editor/SemanticHighlightings.java:206:
private static class StaticFieldHighlighting extends FieldHighlighting {
On 2012/06/29 16:17:49, Brian Wilkerson wrote:
> Should this subclass DefaultSemanticHighlighting?

Done.

[Brian Wilkerson, 2012-06-29 20:20:28]

LGTM

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/javatests/com...
File
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java
(right):

https://chromiumcodereview.appspot.com/10703046/diff/1/compiler/javatests/com...
compiler/javatests/com/google/dart/compiler/type/TypeAnalyzerCompilerTest.java:2932:
"// @deprecated",
> we add warning for type reference.

OK. I understand the reasoning behind the behavior.

> I don't think that we should propagate deprecation flag to the type members.

I agree. I'm fine with it now that I understand the reasoning.