[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