The annotation tests skipped their checks with -builtin or -fastproxy as
neither adds __annotations__ to the generated runtime objects. That is no
longer a reason to skip when -pyi is also used, as the annotations are then
in the generated stub file, but the stub lookup only worked for -builtin.
With -fastproxy a method is the flat C wrapper function, so its __qualname__
is Class_method instead of Class.method. Pass a fastproxy flag from each
runme down to the stub lookup so that such a name is split on the stub class
names only when it really is a flat name. Reword the comment explaining when
annotations_supported is false, which was misleading with -pyi.
Assisted-by: Claude Code (Opus 5)
A generated stub class with no wrapped members had an empty suite, which
is invalid Python syntax. Stubs could also refer to base classes from
%imported modules without importing the corresponding Python proxy
module, leaving those names unresolved.
Track whether each stub class emits a member and use an ellipsis when
its body would otherwise be empty. Collect modules referenced through
%import and emit them before declarations, using the same package and
relative import rules as the generated Python proxy.
Keep annotation tests active with -pyi by parsing annotations from the
generated stub instead of expecting them on runtime objects. Include
each generated .pyi file in multi-module Pyrefly checks.
Add Python 3.14 Linux CI configurations for -pyi -typehints with and
without -builtin.
See #3473.
Assisted-by: Codex (GPT-5.6 Sol)
Testing is skipped where there is no support for it, that is,
using -builtin or -fastproxy. How to add this support in needs
determining, it's not clear how to do so.
Python function annotations containing C/C++ types are no longer
generated when using the -py3 option. Function annotations support
has been moved to a feature to provide finer grained control.
It can be turned on globally by adding:
%feature("python:annotations", "c");
or by using the command line argument:
-features python:annotations=c
The implementation is designed to be expandable to support different
annotations implementations. Future implementations could implement
something like the following for generating pure Python types:
%feature("python:annotations", "python");
or typing module types to conform to PEP-484:
%feature("python:annotations", "typing");
Closes#1561
Issue #735
William S Fulton