Constness in generated code
The way pystencils determines constness and placement of const
keywords is very intransparent and at times misleading.
Things that should be const are often printed non-const. While we may expect compilers to detect constness by themselves, this
makes integration into other code frameworks more tedious, and still may impact performance.
Luckily, so far, I have not observed the opposite (non-const values printed const) which would just not compile.
Constness
Constness is introduced in the following places (maybe I've missed something):
- In the type system:
-
BasicType
andStructType
: An object type may beconst
-qualified. That is how it should be in a C code generator. -
PointerType
: A pointer may beconst
-qualified, and its pointed-to type may also be; so theoretically, all four possible combinations of constness on pointers can be realized. This does not hold for the recently introduced double pointers (!356 (merged)), though; see below.
-
- In the AST:
SympyAssignment
has a memberis_const
for constant declarations.
While it is perfectly sensible to const-qualify types, annotating assignments with context has the potential for vast confusions; what if the type of the LHS is non-const? How to print it if it is const?
Problems
Field Access Resolution
In transformations.py
(here), the data pointer for a field access is created with const=True
if the field is read-only; however this creates a const pointer, not a pointer to const. The pointed-to data type is still non-const.
Code Printer
The code printer handles const SympyAssignment
s (here) in a fashion that is clearly problematic: The LHS type is printed, and then all occurences of const
are removed from it by string operations. Then a leading const
is added.
This breaks down in the presence of pointers (especially now, with the new double pointers): const
may occur more than once in a pointer type. Also, if the declaration LHS is of pointer type, the const
keyword must not be added to the left, but to the right of the type string.
Solutions
Constness should exclusively be a part of the type, and the type system should respect it.
I've tried several avenues of fixing this, without success; even though constness only occurs at very few places in the code, the way they are spread across the code makes changing them extremely challenging.
The constness issue should enter consideration of the design of the new backend (#73), where it can then be solved as a 'by-the-way', simply by clean integration of constness in the type system.