Community
Participate
Working Groups
The API analysis incremental build should only analyze types that have structural changes or have API description changes (and all their dependents). Currently, we analyze all types that change (structually or non-structurally), and all their dependents). As well, only API visible types should be considered for analysis. A change to a non-API type does not effect API compatibility or API use.
> As well, only API visible types should be considered for analysis. A change to > a non-API type does not effect API compatibility or API use. > This is not entirely accurate. We need to scan internal types for the following cases: 1. unsupported tags 2. usage (i.e. illegally extending a restricted type) 3. unused filters 4. system library usage The only scans that are API visibility only are binary compatibility, leak and version.
Created attachment 132129 [details] work in progress Patch removes our usage of various sets throughout the builder and adds an IBuildContext which manages changed types (structural, description and removed types). Cleans up a problem where we were considering too many types as 'changed' (causing additional scanning). All of the tests do not pass with the patch. There is still work to be done finding a better way to work with inner types than hammering the Java model during an incremental build.
Created attachment 132626 [details] update This patch fixes the remaining problems, and all tests pass. Currently we do the usage (illegal extends, etc) and the leak scans at the same time on the same types (which includes dependent types). The problem with this is that the leak usage scans do not need to scan dependent types or non-api types. We should consider breaking the leak usage scans out from the reference analyzer, or updating the scope we pass in to more precisely specify what types are scanned by which parts of the analyzer
Applied the latest patch which prunes the types accordingly using the new build context. It does not include asking about API description changes as that would be better placed in the reference analyzer itself - that way we don't do extra work collecting types in the context when a usage scan might not take place at all (the preferences could be set to ignore). Opened bug 273295 to refactor the reference analyzer. please verify Olivier
Verified.
