[PATCH] D44609: [clang-format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)
Alundra added a comment.
@Wawha In the same style of this missing feature, I think you are also aware of
the miss of clang-format about struct/array initializer like:
https://bugs.llvm.org/show_bug.cgi?id=40411
Basically to have the break for braces after the '=' of the struct/array
initializer like this example:
const FMOD_3D_ATTRIBUTES Attributes =
{
{ WorldPosition.x, WorldPosition.y, WorldPosition.z },
{ 0.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, 1.0f },
{ 0.0f, 1.0f, 0.0f }};
Actually with the indent configured you end with something like:
const FMOD_3D_ATTRIBUTES Attributes =
{
{ WorldPosition.x, WorldPosition.y, WorldPosition.z },
{ 0.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, 1.0f },
{ 0.0f, 1.0f, 0.0f }};
The only way right now is to have the '{' after the '=' but that breaks your
coding style:
const FMOD_3D_ATTRIBUTES Attributes = {
{ WorldPosition.x, WorldPosition.y, WorldPosition.z },
{ 0.0f, 0.0f, 0.0f },
{ 0.0f, 0.0f, 1.0f },
{ 0.0f, 1.0f, 0.0f }};
That looks like on the same topic about braces controls missing feature.
Since you look very familiar, it can be for you a next challenge to add that in
clang format?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D44609/new/
https://reviews.llvm.org/D44609
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D44609: [Clang-Format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)
Alundra added a comment. Please review and consider a merge of this change which looks to not have news since long time. It's useful for a lot of people and it's awesome that there is a ready or almost ready patchset about it. Thanks a lot! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D44609/new/ https://reviews.llvm.org/D44609 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D29944: libclang: Print namespaces for typedefs and type aliases
redm123 added a comment. I guess so. I don't think I'm allowed to commit. So I would appreciate it. Which release version would that be in? 4.1 I guess? Thanks for your help! https://reviews.llvm.org/D29944 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D29944: libclang: Print namespaces for typedefs and type aliases
redm123 added a comment. Any idea how to continue with that? Should I add another reviewer? Whom? https://reviews.llvm.org/D29944 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D29944: libclang: Print namespaces for typedefs and type aliases
redm123 added inline comments.
Comment at: test/Misc/diag-template-diffing.cpp:27
// CHECK-ELIDE-NOTREE: no matching function for call to 'f'
-// CHECK-ELIDE-NOTREE: candidate function not viable: no known conversion from
'vector' to 'vector' for 1st argument
+// CHECK-ELIDE-NOTREE: candidate function not viable: no known conversion from
'vector' to 'vector' for 1st argument
// CHECK-NOELIDE-NOTREE: no matching function for call to 'f'
redm123 wrote:
> arphaman wrote:
> > I think the majority of test changes make sense, we are just adding
> > qualifiers to the typedefs in the diagnostics. I'm curious about this one
> > though, as we are essentially replacing the old diagnostic note `no known
> > conversion from 'vector' to 'vector' for
> > 1st argument` by the new note `no known conversion from
> > 'vector' to 'vector' for 1st argument`. Is one better
> > than the other? It seems that GCC prefers the former, while ICC the latter.
> > Does it even matter which one we have?
> Right, wanted to add a note... forgot about that. This "fix" here is probably
> entirely nonsense. I guess I broke some other feature here. I was hoping for
> some input from the review ;) As I see it it's supposed to print the
> canonical type in case both types would be printed the same, but apparently
> the comparison breaks. The question where this happens... I'll try to dig
> through the history and see if I find something.
So the problematic place seems to be in lib/AST/ASTDiagnostic.cpp:
PrintTypeNames() which compares the printed type names, and as this
versa_string has no namespace it breaks... We could restore the old behavior
for these tests with something like:
Index: lib/AST/ASTDiagnostic.cpp
===
--- lib/AST/ASTDiagnostic.cpp (revision 294732)
+++ lib/AST/ASTDiagnostic.cpp (working copy)
@@ -1612,10 +1612,12 @@
return;
}
+PrintingPolicy ComparePolicy = Policy;
+ComparePolicy.SuppressScope = true;
std::string FromTypeStr = FromType.isNull() ? "(no argument)"
-:
FromType.getAsString(Policy);
+:
FromType.getAsString(ComparePolicy);
std::string ToTypeStr = ToType.isNull() ? "(no argument)"
-: ToType.getAsString(Policy);
+:
ToType.getAsString(ComparePolicy);
// Switch to canonical typename if it is better.
// TODO: merge this with other aka printing above.
if (FromTypeStr == ToTypeStr) {
But as this disables namespace scopes also for normal types (not just
typedefs), things now break further down...
So what would be a proper fix...?
If I see it right this test case only breaks in the first place because it uses
typedefs and no namespaces were printed for typedefs up to now. I.e. you get
"no known conversion from 'vector' to 'vector'", as the comment
says, which is indeed somewhat ambiguous. With my patch you now get "no known
conversion from 'vector' to 'vector'" ... better.
Interestingly if you have the same example with no typedefs, but just "class
string;", you get the same error, as in case of non-typedefs the namespaces
were always printed. In this case it seems to be sufficiently non-ambiguous.
**So**: As with my patch we seem to achive the same result, we could also
remove this entire test, because this case can't happen anymore.
**Further so**: Actually we might also remove the entire check and fallback to
canonical types in PrintTypeNames(), as this also can't happen anymore...
At least AFACIS...
Thoughts?
https://reviews.llvm.org/D29944
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D29944: libclang: Print namespaces for typedefs and type aliases
redm123 added inline comments. Comment at: test/Misc/diag-template-diffing.cpp:27 // CHECK-ELIDE-NOTREE: no matching function for call to 'f' -// CHECK-ELIDE-NOTREE: candidate function not viable: no known conversion from 'vector' to 'vector' for 1st argument +// CHECK-ELIDE-NOTREE: candidate function not viable: no known conversion from 'vector' to 'vector' for 1st argument // CHECK-NOELIDE-NOTREE: no matching function for call to 'f' arphaman wrote: > I think the majority of test changes make sense, we are just adding > qualifiers to the typedefs in the diagnostics. I'm curious about this one > though, as we are essentially replacing the old diagnostic note `no known > conversion from 'vector' to 'vector' for 1st > argument` by the new note `no known conversion from 'vector' to > 'vector' for 1st argument`. Is one better than the other? It seems > that GCC prefers the former, while ICC the latter. Does it even matter which > one we have? Right, wanted to add a note... forgot about that. This "fix" here is probably entirely nonsense. I guess I broke some other feature here. I was hoping for some input from the review ;) As I see it it's supposed to print the canonical type in case both types would be printed the same, but apparently the comparison breaks. The question where this happens... I'll try to dig through the history and see if I find something. https://reviews.llvm.org/D29944 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D29944: libclang: Print namespaces for typedefs and type aliases
redm123 added a comment. In https://reviews.llvm.org/D29944#678033, @arphaman wrote: > Do these diagnostics have the full qualifiers for errors that occur with > record types instead of typedefs? Not sure what you mean by that, but as far as I can see all the changed errors refer to typedefs/aliases. Normal records types should not be affected. https://reviews.llvm.org/D29944 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[PATCH] D29944: libclang: Print namespaces for typedefs and type aliases
redm123 created this revision.
Printing typedefs or type aliases using clang_getTypeSpelling() is missing the
namespace they are defined in. This is in contrast to other types that always
yield the full typename including namespaces.
https://reviews.llvm.org/D29944
Files:
lib/AST/TypePrinter.cpp
test/CXX/basic/basic.lookup/basic.lookup.qual/class.qual/p2.cpp
test/CXX/drs/dr2xx.cpp
test/CXX/drs/dr5xx.cpp
test/Index/annotate-nested-name-specifier.cpp
test/Index/file-refs.cpp
test/Index/print-type.cpp
test/Index/recursive-cxx-member-calls.cpp
test/Layout/ms-x86-basic-layout.cpp
test/Misc/diag-template-diffing.cpp
test/SemaCXX/attr-noreturn.cpp
test/SemaCXX/calling-conv-compat.cpp
test/SemaCXX/coroutines.cpp
test/SemaCXX/cxx0x-initializer-aggregates.cpp
test/SemaCXX/cxx1y-contextual-conversion-tweaks.cpp
test/SemaCXX/enum-scoped.cpp
test/SemaCXX/nested-name-spec.cpp
test/SemaCXX/pseudo-destructors.cpp
test/SemaObjCXX/arc-templates.mm
test/SemaTemplate/member-access-ambig.cpp
test/SemaTemplate/typename-specifier.cpp
Index: test/SemaTemplate/typename-specifier.cpp
===
--- test/SemaTemplate/typename-specifier.cpp
+++ test/SemaTemplate/typename-specifier.cpp
@@ -102,7 +102,7 @@
template struct E {
typedef typename T::foo foo;
- typedef typename foo::bar bar; // expected-error {{type 'foo' (aka 'double') cannot be used prior to '::' because it has no members}}
+ typedef typename foo::bar bar; // expected-error {{type 'E::foo' (aka 'double') cannot be used prior to '::' because it has no members}}
};
struct F {
Index: test/SemaTemplate/member-access-ambig.cpp
===
--- test/SemaTemplate/member-access-ambig.cpp
+++ test/SemaTemplate/member-access-ambig.cpp
@@ -48,7 +48,7 @@
typedef int (A::*P);
template struct S : T {
void f() {
- P(::X) // expected-error {{cannot cast from type 'int *' to member pointer type 'P'}}
+ P(::X) // expected-error {{cannot cast from type 'int *' to member pointer type 'AddrOfMember::P'}}
== ::X;
}
};
Index: test/SemaObjCXX/arc-templates.mm
===
--- test/SemaObjCXX/arc-templates.mm
+++ test/SemaObjCXX/arc-templates.mm
@@ -102,8 +102,8 @@
template
struct make_weak_fail {
typedef T T_type;
- typedef __weak T_type type; // expected-error{{the type 'T_type' (aka '__weak id') is already explicitly ownership-qualified}} \
- // expected-error{{the type 'T_type' (aka '__strong id') is already explicitly ownership-qualified}}
+ typedef __weak T_type type; // expected-error{{the type 'make_weak_fail<__weak id>::T_type' (aka '__weak id') is already explicitly ownership-qualified}} \
+ // expected-error{{the type 'make_weak_fail::T_type' (aka '__strong id') is already explicitly ownership-qualified}}
};
int check_make_weak_fail0[is_same::type, __weak id>::value? 1 : -1]; // expected-note{{in instantiation of template class 'make_weak_fail<__weak id>' requested here}}
Index: test/SemaCXX/pseudo-destructors.cpp
===
--- test/SemaCXX/pseudo-destructors.cpp
+++ test/SemaCXX/pseudo-destructors.cpp
@@ -109,6 +109,6 @@
void test2(Foo d) {
d.~Foo(); // This is ok
- d.~Derived(); // expected-error {{member reference type 'Foo' (aka 'dotPointerAccess::Derived *') is a pointer; did you mean to use '->'}}
+ d.~Derived(); // expected-error {{member reference type 'dotPointerAccess::Foo' (aka 'dotPointerAccess::Derived *') is a pointer; did you mean to use '->'}}
}
}
Index: test/SemaCXX/nested-name-spec.cpp
===
--- test/SemaCXX/nested-name-spec.cpp
+++ test/SemaCXX/nested-name-spec.cpp
@@ -310,7 +310,7 @@
}
namespace TypedefNamespace { typedef int F; };
-TypedefNamespace::F::NonexistentName BadNNSWithCXXScopeSpec; // expected-error {{'F' (aka 'int') is not a class, namespace, or enumeration}}
+TypedefNamespace::F::NonexistentName BadNNSWithCXXScopeSpec; // expected-error {{'TypedefNamespace::F' (aka 'int') is not a class, namespace, or enumeration}}
namespace PR18587 {
@@ -449,7 +449,7 @@
class B {
typedef C D; // expected-error{{unknown type name 'C'}}
A::D::F;
- // expected-error@-1{{'D' (aka 'int') is not a class, namespace, or enumeration}}
+ // expected-error@-1{{'PR30619::A::B::D' (aka 'int') is not a class, namespace, or enumeration}}
};
}
}
Index: test/SemaCXX/enum-scoped.cpp
===
--- test/SemaCXX/enum-scoped.cpp
+++ test/SemaCXX/enum-scoped.cpp
@@ -307,5 +307,5 @@
typedef E E2;
E2 f1() { return E::a; }
- bool f() { return !f1(); } // expected-error {{invalid argument type 'E2' (aka 'test11::E') to unary expression}}
+ bool f() { return !f1(); } //
