HazardyKnusperkeks added inline comments.

================
Comment at: clang/unittests/Format/FormatTest.cpp:21916
 
   // Lambdas with different indentation styles.
+  Style = getLLVMStyleWithColumns(60);
----------------
jp4a50 wrote:
> MyDeveloperDay wrote:
> > jp4a50 wrote:
> > > MyDeveloperDay wrote:
> > > > Why are you changing existing tests
> > > Sorry about the rather large diff here.
> > > 
> > > I have made the following changes to existing tests (all for what I think 
> > > are good reasons):
> > > 
> > >   - Reduced the column limit and then reduced the verbosity of the code 
> > > samples in the test to make them more readable. Before the column limit 
> > > was 100 and the code samples were very long. I found this made them 
> > > unnecessarily difficult to read, especially because some of the lines of 
> > > the code sample would wrap before a newline in the code itself, which was 
> > > confusing.
> > >   - Changed a number of tests written in the form `EXPECT_EQ(code, 
> > > format(otherCode))` to simply `verifyFormat(code)` because the latter is 
> > > much shorter and easier to read. If you can think of a good reason to 
> > > favour the former over the latter then let me know but it just seemed 
> > > like unnecessary duplication to me.
> > >   - Some of the tests weren't syntactically valid C++ e.g. the tests at 
> > > line 21939 which I have changed to have a valid (rather than incomplete) 
> > > trailing return type.
> > >   - The macro test actually captured a bug so I had to change the code 
> > > sample there to reflect the now fixed behaviour.
> > > 
> > > I also added one or two more tests at the bottom to capture more complex 
> > > cases like when more than one argument to a function call is a lambda. 
> > > 
> > > 
> > refactoring the tests is one thing, but not at the same time you are 
> > modifying how they are formatted. Could it be a separate commit so we can 
> > actually see what is changing?
> > 
> > I don't deny what is there before doesn't look 100% correct, but I've 
> > always worked on the Beyoncé rule  (If you liked it you should have put a 
> > test on it), meaning... someone put a test there to assert some form of 
> > formatting behaviour, you are now changing that to be your desired 
> > behaviour, that break the rule (IMHO)
> > 
> > we have to agree what was there before wasn't correct, but your changes 
> > don't give me that confidence, 
> > refactoring the tests is one thing, but not at the same time you are 
> > modifying how they are formatted. Could it be a separate commit so we can 
> > actually see what is changing?
> 
> Sure! I assume that this implies two separate Phabricator reviews/diffs? Or 
> is there somehow a way to show two "commits" within a single review? Sorry, 
> I'm not used to using Phrabricator.
> 
> > I don't deny what is there before doesn't look 100% correct, but I've 
> > always worked on the Beyoncé rule  (If you liked it you should have put a 
> > test on it), meaning... someone put a test there to assert some form of 
> > formatting behaviour, you are now changing that to be your desired 
> > behaviour, that break the rule (IMHO)
> 
> The macro example I was referring to as a "bug" actually had a comment below 
> it which seemed to acknowledge an issue with the previous implementation. Now 
> I'm not 100% sure that that comment was referring to the behaviour in the 
> macro example but what does seem clear is that the behaviour shown in the 
> macro test case is not desirable in the case of using `OuterScope`. I just 
> can't see how that behaviour could be justified as being 
> intentional/desirable. If you wanted, I could reach out to the original 
> author of that test and ask them since they still work at the same company.
> 
> > we have to agree what was there before wasn't correct, but your changes 
> > don't give me that confidence, 
> 
> I'd appreciate if you could elaborate on this - perhaps you're referring 
> mainly to the macro example but I'm not sure.
Each commit gets its own differential, there are no multiple commit reviews 
like pull requests. You can add a parent or child commit to show the 
dependency, if any.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146042/new/

https://reviews.llvm.org/D146042

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to