@@ -35,7 +35,7 @@ The kernel code supports a subset of the *Python 3.5* language. This section hig
...
@@ -35,7 +35,7 @@ The kernel code supports a subset of the *Python 3.5* language. This section hig
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.`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 limited 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.`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 limited 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.~~
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.~~
1.Returning a tuple containing a combination of `TStr` and `TInt32` elements can in some situations result in a `ValueError: location and highlights must refer to the same source buffer`. The cause of the error is unknown and changing the return type not containing `TStr` seems to solve the solution in the few cases we encountered this error.
1.Functions returning tuples have limited support for returning mixed types. It seems that integer types `{TInt32, TInt64, TBool}` combine in a return tuple without problems, but `TFloat` and `TStr` can not be combined with any other types in a return tuple. Doing so results in a compiler bug `ValueError: location and highlights must refer to the same source buffer`.
1. Passing very "large" arguments to kernel functions (i.e. very large lists) can cause an LLVM IR parsing error: `RuntimeError: LLVM IR parsing error <string>:15604:29: error: value for 'column' too large, limit is 65535`. One way to mitigate this issue is to "pass" the variable as a kernel-invariant attribute instead.
1. Passing very "large" arguments to kernel functions (i.e. very large lists) can cause an LLVM IR parsing error: `RuntimeError: LLVM IR parsing error <string>:15604:29: error: value for 'column' too large, limit is 65535`. One way to mitigate this issue is to "pass" the variable as a kernel-invariant attribute instead.
