@@ -515,26 +515,94 @@ namespace {
Call
};
+ /// Either a FunctionDecl or an ObjCMethodDecl. This struct papers over the
+ /// fact that their common ancestors are DeclContext and NamedDecl, which
+ /// does not allow the enumeration of their parameters very easily.
+
rjmccall wrote:
I haven't looked at your patch yet, and I'm not familiar with the `diagnose_if`
feature; I'm just commenting about the AST design question because I was tagged
in to do so. If `diagnose_if` is about compile-time evaluation — essentially
assertion failures during constant evalua
apple-fcloutier wrote:
This is a design space that is large for a person who does not know Clang's
internals and history very well, but that seems fairly narrow for someone with
a lot of experience. As a matter of fact, [there is a
CallableDecl](https://github.com/llvm/llvm-project/pull/115056
rjmccall wrote:
> An abstraction that includes blocks doesn't help us here because we are
> looking for the combination of `NamedDecl` and `DeclContext` and `BlockDecl`
> isn't a `NamedDecl`.
I think you're focusing a little narrowly here. I can't imagine why you'd
specifically need a `NamedD
apple-fcloutier wrote:
An abstraction that includes blocks doesn't help us here because we are looking
for the combination of `NamedDecl` and `DeclContext` and `BlockDecl` isn't a
`NamedDecl`.
Aaron, I'm not sure I understand you correctly, but ObjCMethodDecl doesn't have
a type. What would i
AaronBallman wrote:
I agree that having something tying these together would be nice, but should we
also tie them together at the `Type` level similarly, or just the `Decl` level?
https://github.com/llvm/llvm-project/pull/115056
___
cfe-commits mailin
rjmccall wrote:
Having an abstraction for this would be nice. It doesn't *have* to be a base
class specifically, though; we can do a more extrinsic tagged-union without
actually unifying the class hierarchies, like `llvm::CallSite` does. Swift has
a type called `AnyFunctionRef` that unifies se
ahatanak wrote:
> There is almost certainly value in introducing a base class beneath
> ObjCMethodDecl and FunctionDecl that is both a NamedDecl and a DeclContext,
> because I'm not the first person to run into this problem. If I do the work,
> whose review/approval do we need? Is it deep enou
apple-fcloutier wrote:
I think there's limited value to diagnose_if on blocks, since that will apply
to a variable of block type and not to the block type. In other words, given
this:
```c
void (^block)(int *) = ^(int *p) __attribute__((diagnose_if(p == 0, "p is
NULL"))) { ... };
block(0);
``
ahatanak wrote:
> I wish I didn't need to change the ExprConstant call stack machinery like
> this, happy to take suggestions. This is all because the closest ancestors of
> FunctionDecl and ObjCMethodDecl are NamedDecl and DeclGroup.
Should we enable `diagnose_if` for block methods too?
```
AreaZR wrote:
Any update on this?
https://github.com/llvm/llvm-project/pull/115056
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
apple-fcloutier wrote:
I wish I didn't need to change the ExprConstant call stack machinery like this,
happy to take suggestions. This is all because the closest ancestors of
FunctionDecl and ObjCMethodDecl are NamedDecl and DeclGroup.
https://github.com/llvm/llvm-project/pull/115056
_
https://github.com/apple-fcloutier updated
https://github.com/llvm/llvm-project/pull/115056
>From f74e55dac7d5b28852dbb16455c5f4f083fde8dc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?F=C3=A9lix=20Cloutier?=
Date: Fri, 25 Oct 2024 14:41:28 -0700
Subject: [PATCH] [ObjC] Enable diagnose_if on Objecti
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 17d956588a2cc508acf98574f913eaef6d0e1af3
802e8e85de3b3d0a8c6ccd4f7ac3536f10183ea2 --e
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (apple-fcloutier)
Changes
This change enables checking argument-dependent `diagnose_if` diagnostics on
Objective-C methods.
It changes EvaluateWithSubstitution to accept any NamedDecl, concretely
expecting them to be either Function
https://github.com/apple-fcloutier created
https://github.com/llvm/llvm-project/pull/115056
This change enables checking argument-dependent `diagnose_if` diagnostics on
Objective-C methods.
It changes EvaluateWithSubstitution to accept any NamedDecl, concretely
expecting them to be either Fun
16 matches
Mail list logo
