It occurred to me that eol detection won't work reliably. Especially for
tests, someone will write a compilation database by hand and check it in.
Maybe they have git set to convert newlines for them, and we don't want a
test to behave differently based on your source control settings.
The target
I agree that it can be annoying to say "hey guys, i would normally do post
commit review on this, but i wanted to give the courtesy of a heads up",
and then potentially waiting an indeterminate amount of time.
I think that actually discourages these kind of changes going up at all,
because people
Should we add overloads of the UTF8 conversion functions that accept
wstrings?
In line with what rnk said, I'm curious about the implications of simply
#undef'ing all the non A/W versions of functions so that you have to make
the choice explicit
On Thu, Jun 23, 2016 at 8:20 AM Reid Kleckner wrote
zturner accepted this revision.
zturner added a comment.
This revision is now accepted and ready to land.
Looks good, do you have commit access to commit this?
http://reviews.llvm.org/D21946
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
ht
zturner added a comment.
In http://reviews.llvm.org/D21946#473070, @comicfans44 wrote:
> I've not commited to cfe before, so I think I havn't commit access permission.
If you've committed anywhere in LLVM, you should have commit access to cfe.
Feel free to give it a try, as I won't be able to
Better yet, just delete the number
On Mon, Mar 7, 2016 at 6:21 AM Aaron Ballman
wrote:
> aaron.ballman added inline comments.
>
>
> Comment at: clang.natvis:1-3
> @@ -1,4 +1,4 @@
>
> Do you know if these visualizers will work in MSVC 2013 as well, or are
> you using MSVC 2015
zturner added a subscriber: zturner.
zturner added a comment.
Better yet, just delete the number
http://reviews.llvm.org/D17908
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zturner added a comment.
Natvis has hardly changed at all since it was introduced, so I'm guessing
the lowest common denominator is always going to be our minimum required VS
version
http://reviews.llvm.org/D17908
___
cfe-commits mailing list
cfe-co
Natvis has hardly changed at all since it was introduced, so I'm guessing
the lowest common denominator is always going to be our minimum required VS
version
On Mon, Mar 7, 2016 at 7:09 AM Aaron Ballman
wrote:
> aaron.ballman added a comment.
>
> In http://reviews.llvm.org/D17908#368969, @zturner
For vs2015, the files still need to be in the project right? (In the
vcxproj with a tag)
On Sun, Mar 27, 2016 at 9:09 AM Mike Spertus wrote:
> mspertus updated this revision to Diff 51741.
> mspertus added a comment.
>
> Apply whitespace comments from http://reviews.llvm.org/D18497 mutatis
> mut
Yea, CMake doesn't actually support natvis files. You'd have to actually
patch CMake to make it work.
Can you make the vs2015 and vs2013 paths the same? It will still work for
2015 i think, just that 2015 also supports putting them in the project file
On Sun, Mar 27, 2016 at 10:04 AM Mike Spertus
Code paths. For vs2013 you're installing the natvis files, can we just do
that for vs2015 as well?
On Sun, Mar 27, 2016 at 11:23 AM Mike Spertus wrote:
> mspertus added a comment.
>
> What do you mean by "making both paths the same"?
>
>
> http://reviews.llvm.org/D18498
>
>
>
>
__
If it's not using a natvis tag in the vcxproj (which it isn't since CMake
doesn't support it during generation) then the new natvis project file
support won't work right? In which case the files would need to be copied
into documents\vs2015, otherwise it won't work, unless I'm misunderstanding
some
Ahh that's surprising. If it works even with the none tag, i guess my
concerns are not valid
On Sun, Mar 27, 2016 at 12:11 PM Mike Spertus wrote:
> mspertus added a comment.
>
> No. Testing shows that it works fine in the project with the `` tag.
> VS2015 empirically looks at the extension.
>
>
>
Yea sounds fine
On Sun, Mar 27, 2016 at 12:20 PM Mike Spertus wrote:
> mspertus added a comment.
>
> I understand your concerns, but on balance, I don't see a better course of
> action than what I've done. If I have some time, I'll submit a CMake change
> so we can eventually migrate to having CM
zturner added a subscriber: zturner.
zturner added a comment.
What needs to happen for this to go in? If I understand correctly, it is
either:
1. Add a new option `TreatDeclarationsLikeDefinitions`
2. Merge this option into `AlwaysBreakAfterDefinitionReturnType` and make it an
enum with 5 valu
zturner added a comment.
In http://reviews.llvm.org/D10370#309789, @djasper wrote:
> I think we can add the option AlwaysBreakAfterReturnType but still be
> backwards compatible. If clang-format finds only the old option in a
> configuration file, it can choose the appropriate value of the new
zturner updated this revision to Diff 42774.
zturner added a comment.
This patch was very old, so it didn't apply against ToT. So this initial
update is just to rebase against ToT. I will make changes in a followup patch.
http://reviews.llvm.org/D10370
Files:
include/clang/Format/Format.h
zturner updated this revision to Diff 42895.
zturner added a comment.
Attempt to address remaining issues in patch.
This is my first time touching anything having to do with clang, so there's a
good chance I don't know what i'm doing and this needs more work. Let me know.
`AlwaysBreakAfterDefi
zturner added a comment.
ping
http://reviews.llvm.org/D10370
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
zturner added inline comments.
Comment at: lib/Format/TokenAnnotator.h:168
@@ -158,1 +167,3 @@
+ bool mustBreakForReturnType(const AnnotatedLine &Line,
+ FormatToken &Token) const;
djasper wrote:
> Some comment might help. E.g. at t
Author: zturner
Date: Fri Dec 18 16:20:15 2015
New Revision: 256046
URL: http://llvm.org/viewvc/llvm-project?rev=256046&view=rev
Log:
Support AlwaysBreakAfterReturnType
This changes the behavior of AlwaysBreakAfterDeclarationReturnType
so that it supports breaking after declarations, definitions,
Author: zturner
Date: Fri Dec 18 16:58:42 2015
New Revision: 256055
URL: http://llvm.org/viewvc/llvm-project?rev=256055&view=rev
Log:
Fix invalid enum comparison.
Modified:
cfe/trunk/unittests/Format/FormatTest.cpp
Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL:
http://llvm.org/vie
201 - 223 of 223 matches
Mail list logo
