On Tue, Jul 30, 2013 at 3:52 PM, Manuel Klimek <[email protected]> wrote:
> I think the main reasons why using a structured format instead of patches > here are: > The upside of "patch" formats doesn't apply here: patches are great if you > want them to apply on potentially unknown slightly different revisions. > Otherwise I don't see big pros for patches. > On the other hand, patches have a major downside here: > a) they're too coarse - they're usually line based; refactoring tools > often need to handle replacements that fix stuff (non-overlapping) on the > same line > b) they're hard to "work with" other than applying them; patch libraries > usually just give you that, so if you want to extract the exact ranges on > what is changing (for example to do deduplication, or to do other location > based calculations) you're re-writing your own patch-parsing code > c) they're much harder to generate from a clang-tool; > offset+length+replacement is something you just "have", no need to > construct the actual end-result and run algorithms over the strings in the > tool > > To me patches are basically an optional 3rd level interface here, but we > need something more fine grained in a structured format. Using YAML (or > JSON) seems an obvious choice for that in the llvm context. > All of this sounds like a great email to have on an email thread that actually is discussing the design. This is a reply N replies down on a commit with build bot failures mixed in. This needs to be discussed in a better forum.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
