sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2019-02-08T14:57:32Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2219Scheduled weekly packages should have different name to distinguish them.2019-02-08T14:57:32ZHans-Nikolai ViessmannScheduled weekly packages should have different name to distinguish them.Currently we jut use the default name given by CPack. We can override this with the `CPACK_PACKAGE_FILE_NAME` variable, making the weekly packages distinguishable from normal releasee packages.Currently we jut use the default name given by CPack. We can override this with the `CPACK_PACKAGE_FILE_NAME` variable, making the weekly packages distinguishable from normal releasee packages.Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2220Need more distinct package file names2017-12-13T15:07:23ZHans-Nikolai ViessmannNeed more distinct package file namesAfter merge requests like !35, it has become clear that the package generation can cause unintended overwrites of existing package blobs on the release server. A possible solution would be to append a timestamp to the name, or create a n...After merge requests like !35, it has become clear that the package generation can cause unintended overwrites of existing package blobs on the release server. A possible solution would be to append a timestamp to the name, or create a new directory with the timestamp as its name.https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2221[gitlab CI] Build stdlib using sac2c package2019-02-08T14:57:18ZArtem Shinkarov[gitlab CI] Build stdlib using sac2c packageCurrently, as a part of CI pipeline, we always build stdlib using sac2c binaries directly from the working build directory.
The problem with this is that we never test whether resulting package is operational or not.
It would be a better...Currently, as a part of CI pipeline, we always build stdlib using sac2c binaries directly from the working build directory.
The problem with this is that we never test whether resulting package is operational or not.
It would be a better idea to extend the pipeline as follows:
1. Compile sac2c
2. Create sac2c package
3. Install sac2c package & build stdlib
This would allow to identify the cases when packages are not fully operational.Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2225extend masterrun to build sac2c with/without various features2019-09-26T13:18:39ZHans-Nikolai Viessmannextend masterrun to build sac2c with/without various featuresThis issue was spawned from the MR !43 which made it evident that we need to extend the masterrun to build `sac2c` with or without various combinations of features. This should hopefully more quickly reveal problems like the one solved b...This issue was spawned from the MR !43 which made it evident that we need to extend the masterrun to build `sac2c` with or without various combinations of features. This should hopefully more quickly reveal problems like the one solved by the MR.
It is unclear though what the best way of doing this is; either we extend `.gitlab-ci.yml` to build sac2c with different feature flags, or we run a few more docker images with various installs. Are there other possibilities?https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2237We should build stdlib with installed sac2c2019-02-25T15:50:55ZHans-Nikolai ViessmannWe should build stdlib with installed sac2cThere have been some issues when compiling the stdlib outside of the masterrun. Typically headers give off warnings and errors. This is caused by `config.h` not being included in as part of the install target.
We have two choices:
* we...There have been some issues when compiling the stdlib outside of the masterrun. Typically headers give off warnings and errors. This is caused by `config.h` not being included in as part of the install target.
We have two choices:
* we include `config.h` as part of the install target - NTL lib for instance does this
* we extend the masterrun to install sac2c, and then compile sac2c.
Though we can include `config.h`, its functions is for when we build the runtime-libraries and often is system specific. Including it in the install target means it also get packages... I'm not sure if this might lead to conflict due to differing system configurations.
Updating the masterrun is fairly straightforward... we can do this first I think.https://gitlab.sac-home.org/sac-group/sac2c/-/issues/2282Streamlining errors and warnings2022-08-13T15:43:04ZMichiel VerloopStreamlining errors and warningsCurrently, all errors, warnings and notes (here: messages) go through the various functions in `/src/libsac2c/global/ctinfo.c`.
For these messages, the file and location are printed if they are present and relevant. For longer messages...Currently, all errors, warnings and notes (here: messages) go through the various functions in `/src/libsac2c/global/ctinfo.c`.
For these messages, the file and location are printed if they are present and relevant. For longer messages, they are split up and joined by a new line and one of the seperators `"abort: "`, `"error: "`, `"warning: "`, `"=> "`, `""`, `" "`.
An example of this can be seen by compiling any valid sac file and giving the `-printstart` compiler argument without also providing `-printstop`:
```
$ sac2c generic_error.sac -printstart 1:prs
error: Please use both -printstart <phase_id> and -printstop <phase_id>
error: If it is only one phase/subphase/cyclephase you want reported
error: then the -printstart and -printstop options should be identical.
compilation failed while Loading SAC program, 1 error(s).
```
If multiple such errors appear after each other, it's impossible for a computer to tell where the first error ends and the second error begins. For humans, I argue the distinction between the two errors wouldn't be immediately obvious either.
Additionally, type errors and SAC optimization errors currently differ in format from the other errors for no discernable reason.
In an effort to make the messages from the compiler parsable by regexes without ambiguity and to increase readability, I propose the following:
* The error message is only printed on the first line if the message bears no location information.
* The error message is always printed on a subsequent line if the file, line and/or column is known.
* The message header (abort/error/warning) is included in the function that determines where to place line breaks.
* Type errors are unified with the other errors.
* We capitalize the message headers and 'compilation' properly. (Arguably not important but this bugs me more than it should)
<details><summary>Current vs proposed message forms (click to expand)</summary>
<details><summary>Errors without location information</summary>
Current:
```
$ sac2c generic_error.sac -printstart 1:prs
error: Please use both -printstart <phase_id> and -printstop <phase_id>
error: If it is only one phase/subphase/cyclephase you want reported
error: then the -printstart and -printstop options should be identical.
compilation failed while Loading SAC program, 1 error(s).
```
Proposed:
```
$ sac2c generic_error.sac -printstart 1:prs
Error: Please use both -printstart <phase_id> and -printstop <phase_id>
If it is only one phase/subphase/cyclephase you want reported
then the -printstart and -printstop options should be identical.
Compilation failed while Loading SAC program, 1 error(s).
```
</details>
<details><summary>Errors with line information</summary>
Current:
```
$ sac2c overload_error.sac
./overload_error.sac 10 abort: Cannot overload functions of arity 0
compilation failed while Converting to static single assignment form.
```
Proposed:
```
$ sac2c overload_error.sac
./overload_error.sac 10 abort:
Cannot overload functions of arity 0
Compilation failed while Converting to static single assignment form.
```
</details>
<details><summary>Errors line and column information</summary>
Current:
```
$ sac2c syntax_error.sac
./syntax_error.sac:7:12: error:
=> token `}' expected, `f' token found
./syntax_error.sac:7:12: error:
=> type expected, `f' found
./syntax_error.sac:9:1: error:
=> function body or semicolon expected
abort: Failed to construct a syntax tree for `syntax_error.sac'
compilation failed while Loading SAC program, 3 error(s).
```
Proposed:
```
$ sac2c syntax_error.sac
./syntax_error.sac:7:12: error:
token `}' expected, `f' token found
./syntax_error.sac:7:12: error:
type expected, `f' found
./syntax_error.sac:9:1: error:
function body or semicolon expected
Abort: Failed to construct a syntax tree for `syntax_error.sac'
Compilation failed while Loading SAC program, 3 error(s).
```
</details>
</details>
I am still unsure what to do about SAC optimization errors. For the purposes of easily detecting them, I'd like to give them a special header like `optimization error`. Other than that, I'm told that finding the location in the source code instead of generated code is a worth a thesis on its own, so we probably can't make those more kind to the users.Michiel VerloopMichiel Verloophttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2367Combine _afterguard_ and _guard_, and update guard insertion of ECC2023-12-22T14:55:41ZJordy AalderingCombine _afterguard_ and _guard_, and update guard insertion of ECCConformity checks only have an afterguard, we want to combine this afterguard with guard so that we have a single primitive function, instead of having almost the same thing twice.
Additionally, similarly to type patterns, we want this ...Conformity checks only have an afterguard, we want to combine this afterguard with guard so that we have a single primitive function, instead of having almost the same thing twice.
Additionally, similarly to type patterns, we want this guard to occur both before and after the conformity checked code so that we can keep the context in the future if we have better error messages.
Something like:
```
p1 = conformity check 1
...
pv = conformity check v
x1', .., xn' = guard (x, .., xn, p1, .., pv, "context");
res1, .., resm = _prf_ (x1', .., xn');
res1', .., resm' = guard (res1, .., resm, p1, .., pv, "context");
```Jordy AalderingJordy Aaldering