[clang] [compiler-rt] [Clang] Make `-Wreturn-type` default to an error in all language modes (PR #123470)
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Wed Feb 19 04:54:33 PST 2025
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
More information about the cfe-commits
mailing list