@@ -36,6 +36,7 @@ The kernel code supports a subset of the *Python 3.5* language. This section hig
...
@@ -36,6 +36,7 @@ The kernel code supports a subset of the *Python 3.5* language. This section hig
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. 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. 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.
