The return value of Parrot_api_get_compiler is unreliable (i.e. allways returns 1). This test proves that. Maybe compreg should raise an error?
Typo in api.t
I think you have to use imcc_get_pir_compreg_api(interp, 1, &pir_compiler) (where pir_compiler is a Parrot_PMC) before compreg 'PIR' will work. Check out setup_imcc() in frontend/parrot2/main.c:191
imcc_get_pir_compreg_api(interp, 1, &pir_compiler)
Thats very true but not the point.
The point is that Parrot_api_get_compiler returns true for /all/ calls, irrespective of whether I put in a reasonable name or garbage. Personally, I think not finding a compiler should be a failure case.
The return value of API calls indicates whether the operation in question completed normally or abnormally (an unhandled exception was thrown). If the return value is 0, that means there is an unhandled exception stored in the interpreter to be examined and possibly reported to the user.
Neither of the compreg get/set pathways throw exceptions, so we would expect this API to always return 1. In the future if we use a different mechanism that throws exceptions, we might expect this behavior to change.
The Parrot_api_get_compiler routine returns a PMCNULL in an out parameter if the compiler is not found. You can inspect that value to determine if a compiler has been found.
That said, the current behavior is sane and consistent with the rest of the API. The case can be made that a user can legitimately register PMCNULL to the compreg hash, and this creates a semipredicate problem. The argument can be made that the more useful behavior might be for Parrot_api_get_compreg to throw an exception if a compiler is not found, instead of returning PMCNULL.
In the absence of thrown exceptions, the current behavior is "correct"
I understand that this is not a bug per se. But from the point of view of an API user, not having found a compiler is a failure. The result of Parrot_api_get_compiler is useless as the function will never fail. In fact, having to check for the return value being NULL aside from having to check the return value is redundant.
It could probably be resolved by throwing an exception inside the API function. That way, existing code (that does not expect compreg to fail) will continue to work, and the API will do what the user expects.
Merge remote-tracking branch 'upstream/master'
Merge remote branch 'upstream/master'
Whiteknight, how about this pull request?
I am +1 to merging this, but it does not appear mergable. I've tried twice and it doesn't seem like I can merge it (or merging brings no changes). Can somebody please verify?
Oh, that is my fault. I have erased the repository only to start again with a new one.
I still have the files locally, and I can push a new branch if needed. But that does mean a new pull request.
Also, I should add imcc_get_pir_compiler to the test first.