Simple .lp file no longer readable

[fuglede]

This came up while debugging lovasoa/highs-js#34: A one-line .lp file with contents

Maximize a subject to a >= 1 bounds a <= 0

used to be readable by HiGHS which would detect infeasibility, but now it just gives a "parser error".

[fuglede]

Another example is

Maximize a subject to a >= 1

[fuglede]

Arguably, this is actually completely fine since, according to the specification,

The file must end with the word end in any combination of upper- and lower-case characters, alone on a line. This word is not required for files that are read in to lpsolve, but it is strongly recommended. Files that have been corrupted can frequently be detected by a missing last line.

[jajhall]

Fair cop, we didn't have a file of this kind in the test cases.

[fuglede]

I think it's fine; append the "End" line and both cases work as expected.

[jajhall]

Yes, not requiring an "End" line is lp_solve LP format- that we don't support

[fuglede]

Reopening per discussion here: lovasoa/highs-js#35 (comment)

[jajhall]

Having looked at these two files, Gurobi reads

Maximize a subject to a >= 1

but not

Maximize a subject to a >= 1 bounds a <= 0

so they are clearly on the margins of what's readable. In both cases, if end is appended to the line HiGHS reads them fine

Looking again at the statement in (CPLEX-format)[https://web.mit.edu/lpsolve/doc/CPLEX-format.htm],

The file must end with the word end in any combination of upper- and lower-case characters, alone on a line. This word is not required for files that are read in to lpsolve, but it is strongly recommended. Files that have been corrupted can frequently be detected by a missing last line.

rather than allow HiGHS to interpret EOF as a missing end statement - as it did before - I've decided that it's better to require end so that corrupted (truncated) files are flagged up.

[fuglede]

And while we're at it, the specification also requires that

Each constraint definition must begin on a new line.

which clearly wasn't the case here, so even though it's parsable once the "End" line is added, it's really still invalid according to the specification.