Download - HSR - Institutional Repository

Transcript
CHAPTER 3. IMPLEMENTATION AND SOLUTION
Fix created by Codan. If every resolution would be newly created from a resolution generator, a label could be passed in the
constructor of that
It is possible to back up the marker in the last isApplicable()
call. This way, specific labels may be displayed even with only
one Quick Fix per problem type. This is definitly a hack and fails
if isApplicable() is not called directly before getLabel().
MarkerResolutionGenerator for Append Argument
Add Argument needed its own marker resolution generator. Why?
The problem with the resolution generator of Codan is, it can only
produce one Quick Fix per problem. In case of multiple overloads,
different Add Argument Quick Fixes have to be displayed. This
could be solved by reporting the problem several times for each
overload.
Disabled Codan Problems
Since a separate plug-in was developed and Codan checkers were
duplicated to change their behavior, the old checkers are disabled.
This prevents from the issue that some problems got reported
twice. It is done inside the Activator class of the plug-in. There
a listener waits for Codan to be loaded and then disables all
Codan problems since checkers can only be disabled if all there
to be reported problems were disabled. From this time on only
the self written checkers are active and report problems.
3.5.5. Important Class Overview
Here is a short description about some classes used in the implementation and their duties.
Checkers
To write a checker, an AST-visitor[Gam95] is defined that resolves
the binding for every IASTName inside the AST. If the binding cannot be resolved properly, the returned binding is of the
type IProblemBinding, containing additional information about
the problem. Depending on the type of the problem binding,
49