[PATCH] D34764: Introduce FileEdit utility

[Reid Kleckner via Phabricator via llvm-commits]

rnk added a comment.

In https://reviews.llvm.org/D34764#794163, @chandlerc wrote:

> But I would specifically advocate against using this heavily for things like assembly or C code. There, I would much rather a single file with preprocessing to split, or N files so that tools that are expected to work on those files continues to work.


I don't believe llvm-mc is capable of doing this preprocessing, and lld doesn't depend on clang, so we can't use the C pre-processor there. Really, I just want a tool like the C preprocessor that works on plain text files. That's kind of how I envision FileEdit: it splits files (#ifdef) and does string substitutions (-D macros). If you think using the C preprocessor for this kind of stuff is OK and not confusing, then I don't see how a standalone tool is different.

I really don't want to use prefixes to describe multiple input files. It breaks all the normal editor highlighting and indentation that you normally get for free.

Also, users already submit bugs reduced multi-TU bugs to us in approximately this format. Examples:
https://bugs.llvm.org/show_bug.cgi?id=33598
https://bugs.llvm.org/show_bug.cgi?id=33542
https://bugs.llvm.org/show_bug.cgi?id=33624

I prefer bug reports like this over ones with an attached tarball or zip archive. If we agree (maybe we don't) that this is a good way to describe a multi-TU bug to a developer, then it follows that our test suite should support a test format that looks like these bug reports.

---

I have used the C pre-processor as you describe to write ABI handshake tests. They looked kind of like this:

  // RUN: %clang -c %s -o t1.obj
  // RUN: %clang -c %s -o t2.obj -DFOO
  // RUN: %clang t1.obj t2.obj -o t.exe && ./t.exe
  struct NonTrivial { int x; NonTrivial(const NonTrivial &); };
  int foo(NonTrivial o);
  #ifdef FOO
  int foo(NonTrivial o) { return o.x; }
  #else
  int main() {
    NonTrivial o;
    o.x = 42;
    return foo(o);
  }
  #endif

... and I'd like to have that capability for non-C tests that need multiple input files.


https://reviews.llvm.org/D34764