@@ -14,6 +14,7 @@ The kernel code supports a subset of the *Python 3.5* language. This section hig
1. The keyword `yield` is not supported.
1. Kernels are not able to access class-private members (i.e. attributes with a double underscore name `self.__variable`) since the compiler is not able to resolve those names.
1. Kernel functions with dynamic arguments using `*args` and `**kwargs` are not supported.
1.`if` clauses in list comprehensions are not supported.
**Supported**
...
...
@@ -27,7 +28,7 @@ The kernel code supports a subset of the *Python 3.5* language. This section hig
### Known bugs
1. Unary minus on a kernel invariant causes a cast to `TInt32`, even if the variable is of type `np.int64`. Add an explicit cast using `np.int64()` when using the variable with a unary minus.
1.~~Opening multiple contexts with a single `with` statement can result in incorrect behavior (see [this issue](https://github.com/m-labs/artiq/issues/1478)). As a workaround we recommend to open every context in a separate `with` statement.~~
1. Opening multiple contexts with a single `with` statement can result in incorrect behavior (see [this issue](https://github.com/m-labs/artiq/issues/1478)). As a workaround we recommend to open every context in a separate `with` statement.
1.`RuntimeError` is not bound in kernels (see [this issue](https://github.com/m-labs/artiq/issues/1477)). As a workaround we recommend to make a custom exception class that inherits from `RuntimeError` and raise that class instead.
1.`try`/`except`/`else`/`finally` clauses can cause "variable is not initialized" compile errors when a variable initialized in `try` is used later, even when the `except` clause re-raises the exception. This is due to poor liveness analysis. The problem is known and documented in [this issue](https://github.com/m-labs/artiq/issues/331), but will not be fixed. As a workaround we recommend to initialize the variable before the `try` clause.
1. When explicitly or implicitly declaring a list/tuple/range variable inside a `try`/`with` statement which initializes to the return value of a function, the compiler crashes with an internal type error related to the IR. See [this DAX issue](https://gitlab.com/duke-artiq/dax/-/issues/43) and [this ARTIQ issue](https://github.com/m-labs/artiq/issues/1506). So far we found two workarounds for this bug: **a)** Declare and assign the (implicit) variable before the `try`/`with` statement, **b)** put the body of the `try`/`with` statement in a separate function and call that function.
