Lines Matching refs:annotations

17    format adds new information, such as annotations, parameter names and default
21 3. This is format v2, but will all nullness annotations replaced by a
24    in format v2, but it was deferred since type-use annotations introduces
34 developers), we'd like to have nullness annotations (as well as some other
35 annotations) be a formal part of the SDK.
37 That means the annotations should be part of the signature files too -- such
71 The new signature format now includes annotations; not all annotations (such as
73 annotations, etc.
86 (Notice how the annotations are not using fully qualified name; that's discussed
89 The annotations to be included are annotations for annotation types that are not
92 The annotations should be sorted alphabetically by fully qualified name.
154 "implement" it instead of "extend"-ing it, etc; enums and annotations are just
285 name (and included if the property declaration uses special annotations to name
304 annotations to mark up the null contract for an element, we will also have a
390 new format, we instead list these using annotations, @Deprecated.
429 We have a number of annotations which are significant for the API -- not just
431 ?/! Kotlin syntax and the deprecated "modifier"), but annotations for permission
437 we generate the SDK, we translate these into publicly known annotations,
446 In v2 we do neither: We use only the simple name of the annotations in the
447 signature file, for annotations that are in the well known packages. In other
472 annotations, and doing the same thing for java.lang: Omitting it when writing
480 In v3, "type use annotations" are supported which means annotations can appear