AaronBallman wrote: > @AaronBallman You introduced the fixme in > [75ee4cc](https://github.com/llvm/llvm-project/commit/75ee4cc8302aa68464e55b273ebd53f85252268e) > - given the churn it would create and the opposition of tooling which uses > that a lot, no objection to removing the fixme?
I'd like to better understand why tooling is not able to move away from the soft-deprecated functionality. It sounds like "it's more verbose" is the only consideration, which isn't a compelling reason to remove the FIXME. It's known that these kind of old interfaces will take a long time to get fully removed, but that's fine. The idea is: we don't add *new* uses of the interface, and as we're updating code we should be removing the old uses. Eventually the number of old uses gets low enough that we can remove the last handful in a batch and then excise the problematic interface. But this can take a decade+, and that's fine. Btw, the reason this interface is problematic is because of how easy it is to use while accidentally tanking performance due to the string copies. Making the caller think about that is important, particularly because of the temptation to use this interface for string comparisons (which is often the wrong tool anyway). Tooling like clang-tidy can get away with that performance hit because it's already a massive performance hit to walk the AST a bajillion times, but Clang itself isn't so lucky. So perhaps the answer here is: if some tools don't expect to ever adapt, they can provide their own internal `std::string`-based interface and use that. https://github.com/llvm/llvm-project/pull/218264 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
