Closed Bug 1264085 Opened 4 years ago Closed 4 years ago

shell/warning.js is going to permafail when Gecko 48 merges to Beta

Categories

(Core :: JavaScript Engine, defect, major)

Unspecified
All
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox46 --- unaffected
firefox47 + fixed
firefox48 + fixed

People

(Reporter: RyanVM, Assigned: arai)

References

Details

Attachments

(1 file)

[Tracking Requested - why for this release]: SM permafail when Gecko 48 merges to Beta.

Any idea what might have changed in RELEASE_BUILD land recently here, Arai? This is burning all SM jobs.

https://treeherder.mozilla.org/logviewer.html#?job_id=19227326&repo=try

## shell/warning.js: rc = 3, run time = 0.062321
1170716: Add js shell functions to get last warning
shell/warning.js:16:1 Error: Assertion failed: got false, expected true
Stack:
  @shell/warning.js:16:1
TEST-UNEXPECTED-FAIL | shell/warning.js | (args: "")
Flags: needinfo?(arai.unmht)
This is a regression from bug 1049041.

The warning in String#contains is non-release only.
We should use another warning that is enabled on all branches.
Blocks: 1049041
Flags: needinfo?(arai.unmht)
Flags: needinfo?(jorendorff)
the code is changed again in bug 1103588, to expression closure.
  https://hg.mozilla.org/integration/mozilla-inbound/rev/6891e4414ffaa50352ffdbab21997a6c431e0cae#l2.14

> -let line0 = new Error().lineNumber;
> -assertEq("foo".contains("bar"), false);
> +eval(`(function() "This is an expression closure.")`);

That is also non-release only warning...

> template <typename ParseHandler>
> bool
> Parser<ParseHandler>::warnOnceAboutExprClosure()
> {
> #ifndef RELEASE_BUILD
>     JSContext* cx = context->maybeJSContext();
>     if (!cx)
>         return true;
> 
>     if (!cx->compartment()->warnedAboutExprClosure) {
>         if (!report(ParseWarning, false, null(), JSMSG_DEPRECATED_EXPR_CLOSURE))
>             return false;
>         cx->compartment()->warnedAboutExprClosure = true;
>     }
> #endif
>     return true;
> }
Following warning is enabled on all branches, right?
Will it be removed or disabled near future?

> MSG_DEF(JSMSG_DEPRECATED_BLOCK_SCOPE_FUN_REDECL, 1, JSEXN_NONE, "redeclaration of block-scoped function `{0}' is deprecated")
Assignee: nobody → arai.unmht
Attachment #8740831 - Flags: review?(shu)
(In reply to Tooru Fujisawa [:arai] from comment #3)
> Following warning is enabled on all branches, right?
> Will it be removed or disabled near future?

Looks like it.

In any case fixing the build before merge is the main thing...
Flags: needinfo?(jorendorff)
(In reply to Jason Orendorff [:jorendorff] from comment #4)
> (In reply to Tooru Fujisawa [:arai] from comment #3)
> > Following warning is enabled on all branches, right?
> > Will it be removed or disabled near future?
> 
> Looks like it.

I meant to say, yes, this warning appears to be enabled on all branches.

It won't be removed in the near future. Deprecation is always a long play...
Comment on attachment 8740831 [details] [diff] [review]
Use not-non-release-only warning in js/src/tests/shell/warning.js.

Review of attachment 8740831 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/tests/shell/warning.js
@@ +8,5 @@
>  // Warning with JSEXN_NONE.
>  
>  enableLastWarning();
>  
> +eval(`{ function f() {} function f() {} }`);

So the goal here is to do *something* that generates a warning? Because this warning around functions-in-block will go away too eventually. Is there a more permanent warning we can use?
Attachment #8740831 - Flags: review?(shu) → review+
Thank you for reviewing :)

The testcase is to test getLastWarning shell builtin on JSEXN_NONE and one more non-JSEXN_NONE type.  I wanted to test both types, because they use different path for warning.name property:

>     if (report->exnType == JSEXN_NONE)
>         nameStr = JS_NewStringCopyZ(cx, "None");
>     else
>         nameStr = GetErrorTypeName(cx->runtime(), report->exnType);

So, yes, I want to do something that generates warning messages with JSEXN_NONE there.


Then, currently there are following warning message that uses JSEXN_NONE but not related to deprecation.

> MSG_DEF(JSMSG_ALREADY_HAS_PRAGMA,      2, JSEXN_NONE, "{0} is being assigned a {1}, but already has one")
> MSG_DEF(JSMSG_STMT_AFTER_RETURN,       0, JSEXN_NONE, "unreachable code after return statement")
> MSG_DEF(JSMSG_USE_ASM_TYPE_OK,         1, JSEXN_NONE,    "Successfully compiled asm.js code ({0})")

I have no idea how to hit JSMSG_ALREADY_HAS_PRAGMA in shell.

JSMSG_STMT_AFTER_RETURN was the reason why getLastWarning was added (bug 1170716), so I couldn't use it (because getLastWarning was added before JSMSG_STMT_AFTER_RETURN).  Maybe I could change the testcase to use JSMSG_STMT_AFTER_RETURN instead, but it might be better to use other warning message (also just for coverage).

JSMSG_USE_ASM_TYPE_OK could also be used, but it has no information about line/column...
https://hg.mozilla.org/integration/mozilla-inbound/rev/18ba8acba7902115a6f897d7d22b1cc33cb56008
Bug 1264085 - Use not-non-release-only warning in js/src/tests/shell/warning.js. r=shu
https://hg.mozilla.org/mozilla-central/rev/18ba8acba790
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
You need to log in before you can comment on or make changes to this bug.