steakhal wrote: Modeling a function should only happen if that's the intended function. Sometimes this matching is deliberately fuzzy, but most often it's incidentally so and they should have really check the parameter and return types for exact match. Or at least the parameters that the model cares about. Such incidental matches are usually not a big deal, unless they lead to false assumptions thus crashes like in this case. It's also true that it's just so cumbersome and ugly to match these types that we had an implicit tendency to simply avoid matching these. So if we had convenient tools for matching these types and signatures, the story would look different.
> I've investigated the code of `StdLibraryFunctionsChecker` and the part that > deals with function signatures can be extracted in separate file without many > problems. > > For now, I can implement more error-handling as in option 2 and refactor > `StdLibraryFunctionsChecker` later if needed. I don't want to push you work, but I'm curious. If it was easy to hoist the `Signature` class, would it be easier to use this `Signature` class for implementing the matching code instead of hand-rolling out something custom? https://github.com/llvm/llvm-project/pull/145229 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
