fixes #25: add HostHasSourceTextAvailable hook

[michaelficarra]

If this is sufficient, this was way easier than I thought it would be.

/cc @domenic @phoddie

Fixes #25.

[ljharb]

Provided that any exploration of JS-controlled per-function/per-module/per-file censoring explores the web compatibility of returning "[unavailable code]" or similar, this seems fine to me.

[jdalton]

@ljharb

"[unavailable code]"

Firefox OS (mobile) had something similar IIRC.

[domenic]

Looks great!!

[domenic]

Not sure we need the flexibility to return abruptly, but it doesn't hurt anything.

[michaelficarra]

I figured since toString can already return abruptly today, it didn't hurt to allow the engine to control that as well.

[anba]

Allowing abrupt completions doesn't seem useful to me. Function.prototype.toString is currently spec'ed to either return a string or throw a TypeError. With this change, it either returns a string or throws any value, so the error case is no longer restricted to TypeError.

For example test262 tests will need to be written as:

function f() {}

var errored = false;
var source;
try {
  source = f.toString();
} catch {
  // HostHasSourceTextAvailable is allowed to return abruptly, unconditionally pass in this case.
  errored = true;
}

if (!errored) {
  // NATIVE_FUNCTION_RE is defined in test262/harness/nativeFunctionMatcher.js
  assert(source === "function f() {}" || NATIVE_FUNCTION_RE.test(source));
}

If we don't allow abrupt completions, the test can be written as:

function f() {}

var source = f.toString();
assert(source === "function f() {}" || NATIVE_FUNCTION_RE.test(source));

Nit: The result must be compared to true, so HostHasSourceTextAvailable(func) is true, then return ... instead of HostHasSourceTextAvailable(func), then return .... And we should probably require HostHasSourceTextAvailable to return a boolean value.

And I assume not requiring stable results is intentional? So HostHasSourceTextAvailable is allowed to return different results over time even when the same argument is passed to it?

[michaelficarra]

@erights I invite you to voice any concerns you have in this PR.

[michaelficarra]

Ping @phoddie @erights

[erights]

Hi @michaelficarra I still don't like the host hook. I think it is a mistake. Most of what it legitimately tries to accomplish is better accomplished with the lexical directive. That said, in a world of scarce attention and "pick your battles" I am not inclined to pick this one.

[phoddie]

@michaelficarra, echoing @erights, I can live with the host hook but I don't know that it is needed at this point. Would it be enough to simply modify the existing specification text, e.g. "If the implementation cannot produce a source code string that meets these criteria then it must return NativeFunction"? This defers definition of mechanisms, such as those in the new censor proposal, while guaranteeing return of a consist string, which addresses the overall goal of this proposal, as I understand it.

[domenic]

That sounds like just an underspecified version of the host hook, which requires hosts to say "An implementation is unable to produce a source code string under the following circumstances:" instead of "An implementation defines HostHasSourceTextAvailable as:"

[erights]

Hi @phoddie I agree with @domenic on this point. The reason I think this whole mechanism is a mistake is its effect on what a correct program can assume. A correct program's correct behavior relies on some underlying platform obeying the contract the correct program correctly relies on.

Both the explicit host hook and your suggested text limits these contracts in the same painful way. But the host hook makes the pain explicit, which is better.

[phoddie]

@domenic it is exactly an underspecified version of the host hook, underspecified precisely consistent with the current spec text. As you, @erights, and @michaelficarra are comfortable adding the host hook now, we should move ahead with that.

[michaelficarra]

@phoddie In that case, can you review and approve this PR?

[phoddie]

@michaelficarra, done.