https://github.com/shafik commented:
Flagging what looks like a bug
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1212,6 +1212,14 @@ static void handlePreferredName(Sema &S, Decl *D, const
ParsedAttr &AL) {
<< TT->getDecl();
}
+static void handleNoSpecializations(Sema &S, Decl *D, const ParsedAttr &AL) {
+ StringRef Message;
+ if (AL.getNumArgs() != 0)
+S.checkStringLit
https://github.com/shafik edited
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/philnik777 closed
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/AaronBallman approved this pull request.
LGTM!
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
philnik777 wrote:
@AaronBallman @cor3ntin are you happy as well?
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/philnik777 updated
https://github.com/llvm/llvm-project/pull/101469
>From 82ab798fc72c6de64ae527d96393f0dc67307e98 Mon Sep 17 00:00:00 2001
From: Nikolas Klauser
Date: Thu, 1 Aug 2024 12:30:22 +0200
Subject: [PATCH 1/8] [Clang] Add [[clang::diagnose_specializations]]
---
cl
@@ -473,6 +473,7 @@ def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
def FlagEnum : DiagGroup<"flag-enum">;
def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
def InfiniteRecursion : DiagGroup<"infinite-recursion">;
+def InvalidSpecialization
@@ -5445,6 +5445,10 @@ def note_dependent_function_template_spec_discard_reason
: Note<
"candidate ignored: %select{not a function template|"
"not a member of the enclosing %select{class template|"
"namespace; did you mean to explicitly qualify the specialization?}1}0">;
@@ -473,6 +473,7 @@ def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
def FlagEnum : DiagGroup<"flag-enum">;
def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
def InfiniteRecursion : DiagGroup<"infinite-recursion">;
+def InvalidSpecialization
@@ -473,6 +473,7 @@ def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
def FlagEnum : DiagGroup<"flag-enum">;
def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
def InfiniteRecursion : DiagGroup<"infinite-recursion">;
+def InvalidSpecialization
@@ -473,6 +473,7 @@ def ExpansionToDefined : DiagGroup<"expansion-to-defined">;
def FlagEnum : DiagGroup<"flag-enum">;
def IncrementBool : DiagGroup<"increment-bool", [DeprecatedIncrementBool]>;
def InfiniteRecursion : DiagGroup<"infinite-recursion">;
+def InvalidSpecialization
@@ -1155,6 +1155,15 @@ Query for this feature with
``__has_attribute(diagnose_if)``.
}];
}
+def NoSpecializationsDocs : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+``[[clang::no_specializations]]`` can be applied to function, class or variable
---
@@ -4637,7 +4649,7 @@ def HLSLResourceBinding: InheritableAttr {
let AdditionalMembers = [{
public:
enum class RegisterType : unsigned { SRV, UAV, CBuffer, Sampler, C, I };
-
+
erichkeane wrote:
Please don't commit hte unrelated formatting changes.
@@ -7197,10 +7206,10 @@ alternatives, though the attribute can be used even
when the fix can't be automa
and then use the attribute on the original ``baz()`` to help the users
update their code to use the new function.
-* Attribute attached to fields: The attribute should
https://github.com/erichkeane approved this pull request.
Nits only, otherwise LGTM.
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/erichkeane edited
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/philnik777 updated
https://github.com/llvm/llvm-project/pull/101469
>From 82ab798fc72c6de64ae527d96393f0dc67307e98 Mon Sep 17 00:00:00 2001
From: Nikolas Klauser
Date: Thu, 1 Aug 2024 12:30:22 +0200
Subject: [PATCH 1/7] [Clang] Add [[clang::diagnose_specializations]]
---
cl
@@ -981,6 +981,15 @@ Query for this feature with
``__has_attribute(diagnose_if)``.
}];
}
+def NoSpecializationsDocs : Documentation {
+ let Category = DocCatDecl;
+ let Content = [{
+``[[clang::no_specializations]]`` can be applied to class or variable
er
https://github.com/erichkeane commented:
No real comments, other than FunctionTemplate being left out of the
documentation.
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org
https://github.com/erichkeane edited
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
philnik777 wrote:
> > I went for only adding `[[clang::no_specialization]]` to function
> > templates, since the other cases seem even more unlikely to me and seem to
> > have a higher implementation complexity. Is that OK?
>
> Your test coverage also handles class templates and variable templ
AaronBallman wrote:
> I went for only adding `[[clang::no_specialization]]` to function templates,
> since the other cases seem even more unlikely to me and seem to have a higher
> implementation complexity. Is that OK?
Your test coverage also handles class templates and variable templates in
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff bfe486fe764667d514124faf2b39afb7e7322640
5dd5dd4e7a7733412fb20368202c657f97b635a2 --e
philnik777 wrote:
I went for only adding `[[clang::no_specialization]]` to function templates,
since the other cases seem even more unlikely to me and seem to have a higher
implementation complexity. Is that OK?
https://github.com/llvm/llvm-project/pull/101469
_
https://github.com/philnik777 updated
https://github.com/llvm/llvm-project/pull/101469
>From 82ab798fc72c6de64ae527d96393f0dc67307e98 Mon Sep 17 00:00:00 2001
From: Nikolas Klauser
Date: Thu, 1 Aug 2024 12:30:22 +0200
Subject: [PATCH 1/6] [Clang] Add [[clang::diagnose_specializations]]
---
cl
cor3ntin wrote:
The list is there https://eel.is/c++draft/temp.expl.spec#1
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
philnik777 wrote:
> > > > I did think about it more, and I think it would be more consistent to
> > > > support the attribute on any sort of specializable entity, including
> > > > functions - regardless of STL needs @AaronBallman @ldionne
> > >
> > >
> > > Agreed; if we're adding a custom at
AaronBallman wrote:
> > > I did think about it more, and I think it would be more consistent to
> > > support the attribute on any sort of specializable entity, including
> > > functions - regardless of STL needs @AaronBallman @ldionne
> >
> >
> > Agreed; if we're adding a custom attribute, w
philnik777 wrote:
> > I did think about it more, and I think it would be more consistent to
> > support the attribute on any sort of specializable entity, including
> > functions - regardless of STL needs @AaronBallman @ldionne
>
> Agreed; if we're adding a custom attribute, we might as well s
AaronBallman wrote:
> I did think about it more, and I think it would be more consistent to support
> the attribute on any sort of specializable entity, including functions -
> regardless of STL needs @AaronBallman @ldionne
Agreed; if we're adding a custom attribute, we might as well support i
cor3ntin wrote:
I did think about it more, and I think it would be more consistent to support
the attribute on any sort of specializable entity, including functions -
regardless of STL needs @AaronBallman @ldionne
https://github.com/llvm/llvm-project/pull/101469
___
philnik777 wrote:
> Does it makes sense to also support function templates? For example, my
> understanding is that specializing `is_pointer_interconvertible_with_class()`
> would be UB
I can't find anything explicit about function template specializations, so I'm
not 100% sure whether it's a
cor3ntin wrote:
Does it makes sense to also support function templates?
For example, my understanding is that specializing
`is_pointer_interconvertible_with_class()` would be UB
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing
https://github.com/cor3ntin edited
https://github.com/llvm/llvm-project/pull/101469
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
35 matches
Mail list logo
