allowing limiting which languages a custom check oracle supports
if this list of languages is present, pass the location of the source code to the custom check functions of the programmed oracles.
The intended use of this would be to provide a semi-supported way of doing static analysis of the code of the submission. The reasons for doing this are:
We do have demand for this (and other, proper, solutions is long-term research: #392 )
We do not have to point people wanting to do this to the Python judge if this is implemented.
The maintenance burden and backwards compatibility story for us is very minimal: we just pass the path to the submission in the oracle context. We are not committing to allowing static checks specifically.
An alternative, doing this in the language-specific oracles forces the use of language-specific oracles, which are much harder to properly implement than the programmed ones.
I would certainly not include an example of using this for static checks in the documentation: we do not want to encourage this. The main question is thus do we actually want to make this possible or not?
I am inclined to merge this, as it introduces almost no maintenance overhead for us, and allows researching a better solution in peace (as this is provides a non-horrible workaround).
This is a small change/experiment:
The intended use of this would be to provide a semi-supported way of doing static analysis of the code of the submission. The reasons for doing this are:
An alternative, doing this in the language-specific oracles forces the use of language-specific oracles, which are much harder to properly implement than the programmed ones.
I would certainly not include an example of using this for static checks in the documentation: we do not want to encourage this. The main question is thus do we actually want to make this possible or not?