Lines Matching refs:of
8 a number of purposes:
20 * Diffing versions of the API and determining whether a newer version is
77 * Ability to read in an existing android.jar file instead of from source, which
85 load time such that it can be part of the API analysis.
93 instead of "abstract class extends java.lang.Enum", annotations as
94 "@interface" instead of "abstract class extends java.lang.Annotation", sorts
95 modifiers in the canonical modifier order, using "extends" instead of
96 "implements" for the superclass of an interface, and many other similar
101 files. This is vital now that some of these annotations become part of the
109 signature format now uses a suffix of `?` for nullable, `!` for not yet
112 Instead of
128 instead of
132 Similarly, annotations (the ones considered part of the API; unknown
134 instead of the full package name, e.g. `@UiThread` instead of
149 compiler treat errors in the user code as warnings instead of errors.)
153 of the source code). This means that the documentation tool itself does not
154 need to be able to figure out which parts of the source code is included in
181 important methods that should really be part of the API.)
183 * API Lint: Metalava can optionally (with --api-lint) run a series of additional
186 Some of these take advantage of looking at the source code which wasn't
191 * Baselines: Metalava can report all of its issues into a "baseline" file, which
192 records the current set of issues. From that point forward, when metalava
197 Lint, being able to check in the set of accepted or verified false positives
205 1279 out of 46900 methods were annotated (2%)
206 2 out of 21683 fields were annotated (0%)
207 2770 out of 47492 parameters were annotated (5%)
210 (.class or .jar files) and it will then measure the annotation coverage of the
212 that are currently used by a corpus of apps and target our annotation efforts
213 in a targeted way. For example, running the analysis on the current version of
217 ... --annotation-coverage-of ~/plaid/app/build/intermediates/classes/debug
221 324 methods and fields were missing nullness annotations out of 650 total
274 * Built on top of a full, type-resolved AST. Doclava1 was integrated with
275 javadoc, which meant that most of the source tree was opaque. Therefore, as
286 merges in manually curated data; some of this is in the manual/ folder in this
306 Metalava is implemented on top of IntelliJ parsing APIs (PSI and UAST). However,
316 files. Reading in multiple versions of an API lets doclava perform
322 (2) There's a lot of logic for deciding whether code found in the source tree
324 API and for example mark a subset of its methods as included. By having a
326 filtered model instead of passing around PsiClass and PsiMethod instances
331 "DocInfo".) There are several sub interfaces of Item: PackageItem, ClassItem,
334 to a source tree or a .jar file, and it constructs Items built on top of PSI:
344 file and the current set of source folders), and then you "diff" the two.
359 Similarly you can visit all items (regardless of type) by overriding
363 There is also an `ApiVisitor`. This is a subclass of the `ItemVisitor`, but
364 which limits itself to visiting code elements that are part of the API.
396 included (e.g. if `List<Foo>` is part of the API then `Foo` must be too). This
462 handling loop conditionals. (As a result I for example improved some of the
463 grammar, e.g. when it's listing a number of possible constants the conjunction
464 is usually "or", but if it's a flag, the sentence begins with "a combination of