|
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