Enable user-defined map parameter types

[ThrudPrimrose]

Adding param_types variable I can set the loop params to what I want.

I also remove the "auto" type to prefer the inferred type.

Using the inferred type instead of auto fixes the discrepancy of C++/CUDA inferred auto type and the inferred type between DaCe, where the discrepancy causes unnecessary implicit type conversion, resulting with a loss of performance.

[ThrudPrimrose]

I also need to check why the param type can be none sometimes (some tests failing)

[ThrudPrimrose]

There is one issue that I am currently trying to solve. I can know change the map parameters' types, and can set them to be for example int, but I am having problems implementing the calls to the nested SDFGs seeing the correct types.

(I need to find a way for the method "new_symbols" of an interstate edge not to infer the type of the parameters if the parameter was introduced by a map parameter set by the user)

[ThrudPrimrose]

Good addition, thank you! Two things are missing:

1. My comment on symbols_defined_at (which should be computed as seldomly as possible)

2. Missing unit test with types (maybe even an additional test that would fail with `auto`, as you now changed the behavior of codegen even in the default case)

Also, you do not have to keep merging with the master; the merge queue will do that for you. Every merge puts an unnecessary burden on the CI queue.

I will update the changes according to your comments. Thanks for pointing out the merge queue.

Since auto was only used in a loop, the type of the loop variable depends on the type used in the loop condition. The auto case will never produce code that does not compile unless we compile with -Wconversion -Werror. However, I can create test cases where the SDFG will produce incorrect results. I will do that (and try to find couple of good test cases).

I have looked at the tests. No hard-coded SDFGs are used in the tests. I should create any SDFG I use through the API or a front-end, right?

[tbennun]

@ThrudPrimrose First of all, many tests use the SDFG API (e.g., add_edge_pair_test.py, you should use that.

Second, for a wrong test case, a simple for loop with a mismatch in start/end types will run forever if not written correctly. See the following example (which one can write in dace): https://godbolt.org/z/YW5xsP51x

[ThrudPrimrose]

Since there is no auto type, it is hard to create one that fails due to auto. When I tried with auto, having auto I = 0; I <N with N being an unsigned long long variable results with I being an int and causing issues.

I can easily create a test that mimics this behaviour by forcing the type of the variable. Then I can run it with subprocess and check for segfaults, should I do that or these tests should be enough?

[tbennun]

What I meant was to have a test that would fail if we generated auto. Obviously all the tests will now pass. :)