Check each case value in turn while parsing it, performing the
conversion to the switch type within the context of the expression
itself. This will become necessary in order to properly handle cleanups
for temporaries created as part of the case label (in an upcoming
patch). For now it's just good hygiene.
This necessitates moving the checking for the switch condition itself to
earlier, so that the destination type is available when checking the
case labels.
As a nice side-effect, we get slightly improved diagnostic quality and
error recovery by separating the case expression checking from the case
statement checking and from tracking whether there are discarded case
labels.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338056 91177308-0d34-0410-b5e6-96231b3b80d8
This only warns on direct gotos and indirect gotos with a unique label
(`goto *&&label;`). Jumping out ith a true indirect goto is already an error.
This isn't O(1), but goto statements are less common than continue, break, and
return. Also, the GetDeepestCommonScope() call in the same function does the
same amount of work, so this isn't worse than what's there in a complexity
sense, and it should be pretty fast in practice.
This is the last piece that was missing in r231623.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231628 91177308-0d34-0410-b5e6-96231b3b80d8
Thou shall not jump into SEH blocks. Jumping out of SEH __try and __excepts
is A-ok. Jumping out of __finally blocks is B-ok (msvc doesn't error about it,
but warns that it has undefined behavior).
I've checked that clang's behavior with this patch matches msvc's behavior.
We don't have the warning on jumping out of a __finally yet, see the FIXME
in the test. clang also currently crashes on codegen for a jump out of a
__finally block, see PR22414 comment 7.
I also added a few tests for the interaction of indirect jumps and SEH blocks.
MSVC doesn't support indirect jumps, so there's no way to know if clang behave
the same way as msvc here. clang's behavior with this patch does make sense
to me, but maybe it could be argued that it should be more permissive (see
FIXME in the indirect jump tests -- shout if you have an opinion on this).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227982 91177308-0d34-0410-b5e6-96231b3b80d8
"protected scope" is very unhelpful here and actively confuses users. Instead,
simply state the nature of the problem in the diagnostic: we cannot jump from
here to there. The notes explain nicely why not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217293 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us diagnose and perform more complete semantic analysis when faced
with errors in the function body or declaration.
By recovering here we provide more consistent diagnostics, particularly during
interactive editing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@208394 91177308-0d34-0410-b5e6-96231b3b80d8
declarations that might lifetime-extend multiple temporaries. In passing, fix a
crasher (PR18217) if an initializer was dependent and exactly the wrong shape,
and remove a bogus function (Expr::findMaterializedTemporary) now its last use
is gone.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197103 91177308-0d34-0410-b5e6-96231b3b80d8
we don't do the scope checks otherwise we are going to hit assertion checks
since a label may not have been actually added.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175281 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146619 91177308-0d34-0410-b5e6-96231b3b80d8
cases that demonstrates exactly why this does indeed apply in 0x mode.
If isPOD is currently broken in 0x mode, we should fix that directly
rather than papering over it here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130007 91177308-0d34-0410-b5e6-96231b3b80d8
in the scope checker. With that done, turn an indirect goto into a
protected scope into a hard error; otherwise IR generation has to start
worrying about declarations not dominating their scopes, as exemplified
in PR8473.
If this really affects anyone, I can probably adjust this to only hard-error
on possible indirect gotos into VLA scopes rather than arbitrary scopes.
But we'll see how people cope with the aggressive change on the marginal
feature.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@117539 91177308-0d34-0410-b5e6-96231b3b80d8
about the permitted scopes. Specifically:
1) Permit labels and gotos to appear after a prologue of variable initializations.
2) Permit indirect gotos to jump out of scopes that don't require cleanup.
3) Diagnose possible attempts to indirect-jump out of scopes that do require
cleanup.
This requires a substantial reinvention of the algorithm for checking indirect
goto. The current algorithm is Omega(M*N), with M = the number of unique
scopes being jumped from and N = the number of unique scopes being jumped to,
with an additional factor that is probably (worst-case) linear in the depth
of scopes. Thus the entire thing is likely cubic given some truly bizarre
ill-formed code; on well-formed code the additional factor collapses to
an amortized constant (when amortized over the entire function) and so
the algorithm is quadratic. Even this requires every label to appear in
its own scope, which would be very unusual for indirect-goto code (and
extremely unlikely for well-formed code); it is far more likely that
all labels will be in the same scope and so the algorithm becomes linear.
For such a marginal feature, I am fairly happy with this result.
(this is using JumpDiagnostic's definition of scope, where successive
variables in a block appear in their own scope)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103536 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith