tools/presubmit.py changes source files

[DartBot]

This issue was originally filed by rchandia@google.com

---

Running tools/presubmit.py modifies two files present in bleeding/edge:

tests/stub-generator/src/MintMakerFullyIsolatedTest-generatedTest.dart
tests/stub-generator/src/MintMakerPromiseWithStubsTest-generatedTest.dart

This causes unnecessary noise, and frequently these files get recommited by mistake.

Also notice that generated files leaks personal information. For example line 9 in

http://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/tests/stub-generator/src/MintMakerFullyIsolatedTest-generatedTest.dart#­9

[DartBot]

This comment was originally written by drfibonacci@google.com

---

Added Triaged label.

[whesse]

This continues to be very annoying. Marking the original creator of these files as owner of the bug.

---

Set owner to benl@google.com.

[DartBot]

This comment was originally written by ben@links.org

---

As I've mentioned before, it should not be a hard change to make it only overwrite the files when they have changed.

[whesse]

Here is the present behavior, and the difficulties in changing it to something else:
Components not based on the dartc compiler take the generated tests files and run normally on those. The generated test files are alongside the originals, with -generatedTest.dart at the end.

Components based on dartc (dartc and chromium), compile some stubs to a temporary output directory with the -generate-isolate-stubs flag, and then concatenate them with the original file to make the -generatedTest files. Then they run as normal on the generatedTest files.

Difficulties in changing this are:
  1) The final files have relative paths to ../../isolate/src/TestFramework.dart. So they cannot be put in a temporary directory. They could be put in a subdirectory of the build directory, if it is at the right relative level. The relative path could also be made to start with ../../.. if it helps. Or all the support files could be copied to the temporary directory. Or the relative paths could be rewritten in the generated files.

  2) If the generated files are not kept (and checked in), then other components without dartc cannot be tested on them. If a checked in version is kept, that is not
generated automatically, then it will get out of date unless someone refreshes it.

The question is, what alternative solution do we want to adopt? Do we need a general system for links to infrastructure library files from generated dart (and JS) files? Do we support always placing the generated tests from a test at the same relative level in the client checkout, and use relative links with ../../..? This also causes a problem with build directories at different levels (building and testing from runtime and compiler, rather than from the top level). These problems will probably get larger, as we test more complex Dart web apps and Dart standalone apps. A deployment tool for web apps could help here.

[whesse]

I have a working CL to put the generated tests into the build directory, which only leaves issue #2.

[whesse]

Changelist is https://chromiumcodereview.appspot.com/9195017/

[whesse]

This should be marked as fixed, but only when we decide what to do about regenerating the generated tests files that are in the repository, when regeneration is needed.

---

Added Started label.

[whesse]

Added AssumedStale label.

[anders-sandholm]

Removed Area-Build label.
Added Area-Infrastructure label.