[PATCH] D136162: [analyzer] Fix assertion failure with conflicting prototype calls

[Balázs Benics via Phabricator via cfe-commits]

steakhal marked an inline comment as done.
steakhal added a comment.

In D136162#3873392 <https://reviews.llvm.org/D136162#3873392>, @NoQ wrote:

> Ok so you're saying that it's not just a wrong Decl but there's like an entire cast-expression missing in the AST? This fix is probably good enough for us but it begs a question, what does CodeGen do in such cases? Does it also need to emit a cast instruction into LLVM IR that doesn't correspond to anything in the AST? Or is this entirely about our weird pointer cast handling, that needs to act even when the numeric value of the pointer doesn't change?

Good question. The IR is identical for the two cases - except for metadata markers e.g. for deb info, etc.
So, it might be simply that the "C" language just doesn't care if there is a bitcast or not in the AST, because the hardware register is just an untyped register; hence this `ImplicitCastExpr` (bitcast) is getting lowered as a noop at the IR level.

Unfortunately, it's beyond my expertise. Do you think we should invite someone, like Shafik or Aaron?



================
Comment at: clang/lib/StaticAnalyzer/Core/CallEvent.cpp:490
+    // edge-cases.
+    ArgVal = castArgToParamTypeIfNeeded(Call, Idx, ArgVal, SVB);
+
----------------
tomasz-kaminski-sonarsource wrote:
> Previously we didng make bindings if `ArgVal` was unknown, and we may want to preserve this invariant.
IDK what are the implications of not having a binding or having a binding to unknown.
I'll change this anyway. Thanks for noticing.


================
Comment at: clang/test/Analysis/region-store.c:66
+  // expected-warning at +1 {{passing arguments to 'b' without a prototype is deprecated in all versions of C and is not supported in C2x}}
+  b(&buffer);
+}
----------------
NoQ wrote:
> steakhal wrote:
> > tomasz-kaminski-sonarsource wrote:
> > > tomasz-kaminski-sonarsource wrote:
> > > > I would like to see an example where the called function is implicitly defined.
> > > After rethinking it, I have not idea how to construct that example.
> > I could not construct such an example.
> > It seems like clang errors out for cases when an implicit declaration of a call mismatches with the definition of that function.
> > https://godbolt.org/z/rM9ajeTf7
> Yeah, if you scroll really far to the right, you'll see that the first error is actually a warning auto-promoted to an error. So you can pass `-Wno-implicit-function-declaration` and it'll disappear. Not sure what to do with the other error though, it really does notice that the implicit definition conflicts with the later explicit definition. So, dunno.
Yup, I should have been more clear on this. See the test, I'm also passing the `-Wno-implicit-function-declaration` :)
Maybe Shafik or Aaron knows some weird stuff about how to make it 'compile'. WDYT?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D136162/new/

https://reviews.llvm.org/D136162