ghost
commented
8 years ago Looking very far ahead, one idea for achieving sophisticated analysis of source code changes is to embed a C compiler front-end as a plugin. KT uses CIL as its Advance analyzer front-end. We in Palo Alto discussed the viability of using CIL in Atom to do this results invalidation task, concluding it "might" be possible. The CIL-produced abstract syntax tree (AST) would be the basis for comparison of before-after differences in source changes and might be passed to the analyzer as a "difference" indication. It is fast enough to do this without having to run the static analyzer, which could require more time and would have to run CIL anyway.
CIL is open source. It is written in OCaml and would have to be built for the user's platform and then wrapped in an Atom plugin somehow. I don't know if any sand-boxing allows local platform reference.
The CIL source is mature, but lightly maintained by Gabriel Kerneis in Paris.
compartia
If a user edits a C source file after its KT Advance analysis was completed, then the previous Advance results may no longer be accurate. There are some sophisticated parsing algorithms we might apply later to determine whether the analysis remains accurate after a change. Until then, perhaps we can apply a simple default rule that any change to a function automatically invalidates all previous analysis results associated with that function (INV, PPO, PEV, SPO, SEV, API).
How best to show previous results invalidated? I don't know. Can these be tagged somehow as
dirtyto indicate the analysis for that function must be re-performed? We don't want necessarily to remove the results altogether because the user might parse for himself whether it remains valid. Moreover we might track statistics on file/program dirty result counts.