Details
- Reviewers
klimek cfe-commits
Diff Detail
Event Timeline
lib/Format/Format.cpp | ||
---|---|---|
1594–1598 | Perhaps document that Includes needs to be in strict source order. | |
1624 | You'll probably want to allow more spaces if this is run before formatting: | |
1632–1634 | Having the ! case first without early exit confused me. | |
1642–1644 | Why does this work if Pos is npos here? Or can that not happen? | |
1647 | Here I can see that npos doens't matter, because we'll not re-use Prev. | |
tools/clang-format/ClangFormat.cpp | ||
218 | Call this outputReplacementsXML (so it's consistent with outputReplacementXML), or rename all. | |
244–249 | Aren't now the ranges incorrect? | |
279 | This is not atomic, which has been a problem in the past (and which is why the rewriter's overwriteChangedFiles is carefully crafted).
Alternatively, do not support include sorting and clang-format in the same run and have editor integrations do 2 calls (?) | |
unittests/Format/SortIncludesTest.cpp | ||
32–37 | Nit: I find it slightly distracting that we're not calling them a.h, b.h, c.h (and perhaps have one test that checks that they support longer filenames). | |
51–60 | Do we want to sort C vs C++ system headers? |
lib/Format/Format.cpp | ||
---|---|---|
1642–1644 | Simplified so that this isn't an issue any more. | |
1647 | Ack. | |
tools/clang-format/ClangFormat.cpp | ||
244–249 | So, there are two cases:
| |
279 | Yes, using a second rewriter or recomputing the affected ranges is a significant calculation for the sole purpose of un-doing the offsets calculated in the rewriter. Furthermore, we already have the new code after #include sorting, which we simply calculate again, which seems like wasted efforts. I don't know how the non-atomic-write has been a problem, but if it is, I'd prefer to pull out a function or the AtomicallyMovedFile. I am strongly against letting this be handled by editor integrations so that the integrations exhibit consistent behavior and that we don't need to implement this N times. | |
unittests/Format/SortIncludesTest.cpp | ||
51–60 | Yes, but I want to do refinements to the actual sorting in a follow up. I have a bunch of ideas. |
tools/clang-format/ClangFormat.cpp | ||
---|---|---|
279 | I don't understand yet why we can't use 1 rewriter. The rewriter should automatically use the updated ranges after we did the fixes, shouldn't it? I definitely think we'll need to have 2 different runs anyway for all integrations that run on replacements, or otherwise we'd need to somehow group replacements in a way that it's clear in which order they need to be applied, and when the basis for the calculation of the ranges changes. | |
unittests/Format/SortIncludesTest.cpp | ||
51–60 | SG |
tools/clang-format/ClangFormat.cpp | ||
---|---|---|
279 | That's exactly what the rewriter does. It simply doesn't help us at all in this case. Other than writing the file atomically, it only makes our life harder. I think clang-format outputting the replacements in the order in which they need to applied makes sense and is significantly easier to integrate with than a two-phase run. |
tools/clang-format/ClangFormat.cpp | ||
---|---|---|
279 | I'll need to tinker with that myself, but that's not a blocker. I'm still unhappy with the interface though. I think having a list of replacements where you can't select a single one and apply it is a very subtle interface. Have you tested this with the eclipse / visual studio integration? |
tools/clang-format/ClangFormat.cpp | ||
---|---|---|
279 | Oooo... I have a good idea to fix both of these things. Let me rewrite some stuff. |
Added an alternative way to handle the two sets of Replacements: Merge them properly.
I haven't completely finished implementing / testing this. Wanted to get feedback first before going further down this road.
Now properly implemented merging of two replacement sets that are meant to be applied in sequence. I think this functionality will also be highly useful, e.g. when formatting the result of a clang-tidy fix or many other such things.
First round of comments; some things are still a bit confusing, so I hope another round will help to weed them out.
include/clang/Tooling/Core/Replacement.h | ||
---|---|---|
223–224 | s/to/two/ | |
lib/Format/Format.cpp | ||
1612–1620 | I think this wants a comment along the lines of: | |
1644 | Do we want to use \s instead of "\ " so this also works for tab-using codebases? | |
1651 | I'd have expected early exit, but I can see it'd introduce a one-line duplication. Not sure, just wanted to bring it up. | |
1660–1663 | Nit: I think this would be a bit more readable if we only call sortInlucdes if !IncludesInBlock.empty() and add that as condition to the else. | |
lib/Tooling/Core/Replacement.cpp | ||
310–313 | Nit: remove the first ','. | |
314 | Would be good to learn up here why SecondI == Second.end() implies "an element from 'Second' needs to be merged". | |
332–336 | This structure looks like we'd want 2 functions. I assume you had reasons not to pull out two local functions? What are they? Too many parameters? (I'd probably pull out a class to be able to put this into smaller methods, but I'm probably weird). | |
341 | If SecondI == Second.end(), isn't this an undefined access? | |
354 | I'm surprised the explicit Twine() is needed here... |
lib/Format/Format.cpp | ||
---|---|---|
1651 | It's actually three lines I think. Also, I think we'll significantly extend the logic here shortly (e.g. to properly support Google and LLVM styles), so I don't think it is worth thinking about too much. | |
1660–1663 | Done and removed the check inside sortIncludes. | |
lib/Tooling/Core/Replacement.cpp | ||
332–336 | Maybe a class would be the way to go here. I'll try in a subsequent patch (don't think it should be a priority at this point). | |
341 | Cannot happen. The while starts with MergeSecond && SecondI != Second.end(). | |
354 | How else would this know to use a Twine for efficient concatenation? |
Restructured a bit. Not as many comments just yet. Do you think this is an improvement?
Sending another batch of comments.
lib/Tooling/Core/Replacement.cpp | ||
---|---|---|
305–307 | Merge the two sets which are each sorted by offset:
Invariants:
Position projections:
| |
308–309 | Comment: (not sure whether that comment carries it's weight; I started it because it took me a moment to figure out why we don't compute which one to take next during merging, and it's a bit more complex, but not sure where to put the comment yet; basically, the problem is that if the next replacement at the end doesn't overlap, it might also be after a non-overlapping replacement from the other set, which I think is not entirely obvious). | |
310–314 | Ok, I think I now understand what confuses me here: For me calling this: | |
326 | This I'm less sure about, but I think 'Text' is somewhat ambiguous here - perhaps 'MergedReplaceWith'? | |
354 | There are various overloads of + that yield Twine? |
s/to/two/