[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
AaronBallman wrote: > > Existing code already uses `-Wreturn-type` though, and this patch is > > enabling it in all language modes, not just C23 and above. > > At least that’s what I hope we’ll be able to do. A compromise would be to > only enable it in e.g. C23/C++26/whatever, but that doesn’t quite seem > satisfactory to me... Yeah, the goal is to improve safety and security, and so I think it makes sense to aim for enabling this in all language modes. Even if we enable it only in C23 or later as a fallback, it still means projects will struggle to upgrade to the latest C standard, so it's better for us to try to address as many pain points as we can so that migration path is easier for users. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: > Existing code already uses `-Wreturn-type` though, and this patch is enabling > it in all language modes, not just C23 and above. At least that’s what I hope we’ll be able to do. A compromise would be to only enable it in e.g. C23/C++26/whatever, but that doesn’t quite seem satisfactory to me... https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
AaronBallman wrote: > > No, that's not the principal issue (but you should consider building > > userland with it to see how many packages will need fixing) > > Firstly, they need to start using C23/C26. So, existing packages should not > be affected significantly. :-) Existing code already uses `-Wreturn-type` though, and this patch is enabling it in all language modes, not just C23 and above. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
foxtran wrote: > No, that's not the principal issue (but you should consider building userland > with it to see how many packages will need fixing) Firstly, they need to start using C23. So, existing packages should not be affected significantly. :-) https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
AaronBallman wrote: > > The compromise is to make it a warning which defaults to an error so users > > who hit the false positives have an escape hatch. > > OK, that's fair enough, I think. I can see it being controversial but I think > it's a defensible choice (that I agree with). Yeah, my primary concern in terms of fallout is the behavior of `autoconf`. It'd be nice if we could understand the damage there before landing, but now that we're early in the 21.x cycle, we could land and see how it impacts early adopters. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
thesamesam wrote: > The compromise is to make it a warning which defaults to an error so users > who hit the false positives have an escape hatch. OK, that's fair enough, I think. I can see it being controversial but I think it's a defensible choice (that I agree with). https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
AaronBallman wrote:
> > The way -Wreturn-type is implemented in Clang is we build a CFG from the
> > AST and then walk that to determine whether all paths return a value, if
> > that’s what you’re asking.
>
> Is `-Wreturn-type` more susceptible to FPs than other typical Clang warnings,
> and hence maybe shouldn't be an error? e.g. cases where some assert is made
> in the only caller so we know it can't happen, or it's a fixed value and that
> is wrongly not propagated. This kind of thing has plagued GCC and is
> unavoidable AFAICT. I'll look for bugs.
Yeah, it cannot be a hard error because we do have false positives. The
compromise is to make it a warning which defaults to an error so users who hit
the false positives have an escape hatch.
> I juts found this PR. Thank you, @Sirraide! I made a corresponding proposal
> for C language (C2y) to have a restriction at standard level rather than in
> compiler level: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3483.pdf
FWIW, I plan to vote against this proposal at next week's meetings. I like the
idea and I wish I could support it, but because the analysis is complex and
there are false positives, this is not defensible as a constraint IMO. Also,
you have to consider the oddball situations you run into with the preprocessor,
along the lines of:
```
#ifdef DIEDIEDIE
#define DIE_OR_RETURN(x) _Exit(x)
#else
#define DIE_OR_RETURN(x) return x
#endif
int foo(int x) {
if (x < 10)
return 100;
// Should never get here.
DIE_OR_RETURN(-1);
}
```
https://github.com/llvm/llvm-project/pull/123470
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
foxtran wrote: > Would you be interested in collaborating on a paper? Yep. Sure. Let's make C/C++ safer! https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
jeremy-rifkin wrote: Hi @foxtran, I have been working on a proposal on the C++ side. Extensive justification is needed to justify breakage here and I have been attempting to survey the extent of potential breakage. The wording is also tricky especially since attributes are designed to be ignorable. Would you be interested in collaborating on a paper? https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
foxtran wrote: I juts found this PR. Thank you, @Sirraide! I made a corresponding proposal for C language (C2y) to have a restriction at standard level rather than in compiler level: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3483.pdf I think (and not only me) that the same proposal should be sent to C++ committee. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
@@ -1,4 +1,4 @@ -// RUN: %clang_hwasan %s -o %t && %env_hwasan_opts=random_tags=1 %run %t +// RUN: %clang_hwasan -Wno-error=return-type %s -o %t && %env_hwasan_opts=random_tags=1 %run %t vitalybuka wrote: It should be fine to change HWASAN tests, it does nothing specific to returning value. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
https://github.com/Sirraide edited https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
@@ -1,4 +1,4 @@ -// RUN: %clang_hwasan %s -o %t && %env_hwasan_opts=random_tags=1 %run %t +// RUN: %clang_hwasan -Wno-error=return-type %s -o %t && %env_hwasan_opts=random_tags=1 %run %t Sirraide wrote: I’m not really that familiar with the sanitizers, and I know there are some sanitizer tests that explicitly test what happens if we *do* fall off the end of a function, so I wasn’t sure whether that was relevant here or not; if just returning `nullptr` is an option here then I’ll switch to that instead. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
@@ -2,10 +2,10 @@
// UNSUPPORTED: target=thumb{{.*}}
// UNSUPPORTED: android
-// RUN: %clangxx -fsanitize=return %gmlt -O2 -fno-omit-frame-pointer
-fasynchronous-unwind-tables %s -o %t
+// RUN: %clangxx -Wno-error=return-type -fsanitize=return %gmlt -O2
-fno-omit-frame-pointer -fasynchronous-unwind-tables %s -o %t
Sirraide wrote:
Yup, at this point it seems like it’ll be better to split this into another
separate pr
https://github.com/llvm/llvm-project/pull/123470
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
@@ -2,10 +2,10 @@
// UNSUPPORTED: target=thumb{{.*}}
// UNSUPPORTED: android
-// RUN: %clangxx -fsanitize=return %gmlt -O2 -fno-omit-frame-pointer
-fasynchronous-unwind-tables %s -o %t
+// RUN: %clangxx -Wno-error=return-type -fsanitize=return %gmlt -O2
-fno-omit-frame-pointer -fasynchronous-unwind-tables %s -o %t
vitalybuka wrote:
Probably better to land all fix-ups in a separate PR before actual feature, so
we don't revert/related unnecessary stuff.
https://github.com/llvm/llvm-project/pull/123470
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
https://github.com/vitalybuka edited https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
@@ -1,4 +1,4 @@ -// RUN: %clang_hwasan %s -o %t && %env_hwasan_opts=random_tags=1 %run %t +// RUN: %clang_hwasan -Wno-error=return-type %s -o %t && %env_hwasan_opts=random_tags=1 %run %t vitalybuka wrote: why not just to return nullptr? https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
thesamesam wrote: Thanks. I expect there'll be some fallout but you also get missed optimisation bugs out of that in some cases, so. > Another option would be to make this default to an error depending on the > language mode (e.g. only in C23 or later, and either unconditionally in C++ > or in e.g. C++17 or later etc.); I don’t have any actual data on this, but I > would imagine that most programs that actually have code that triggers this > warning are probably C99 or earlier. This unfortunately won't work when we change the default to C23 and so on. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: > Is it implemented differently in Clang, The way `-Wreturn-type` is implemented in Clang is we build a CFG from the AST and then walk that to determine whether all paths return a value, if that’s what you’re asking. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote:
> What I'm asking is: is `-Wreturn-type` more susceptible to FPs than other
> typical Clang warnings
There definitely are cases where we currently can’t figure out that a function
always returns if the control flow is very convoluted, e.g. #111509 has this
horrible example
```c
int foo(int x) {
bool matched = false;
do {
if (matched) {
label: return 0;
}
if (matched || x == 1) {
matched = true;
return 123;
}
if (matched || x == 2) {
matched = true;
return 456;
}
if (matched) {
break;
}
goto label;
} while(false);
}
```
https://github.com/llvm/llvm-project/pull/123470
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
thesamesam wrote: > The way -Wreturn-type is implemented in Clang is we build a CFG from the AST > and then walk that to determine whether all paths return a value, if that’s > what you’re asking. What I'm asking is: isn't this more susceptible to FPs than other typical Clang warnings, and hence maybe shouldn't be an error? e.g. cases where some assert is made in the only caller so we know it can't happen, or it's a fixed value and that is wrongly not propagated. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: > I'm worried about the fallout and I have vague recollections of some early > work I did when I assumed we were making this change for the C99 enforcement > work Another option would be to make this default to an error depending on the language mode (e.g. only in C23 or later, and either unconditionally in C++ or in e.g. C++17 or later etc.); I don’t have any actual data on this, but I would imagine that most programs that actually have code that triggers this warning are probably C99 or earlier. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
thesamesam wrote: @AaronBallman On another note, we've had people request this many times in GCC for C++ at least, but it has FPs as a result of how it's implemented. I was under the impression Clang generally didn't do "middle-end"-style (or optimisation-dependent) warnings. Is it implemented differently in Clang, am I misremembering or misunderstanding something, or is Clang just accepting the FPs here? (cc @pinskia) https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
thesamesam wrote: > Is that something you've looked into by any chance? If not, it would be > worthwhile to know what the fallout is. I'm worried about the fallout and I have vague recollections of some early work I did when I assumed we were making this change for the C99 enforcement work, but I don't have specifics. I can look into this but I'd need time -- I can't do that ready for Clang 20. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
shafik wrote: > > I see a lot of diagnostics were updated to `DefaultError` but I don't see > > matching tests that demonstrate the now error. We should be testing each > > diagnostic. > > #123464 also added `-Werror=return-type` to some tests; we can remove those > now, which should cover at least some of the diagonstics; I’ll add a test for > whatever is left after that because I don’t think we have one for e.g. the > coroutine ones. I missed that but it was a large change. In the future it would be helpful to mention that in the summary since we do expect all diagnostics we modify/add to have full coverage. Otherwise we leave ourselves open to future regressions. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: > (to me) it's not really defensible in 2025 that falling off the end of a > function with a non-void return type is anything but an error. Yeah, agreed. > Specifically, I wonder about `autoconf` I hadn’t thought about that, that’s a good point. > Is that something you've looked into by any chance? I’m not really familiar w/ autoconf, so no, I haven’t. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
AaronBallman wrote:
> > I think this is probably Clang 21 material
>
> Yeah, probably
First off, I really appreciate this patch because (to me) it's not really
defensible in 2025 that falling off the end of a function with a non-void
return type is anything but an error. So thank you!
I do think this is Clang 21 material though because I suspect the fallout from
this might be a challenge. Specifically, I wonder about `autoconf`; that tool
often plays fast-and-loose with the generated code and it relies on the
presence of diagnostics to say "nope, this is not supported". So I worry there
will be autoconf scripts out there which do `int test() { malloc(1); }` to test
for whether `malloc` exists and it now fails because it falls off the end of a
non-void function and so it gives the wrong answer. However, I don't have
evidence of this myself. Is that something you've looked into by any chance? If
not, it would be worthwhile to know what the fallout is. CC @thesamesam who
maybe has insights into what kind of fallout this will cause (or may be willing
to do a test-run with the patch?)
https://github.com/llvm/llvm-project/pull/123470
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: > I think this is probably Clang 21 material Yeah, probably https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: > I see a lot of diagnostics were updated to `DefaultError` but I don't see > matching tests that demonstrate the now error. We should be testing each > diagnostic. #123464 also added `-Werror=return-type` to some tests; we can remove those now, which should cover at least some of the diagonstics; I’ll add a test for whatever is left after that because I don’t think we have one for e.g. the coroutine ones. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
https://github.com/shafik commented: I see a lot of diagnostics were updated to `DefaultError` but I don't see matching tests that demonstrate the now error. We should be testing each diagnostic. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: > Did you do a stage 2 build? Not yet; that’s probably a good idea. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
jeremy-rifkin wrote: There are implications with #123166, which might also be clang 21 material https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
cor3ntin wrote: Thanks for working on that Did you do a stage 2 build? I think this is probably Clang 21 material (unless we become sufficiently confident before RC3) https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Sirraide wrote: Ok, it ended up being only 3 compiler-rt tests that needed fixing. https://github.com/llvm/llvm-project/pull/123470 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
https://github.com/Sirraide updated
https://github.com/llvm/llvm-project/pull/123470
>From 441385e14210f23a4fe5368d44620073a4347a31 Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Sat, 18 Jan 2025 19:35:01 +0100
Subject: [PATCH 1/3] [Clang] Make -Wreturn-type default to an error in all
language modes
---
clang/docs/ReleaseNotes.rst | 4
clang/include/clang/Basic/DiagnosticSemaKinds.td | 12 ++--
clang/test/Index/warning-flags.c | 2 +-
3 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index aa1c02d04f7caa..a086c443984408 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -81,6 +81,10 @@ code bases.
``-fno-strict-overflow`` to opt-in to a language dialect where signed integer
and pointer overflow are well-defined.
+- ``-Wreturn-type`` now defaults to an error in all language modes; like other
+ warnings, it can be reverted to just being a warning by specifying
+ ``-Wno-error=return-type``.
+
C/C++ Language Potentially Breaking Changes
---
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index db54312ad965e8..b70d152781a2a8 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -709,10 +709,10 @@ def err_thread_unsupported : Error<
// FIXME: Combine fallout warnings to just one warning.
def warn_maybe_falloff_nonvoid_function : Warning<
"non-void function does not return a value in all control paths">,
- InGroup;
+ InGroup, DefaultError;
def warn_falloff_nonvoid_function : Warning<
"non-void function does not return a value">,
- InGroup;
+ InGroup, DefaultError;
def warn_const_attr_with_pure_attr : Warning<
"'const' attribute imposes more restrictions; 'pure' attribute ignored">,
InGroup;
@@ -726,10 +726,10 @@ def err_falloff_nonvoid_block : Error<
"non-void block does not return a value">;
def warn_maybe_falloff_nonvoid_coroutine : Warning<
"non-void coroutine does not return a value in all control paths">,
- InGroup;
+ InGroup, DefaultError;
def warn_falloff_nonvoid_coroutine : Warning<
"non-void coroutine does not return a value">,
- InGroup;
+ InGroup, DefaultError;
def warn_suggest_noreturn_function : Warning<
"%select{function|method}0 %1 could be declared with attribute 'noreturn'">,
InGroup, DefaultIgnore;
@@ -8365,10 +8365,10 @@ let CategoryName = "Lambda Issue" in {
"lambda declared 'noreturn' should not return">;
def warn_maybe_falloff_nonvoid_lambda : Warning<
"non-void lambda does not return a value in all control paths">,
-InGroup;
+InGroup, DefaultError;
def warn_falloff_nonvoid_lambda : Warning<
"non-void lambda does not return a value">,
-InGroup;
+InGroup, DefaultError;
def err_access_lambda_capture : Error<
// The ERRORs represent other special members that aren't constructors, in
// hopes that someone will bother noticing and reporting if they appear
diff --git a/clang/test/Index/warning-flags.c b/clang/test/Index/warning-flags.c
index 1694c6abab5624..3229f000c4ae0c 100644
--- a/clang/test/Index/warning-flags.c
+++ b/clang/test/Index/warning-flags.c
@@ -9,7 +9,7 @@ int *bar(float *f) { return f; }
// RUN: c-index-test -test-load-source-reparse 5 all -w %s 2>&1 | FileCheck
-check-prefix=NOWARNINGS %s
// RUN: c-index-test -test-load-source all -w -O4 %s 2>&1 | FileCheck
-check-prefix=NOWARNINGS %s
-// CHECK-BOTH-WARNINGS: warning: non-void function does not return a value
+// CHECK-BOTH-WARNINGS: error: non-void function does not return a value
// CHECK-BOTH-WARNINGS: warning: incompatible pointer types returning 'float
*' from a function with result type 'int *'
// CHECK-SECOND-WARNING-NOT:non-void function does not return a value
>From 5200de410b12463a7c8ba7fdbb75e9156f2cb116 Mon Sep 17 00:00:00 2001
From: Sirraide
Date: Sat, 18 Jan 2025 21:43:37 +0100
Subject: [PATCH 2/3] Fix two tests
---
clang/test/CodeGen/armv7k-abi.c| 10 +-
clang/test/CodeGenOpenCL/atomics-cas-remarks-gfx90a.cl | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/clang/test/CodeGen/armv7k-abi.c b/clang/test/CodeGen/armv7k-abi.c
index fd18dafa7d03f5..872e6423a4a992 100644
--- a/clang/test/CodeGen/armv7k-abi.c
+++ b/clang/test/CodeGen/armv7k-abi.c
@@ -16,7 +16,7 @@ typedef struct {
void simple_hfa(HFA h) {}
// CHECK: define{{.*}} %struct.HFA @return_simple_hfa
-HFA return_simple_hfa() {}
+HFA return_simple_hfa() { return (HFA){0}; }
typedef struct {
double arr[4];
@@ -43,7 +43,7 @@ typedef struct {
void big_struct_indirect(BigStruct b) {}
// CHECK: define{{.*}} void @return_big_struct_indirect(ptr dead_on_unwind
noalias writable sret
-BigStruct return_big_struct_indirect() {}
+BigStruct return_big_struct_indirect()
