[Rd] Minor inconsistencies in tools:::funAPI()

[Ivan Krylov]

В Mon, 29 Jul 2024 16:29:42 -0400
Toby Hocking <tdhock5 using gmail.com> пишет:

> Can you please clarify what input files should be used with your
> proposed function? I tried a few files in r-svn/src/include and one of
> them gave me an error.

This is a good illustration of the brittleness of the regexp approach.
I focused on the header files marked as API: 

> tools:::funAPI()$loc |> unique() |> setdiff('WRE')
 [1] "R_ext/GraphicsDevice.h" "Rmath.h"
 [3] "R_ext/GraphicsEngine.h" "R_ext/BLAS.h"
 [5] "R_ext/Lapack.h"         "R_ext/Linpack.h"
 [7] "Rembedded.h"            "Rinterface.h"
 [9] "R_ext/Altrep.h"         "R_ext/Memory.h"
[11] "R_ext/RStartup.h"       "R_ext/Arith.h"
[13] "R_ext/Random.h"         "R_ext/Error.h"

I also wanted the function not to crash with Rinternals.h, but getdecl
/ getdecl2 / tools:::getFunsHdr all give different answers for it.

I think this can be done in a more reliable manner using a recursive
descent parser, but that would take some screenfuls of R that will need
to be very carefully written.

Speaking of discrepancies, here are a few functions declared in API
headers but marked with attribute_hidden:

R_ext/Error.h:NORET void WrongArgCount(const char *);
R_ext/Memory.h:int      R_gc_running(void);

And some minor headaches for people who would like a full
programmatic list of entry points:

 - The functions [dpq]norm are unconditionally remapped to dnorm4,
   pnorm5, qnorm5, and the header file parser only picks up the
   numbered function names.

 - 'optimfn', 'optimgr', 'integr_fn' are marked in WRE as @apifun
   despite not directly being functions or symbol names exported by R
   binaries. May I suggest a separate category for types?

-- 
Best regards,
Ivan