… use of Parrot_pcc_get_*_reg functions. These functions are marked PARROT_EXPORT, and they probably need to be for things like dynops. However, we should definitely provide some warnings/guidance in case somebody wants to try to use these functions for other purposes.
To my knowledge this function has never 'walked up the scopes', and I'm not aware of any problems caused by that omission. Further, a request for a test or use-case over a year ago went unanswered, suggesting there isn't any user desire for such a change. This commit closes #563
alvis++ for pointing it out. cotto+ for final review.
Don't mention PMCs. Instead, mention classes and objects, the kind of higher-level features that HLLs will work with. Mention that the specified list of compiler targets depeds on the individual compiler. Some (like data_json) don't make sense to offer parse/past/pir/pbc targets.
…d' from 'docs/'.
…re it in the 'docs/' directory, and we no longer have 'packfile-perl.pod', 'packfile-c.pod', and 'strings.pod'.
… call to Parrot_x_panic_and_exit; I don't see it used directly in the code, so I guess it's the PMC compiler or a macro that's introducing the call to it. Thus it must be marked PARROT_EXPORT. This unbusts NQP build on MSVC.
…t. Rename the previous Parrot_x_panic_and_exit with Parrot_x_force_error_exit
…and_exit (may be renamed). Add a new macro PARROT_FORCE_EXIT to use in place of the libc exit(i) routine, which should not be used on all platforms