ppx can generate code that assumes stdlib/pervasives are in scope

[davesnx]

Problem

ppx authors frequently encounter issues where code generated implicitly relies on Stdlib modules and functions being in scope. This creates problems for users who:

• Use alternative standard libraries (Base, Core, etc.)
• Want explicit control over what's in scope
• Compile with -nopervasives or similar flags

It's not rare to generate code that relies on Array, List, String Printf or even raise, invalid_arg, etc.

Current workarounds

Right now I track down each stdlib dependency in generated code (easy to lose cases such as |> or <=) I have used a cram test with (flags -nopervasives) to catch assumptions (but it is unreliable since nopervasives propagate to all dependencies).

Potential solution

Could ppxlib/metaquote provide:

1. Fully qualified generation - Generate Stdlib.List.map instead of List.map
2. Configuration option - Allow PPX authors to specify whether to generate qualified names
3. Lint/warning system - Warn when generated code assumes stdlib availability
4. Some utilities - A way to test ppx output without stdlib assumptions (nopervasives seems not useful)

[NathanReb]

Yes that is indeed a problem, thanks for reporting it!

Helpers for ppx authors definitely sounds like something we should provide to help them write code that can safely use the standard library regardless of the context, we could expose fully qualified identifiers for the stdlib for instance.

We could setup a flag that detects potential stdlib assumptions but this would have to be disabled by default as it could easily trigger false positives, especially in the case of derivers that usually make assumptions on some functions availability, e.g.:

type t = String.t
[@@deriving compare]

would generate code that assumes String.compare is available, without it having to be the stdlib's String.compare. That would actually hold for any automated mechanism we might want to setup around this. Ultimately, ppx authors will have to update their code for it to be foolproof in that regard.

That could still help ppx users to detect potential issues in the ppx they use and report them upstream.

I think the utilities you suggest could actually replace the linting if we can come up with a good solution, something that would somehow shadow the stdlib's module, or deprecate them so the generated code would emit warnings. I'll look into this!