[clang] [libclang/python] Add type annotations to the TranslationUnit class (PR #180876)

Vlad Serebrennikov via cfe-commits cfe-commits at lists.llvm.org
Sun Feb 15 08:40:38 PST 2026


================
@@ -3490,11 +3504,12 @@ def from_source(
         etc. e.g. ["-Wall", "-I/path/to/include"].
 
         In-memory file content can be provided via unsaved_files. This is a
-        list of 2-tuples. The first element is the filename (str or
+        list of 2-tuples. The first element is the filename (str, bytes or
         PathLike). The second element defines the content. Content can be
-        provided as str source code or as file objects (anything with a read()
-        method). If a file object is being used, content will be read until EOF
-        and the read cursor will not be reset to its original position.
+        provided as str or bytes source code, or as file objects (anything with
+        a read() method). If a file object is being used, content will be read
+        until EOF and the read cursor will not be reset to its original
+        position.
----------------
Endilll wrote:

Ugh, this is a complicated topic which have even more repercussions than you listed.
It seems that we generally support `bytes` in `TranslationUnit` via wonderfully named `b` function.
Then I see support for `bytes` in `c_interop_string`, which is not a part of our user-facing API, but still worth mentioning, because I intend low-level C API be usable if that's what users want to use.

> Imo being able to pass filepaths as bytes is a pretty pointless feature

The problem is that we have no insight how many people pass `bytes` to our API. How hard would it be to support them everywhere?

https://github.com/llvm/llvm-project/pull/180876


More information about the cfe-commits mailing list