erichkeane wrote: Here is where my mind is at:
1- We need, as a project to re-think/come up with a better way to figure out how to suppress warnings in header files. I don't think there is a silver-bullet here, and no one has come up with a reasonable way forward on this. 2- I think the idea that 'warnings in the STL aren't actionable by users' is correct in SOME cases, but not all. It is frustrating we don't have a way to figure out when an STL function is a 'proxy' for user action (like construct_at/invoke/emplace_back/ etc), where we should no longer suppress warnings in that instantiation-context. PERHAPS we could find a way to mark it that way? 3- This one somewhat scares me for things where the STL will need to 'invent' an object (eg, sees it is 'default constructible'/'trivially copyable', so does a default-construct + memcpy instead of a construct-in-place because reasons), which will result in false-positives, because as I said, the STL is 'assumed right'. 4- It is PROBABLY not a huge deal here, and is something we could perhaps use to fix 'later'. This is an opt-in and perhaps a bit of a 'you get what you asked for' (even if you didn't know what you were asking for) via the attribute. IMO, I wonder if we should INSTEAD start marking this diagnostic as an error? It plays awkwardly with SFINAE IIRC, but we can mark it as SFINAE error anyway. 5- Even if we choose not to make it an error, I think I'm about 55/45 that we can accept this and hold our nose/push off the issues with figuring out STL proxy-function vs normal-function. https://github.com/llvm/llvm-project/pull/141133 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
