This is really, really, annoying. What we really want is (psuedocode):
```python
class SubValues(TypedDict[str, str], total=False):
@INPUT@: T.List[str]
@OUTPUT@: T.List[str]
```
Which would specifiy that `@INPUT@` and `@OUTPUT@` *may* be present and
if they are, then they are lists. There may be additional keys, which
have a single string as a value. Of course there is currently no way to
do that with typing, so we have to instead take a union type and then
use asserts to help the type checker unerstand this.
More info: https://github.com/python/mypy/issues/4617
get_compiler_for_source and classify_unity_sources are both wrong, in
that they expect to be given a seqence of strings, but they really
should take a `Sequence[str | File]`.
Additionally, they're using `CompilerType`, which we don't need anymore,
and should stop using, most methods for the Compiler are actually
defined in the base compiler class.
Again, this is not complete and is just enough for backend.py. Again,
typing these is complicated massively by the layering violations in the
Target classes and the interpreter.
This is not complete, it's just enough for backend/backend.py. A more
completely typing would be more difficult, especially whithout
untangling the layering violation between the build targets and the
interpreter.
rsplit(..., 1) always produces exactly one split, by design, there's no
need to then join a 1-element list via a generator comprehension after
extracting the end of it via pop. If this commit message sounds
confusing, then so was I when trying to figure out what this actually
did and if it needed extracting to PythonExternalModule.
Currently, we write each file to the command line, but this can result in
situations where the number of files passed exceeds OS imposed command
line limits. For compilers, we solve this with response files. For
depscan I've chosen to use a JSON list instead. JSON has several
advantages in that it's standardized, there's a built-in python module
for it, and it's familiar. I've also chosen to always use the JSON file
instead of having a heuristic to decide between JSON and not JSON,
while there may be a small performance trade off here, keeping the
implementation simple with only one path is wort it.
Fixes#9129
There are two changes here, one is to remove an `elif` that is
effectively an `else`, that helps the type checker and provides a small
speedup potentially. The second is a potentially unbound variable, that
currently isn't hit, but very much could be.
This assert causes several type checkers (both mypy and pyright) to
force `obj` to be a base `HoldableObject` instead of the specialized
object. Since the check itself may still be valuable as we don't have
fully type annotation coverage it's simply been removed when type
checking to aid in type specialization.
Dylan Baker
Xavier Claessens
Eli Schwartz
Nirbheek Chauhan
Tristan Partin
Jussi Pakkanen