thakis added a comment. Since the fix for this seems to be "just remove the flag", and since the flag can be removed while on the old clang version without problems, it's possible to migrate to the new way without having to do this at the same time as a compiler update already. So I'm not sure we need this.
The situation we're trying to avoid is where old clang has one way of doing things, new clang a new way, and you need to switch ways at the same time as updating compilers. It's better to add the new way while keeping old way working for a while so that you can update clang and then switch to the new way, and then we can remove support for the old way. But in this case it looks like current clang supports old and new way already (?) so I'm not sure we need this. If others think this is useful, there's little harm in accepting this for a while either though. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96971/new/ https://reviews.llvm.org/D96971 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
