On a high-level note: I think we should aim for making the tool independent
of the cpp11 migration. That would also mean putting the definitions on how to
store the replacements etc somewhere into Tooling/, and having the functions
for how to apply those replacements in Tooling/, too. I think if necessary we
can do that later (as that requires some significant design bike-shedding) but
I'd really want to see that plan documented in FIXMEs.
Now regarding some design issues:
- you're talking about changes "for headers"; I wouldn't actually treat
headers special here, I'd just have changes on files; if you want the main
source file, so you can validate the header changes, I'd rather propose a full
re-parsing post-processing step - after all, a header can be used from many
TUs, and only a full build will tell whether seomthing broke
- I dislike the name migmerge - both because I think "mig" (probably short
for "migrate") doesn't really help, and it's not really a "merge" - it's more
something that applies changes; I don't feel that strongly about it, though,
and unless I can come up with a better name, feel free to leave it for now.
================
Comment at: test/migmerge/conflict/file3.yaml:2
@@ +1,3 @@
+---
+TransformID: "Blah"
+Replacements:
----------------
Is the TransformID actually used for anything?
================
Comment at: cpp11-migrate/Core/ApplyChangeDescriptions.cpp:66
@@ +65,3 @@
+bool applyChangeDescriptions(const StringRef Directory,
+ DiagnosticsEngine &Diagnostics) {
+
----------------
I think this function can be split up a lot more :)
http://llvm-reviews.chandlerc.com/D1382
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
