Lines Matching refs:signature

10 * Allow extracting the API (into signature text files, into stub API files
44     signature files, the SDK stub files, external annotations etc.
75   signature files for the framework as doclava1.
78   means we can regenerate signature files etc for older versions according to
83   IntelliJ external annotations data as well as signature files containing
87 * Support for an updated signature file format (which is described in FORMAT.md)
92   * Improve the signature format such that it for example labels enums "enum"
98     ignores) block comments in the signature files.)
100   * Add support for writing (and reading) annotations into the signature
107     their nullness contract, the signature files would very quickly become
109     signature format now uses a suffix of `?` for nullable, `!` for not yet
133     annotations are not included in signature files) use just the simple name
167   require you to create two signature files to diff.
170   generated the signature files and generated the stubs had diverged, so there
172   same signatures as in the signature files.
179   the exact same API as is listed in the signature files, and once this was
187   possible with the signature-file based Python version; for example, it looks
293   API usage. (Prior to this, this was based on signature file parsing in
301   method using the intended visibility instead when generating signature files
315     android.jar files (e.g. backed by bytecode) or reading previous signature
318     can also generate signature files in the new format (including data that was
319     missing in older signature files, such as annotation methods) without having
336 signature files: TextPackageItem, TextClassItem, and so on.
342 from a signature file. That's how API diffing is performed: you load two
343 codebases (from whatever source you want, typically a previous API signature
369 signature or stub data:
443 hierarchy to see if there still is an inherited method with the same signature,