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
