iains added a comment. In D126694#4470297 <https://reviews.llvm.org/D126694#4470297>, @ChuanqiXu wrote:
>> Yes, that was the decision at the last time we looked - because removing >> decls would degrade this - if we have new information that changes our >> preferred design, then fine. > > I remember the major reason for the last time to not remove the decls are > that the design of AST doesn't support to remove decls. And my current idea > is, we can refuse to write the discardable Decls into the BMIs. @rsmith pointed out that the API was not intended for that purpose - so, yes, you are correct that the next place to look was in the serialisation [but ISTR that this also has some challenges because of the way in which the structures are interconnected]. It might be necessary to do a pass before the serialisation and actually prune the AST there. (in a similar manner we'd need to prune it to remove non-inline function bodies in some future version) >> One solution is to place the elision behind a flag so that the user can >> choose slower compilation with better diagnostics or faster compilation but >> maybe harder-to-find errors? > > I proposed to add a flag. But that was a helper for developers to find if we > did anything wrong. I don't want to provide such a flag since on the one > hand, there are already many flags and on the other hand, form my user > experience, it is not so hard to find the unexported decls. It is really much > much more easier than template programming. Yeah, (as you know) I definitely prefer not to add more flags - there are too many - it was only an option in case there were many people against degrading diagnostic output. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D126694/new/ https://reviews.llvm.org/D126694 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
