================
@@ -2382,14 +2382,20 @@ size_t SourceManager::getDataStructureSizes() const {
SourceManagerForFile::SourceManagerForFile(StringRef FileName,
StringRef Content) {
+ // We copy to `std::string` for Context instead of StringRef because the
+ // SourceManager::getBufferData() works only with null-terminated buffers.
+ // And we still want to keep the API convenient.
+ ContentBuffer = Content.str();
----------------
ilya-biryukov wrote:
Looking through the uses of `SourceManagerForFile`, we use it for:
- clang-format,
- some functions in Clangd reading the current file,
- tests.
I would not worry about tests for obvious reasons.
Re Clangd I can also say with high confidence it would never make a difference.
If someone opens a large file there, we'll see a ton of copies when LSP passes
us this file and anything will bleak in comparison with the memory and compute
requirements of Clang itself.
Wrt to clang-format, I am also fairly confident that any large file will take a
lot more time and memory to process and this copy will not be noticeable. I
will get some large mock file and run some benchmarks for sure and get back to
you.
I am not sure in which context unity builds would be a useful use-case to
support for either clang-format or Clangd, do you have any use-cases in mind
that I am missing?
https://github.com/llvm/llvm-project/pull/131299
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
