| In order not to break the PAL API, I suggest we add validation methods similar to the same for parsing:
Puppet::PAL::Compiler#validate_string(String source) >> Tuple[AST, Array[Hash]] |
Puppet::PAL::Compiler#validate_file(String file_name) >> Tuple[AST, Array[Hash]]
|
These would parse and validate and return all found issues as an Array of hashes where each hash describes one issue as follows:
# example from IssueReporter that does this for purpose of logging |
{ |
:level => :warning, # :error, :warning, :deprecation, :ignore |
:message => issue.format(args), |
:arguments => args, |
:issue_code => issue.issue_code, |
:file => semantic.file, # semantic is an AST object |
:line => semantic.line, |
:pos => semantic.pos, |
}
|
The validate methods should include all reported issues - including :deprecated and :ignore - it would be up to the reporter to handle those as warnings, information, etc. Also, the settings max_error, max_warnings etc. should not have any effect - it should simply return all reported. With the above all but one "internal API leakage" would be fixed - the args key would be the values given to the issue as arguments - and this could be some object that we do not intend to expose as API. This can be solved by not surfacing the arguments, or to do a serialization of them to for example a rich data hash (would need to check what happens when turning non-rich-data to a data hash for example an arbitrary Ruby Class, instance of arbitrary ruby Class, and specifically an Error). |
