Split refactoring problems into init, options and final.

pkg/analysis_server/test/integration/integration_test_methods.dart

 // Copyright (c) 2014, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 //
 // This file has been automatically generated.  Please do not edit it manually.
 // To regenerate the file, use the script
 // "pkg/analysis_server/tool/spec/generate_files".
 
 /**
  * Convenience methods for running integration tests
@@ skipping 1119 matching lines @@
    * options ( optional RefactoringOptions )
    *
    *   Data used to provide values provided by the user. The structure of the
    *   data is dependent on the kind of refactoring being performed. The data
    *   that is expected is documented in the section titled Refactorings,
    *   labeled as “Options”. This field can be omitted if the refactoring does
    *   not require any options or if the values of those options are not known.
    *
    * Returns
    *
-   * problems ( List<RefactoringProblem> )
+   * initialProblems ( List<RefactoringProblem> )
    *
-   *   The status of the refactoring. The array will be empty if there are no
-   *   known problems.
+   *   The initial status of the refactoring, i.e. problems related to the
+   *   context in which the refactoring is requested. The array will be empty
+   *   if there are no known problems.
+   *
+   * optionsProblems ( List<RefactoringProblem> )
+   *
+   *   The options validation status, i.e. problems in the given options, such
+   *   as light-weight validation of a new name, flags compatibility, etc. The
+   *   array will be empty if there are no known problems.
+   *
+   * finalProblems ( List<RefactoringProblem> )
+   *
+   *   The final status of the refactoring, i.e. problems identified in the
+   *   result of a full, potentially expensive validation and / or change
+   *   creation. The array will be empty if there are no known problems.
    *
    * feedback ( optional RefactoringFeedback )
    *
    *   Data used to provide feedback to the user. The structure of the data is
    *   dependent on the kind of refactoring being created. The data that is
    *   returned is documented in the section titled Refactorings, labeled as
    *   “Feedback”.
    *
    * change ( optional SourceChange )
    *
@@ skipping 303 matching lines @@
       case "execution.launchData":
         expect(params, isExecutionLaunchDataParams);
         _onExecutionLaunchData.add(params);
         break;
       default:
         fail('Unexpected notification: $event');
         break;
     }
   }
 }