Lines Matching refs:annotations

21    format adds new information, such as annotations, parameter names and default
25 3. This is format v2, but with all nullness annotations replaced by a
28    in format v2, but it was deferred since type-use annotations introduces
38 developers), we'd like to have nullness annotations (as well as some other
39 annotations) be a formal part of the SDK.
41 That means the annotations should be part of the signature files too -- such
75 The new signature format now includes annotations; not all annotations (such as
77 annotations, etc.
90 (Notice how the annotations are not using fully qualified name; that's discussed
93 The annotations to be included are annotations for annotation types that are not
96 The annotations should be sorted alphabetically by fully qualified name.
158 "implement" it instead of "extend"-ing it, etc; enums and annotations are just
289 name (and included if the property declaration uses special annotations to name
308 annotations to mark up the null contract for an element, we will also have a
394 new format, we instead list these using annotations, @Deprecated.
433 We have a number of annotations which are significant for the API -- not just
435 ?/! Kotlin syntax and the deprecated "modifier"), but annotations for permission
441 we generate the SDK, we translate these into publicly known annotations,
450 In v2 we do neither: We use only the simple name of the annotations in the
451 signature file, for annotations that are in the well known packages. In other
475 annotations, and doing the same thing for java.lang: Omitting it when writing
483 In v3, "type use annotations" are supported which means annotations can appear