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