https://github.com/shafik commented:
So I think on my last comment, using `break` as opposed to `continue` makes
sense. Agree @cor3ntin
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://l
shafik wrote:
So this is the commit that introduced this 06e41ae5c77c6
and it looks like code like this:
```objc
id x(id(0));
```
we are trying to differentiate a protocol Vs the next parameter?
https://github.com/llvm/llvm-project/pull/109298
___
c
c8ef wrote:
I'm sorry, but I can't identify a case that would trigger this code path. I
might not be that familiar with ObjC...
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm
cor3ntin wrote:
> @cor3ntin See the discussion on #95917. This is likely effectively dead code,
> but nobody is certain enough of that to delete it outright...
The original issue seems to suggest the code path can be used on invalid code
such as
struct X {
};
void foo() {
X;
}
```
(ie
c8ef wrote:
> But that function _does_ have a return statement after the loop?
I assumed that the entire function body was enclosed within the `while(true)`
loop?
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commi
c8ef wrote:
Or we can simply return `TPResult::Ambiguous`, as many functions in this file
do.
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
tbaederr wrote:
But that function _does_ have a return statement after the loop?
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
c8ef wrote:
> I'm only worried about the missing return at the end of the function - maybe
> there should be a `llvm_unreachable` here to silence compilers, even if that
> control flow is not possible.
https://github.com/llvm/llvm-project/blob/21594f2793da5d2e1d1cd6714bfa10e742f2e526/clang/lib
tbaederr wrote:
Yeah the behavior is not the same. The original code only parsed `ident[,]` in
the loop, since the `continue` ended the loop anyway.
The comment above the function reads:
```
/// [ObjC] protocol-qualifiers:
'<' identifier-list '>'
```
So the assumption is that this
shafik wrote:
CC @tbaederr this does not look like equivalent code to me based on your
original isue but maybe I am confused.
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o
nikic wrote:
@cor3ntin See the discussion on
https://github.com/llvm/llvm-project/pull/95917. This is very likely
effectively dead code, but nobody is certain enough of that to delete it
outright...
https://github.com/llvm/llvm-project/pull/109298
_
c8ef wrote:
Based on the comment from the original PR, I am unsure how to reproduce this
bug. However, it aligns with the original intention of this code.
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commits@lists.
cor3ntin wrote:
Do we have a test for this?
https://github.com/llvm/llvm-project/pull/109298
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (c8ef)
Changes
Fixes https://github.com/llvm/llvm-project/issues/95895.
It appears that there was a logic error in the code of
Parser::TryParseProtocolQualifiers related to parsing the identifier list. This
pull request fixed the is
https://github.com/c8ef created https://github.com/llvm/llvm-project/pull/109298
Fixes https://github.com/llvm/llvm-project/issues/95895.
It appears that there was a logic error in the code of
Parser::TryParseProtocolQualifiers related to parsing the identifier list. This
pull request fixed th
15 matches
Mail list logo
