"Line aware synthesis cannot synthesis…" error doesn't specify line number.

[Geremia]

This error message (syrec_line_aware_synthesis.cpp#L63C1-L63C204):

std::cerr << "Line aware synthesis cannot synthesis a statement that contains a variable access that uses a non-compile time constant expression as index in its dimension access component\n";

doesn't specify a line number where this error occurs in the SyReC source file.

Also, proper grammar should be:

Line aware synthesis cannot synthesize a statement that contains a variable access that uses a non-compile time constant expression as index in its dimension access component.

[TooMuchDakka]

• The SyReC parser and the cost-/line-aware synthesizers use two different error reporting mechanisms with the former returning the found errors concatinated as a std::string while the latter print them to the standard error output stream std::cerr and returns a boolean to indicate whether the synthesis succeeded.
• Additionally, the parser error messages can be built programmatically while the synthesizer errors are defined as hard coded strings at the source of the error and not easily testable at the moment and could require some effort to trigger if one wishes to test all possible synthesizer errors.
• The parser error messages have a known output format while the synthesizer errors have not with the latter potentially lacking helpful information as shown by this issue.

@burgholzer Potential fixes for this issue are:

• Reuse the parser error message format for the synthesizer errors? Is it helpful to the user to known whether the error was generated by the parser or synthesizer?
• Refactor the synthesizer errors to be parameterized string formats that can constructed instead of raw strings.
• Return the concatinated synthesizer errors in the same way that the SyReC parser does, as a std::string?
• Return a collection of the recorded errors, errors are already recorded in this form in the SyReC parser, instead of returning the concatination of the stringified errors? However, this would be a breaking change in the public interface of both the parser and synthesizers.

[burgholzer]

I don't have a particular preference here. Some kind of unification definitely makes sense.
I am also fine with breaking changes here as long as they lead to an improvement in the usability of the library.