That works, but there's no forcing function to remove the conditionals when
they're no longer needed. The nightlyOnly test gives people failures in CI
that they have to go fix.

On Fri, Aug 18, 2017 at 12:41 AM, Lars Hansen <lhan...@mozilla.com> wrote:

> More often I've seen predicates defined in builtin/TestingFunctions.cpp
> and visible at the shell top level used to gate tests, eg, wasmIsSupported
> tests for webassembly, wasmThreadsSupported tests additionally for the new
> thread proposal functionality, etc.
>
> if (!wasmIsSupported())
>   quit(0)
> // tests
> ...
>
> or
>
> if (wasmThreadsSupported()) {
>   // some additional tests here
>   ...
> }
>
> --lars
>
>
> On Fri, Aug 18, 2017 at 1:01 AM, Jim Blandy <jbla...@mozilla.com> wrote:
>
>> I don't know how other SpiderMonkey folks work with this, but I added a
>> jit-test library function for marking tests for features that are enabled
>> only in nightly:
>>
>> http://searchfox.org/mozilla-central/rev/e8c36327cd8c9432c69
>> e5e1383156a74330f11f2/js/src/jit-test/lib/nightly-only.js
>>
>> The comments explain it pretty well:
>>
>> // Some experimental features are enabled only on nightly builds, and
>> disabled
>> // on beta and release. Tests for these features should not simply disable
>> // themselves on all but nightly builds, because if we neglect to update
>> such
>> // tests once the features cease to be experimental, we'll silently skip
>> the
>> // tests on beta and release, even though they should run.
>>
>> // Call the function f. On beta and release, expect it to throw an error
>> that is
>> // an instance of error.
>> function nightlyOnly(error, f) { ... }
>>
>> I used this to mark up tests for async generators, like so:
>>
>> nightlyOnly(g.SyntaxError, () => {
>>   g.eval("(async function* estux() { debugger; })().next();");
>>   assertEq(name, "estux");
>> })
>>
>> Now that async generators have landed, I think there are no uses of
>> nightlyOnly in the code, but if you know of any tests of this sort, you
>> might consider using it. Otherwise, I guess it should be removed.
>> _______________________________________________
>> dev-tech-js-engine-internals mailing list
>> dev-tech-js-engine-internals@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
>>
>
>
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals

Reply via email to