|
351 | 351 | called for the second `pop` call as well, since it calls a method
|
352 | 352 | inside a `@ThreadSafe` annotation (on the outer class), but the `index`
|
353 | 353 | would be 1. The lint check can check all the annotations earlier than
|
354 |
| -the one at the index to see if they "counteract" the annotation, which |
| 354 | +the one at the index to see if they “counteract” the annotation, which |
355 | 355 | of course the `@NotThreadSafe` annotation does.
|
356 | 356 |
|
357 | 357 | Lint uses this mechanism for example for the `@CheckResult` annotation,
|
|
375 | 375 | found in multiple nested contexts, lint *will* include all the
|
376 | 376 | annotations in the `AnnotationUsageInfo`, but it will not invoke
|
377 | 377 | your callback for any outer occurrences; only the closest one. This
|
378 |
| - is usually what detectors expect: the innermost one "overrides" the |
| 378 | + is usually what detectors expect: the innermost one “overrides” the |
379 | 379 | outer ones, so lint omits these to help avoid false positives where
|
380 | 380 | a lint check author forgot to handle and test this scenario. A good
|
381 | 381 | example of this situation is with the `@RequiresApi` annotation; a
|
|
405 | 405 | for testing purposes, but you have a concrete subclass where you are
|
406 | 406 | deliberately supporting the operation, not just from tests. If
|
407 | 407 | annotations were always inherited, you would have to create some sort
|
408 |
| -of annotation to "revert" the semantics, e.g. |
| 408 | +of annotation to “revert” the semantics, e.g. |
409 | 409 | `@VisibleNotJustForTesting`, which would require a lot of noisy
|
410 | 410 | annotations.
|
411 | 411 |
|
|
0 commit comments