> I think what we should do is confirm that strict warnings as errors is
> actually turned on for xpcshell, and if so, where this happens.
Indeed. Can you set a breakpoint in toggleWerror and see what trips it?
Gavin
On Thu, May 8, 2014 at 7:02 AM, Eddy Bruel wrote:
> To be clear, I don't actua
To be clear, I don't actually know where the werror flag for xpcshell
tests is set.
What I've observed is:
-If we Cu.import a JSM that requires module X, and then also require
module X from head_dbg.js after that, all is well.
-If we require module X from head_dbg.js first, and then als
To elaborate:
- Bug 524781 is still open
- I don't see any reference to -werror or -S in runxpcshelltests.py
Gavin
On Wed, May 7, 2014 at 4:48 PM, Gavin Sharp wrote:
>> When xpcshell tests are run, they flip a bit on the initial JSContext that's
>> off by default that tells spidermonkey "make th
> When xpcshell tests are run, they flip a bit on the initial JSContext that's
> off by default that tells spidermonkey "make the strict warning messages
> into error messages".
Do you have a pointer to where this happens? I've never heard of this,
and couldn't find it MXRing.
Gavin
On Wed, May
On 5/7/14, 4:21 PM, Gavin Sharp wrote:
What does "get rid of strict warnings as errors for xpcshell tests"
mean in practice?
It means that our non-standard spidermonkey "strict mode" (not the
actual strict mode) console warnings would continue to simply be console
warning messages rather than
On Tue, May 6, 2014 at 1:49 PM, Eddy Bruel wrote:
> I would like to propose that we get rid of strict warnings as errors for
> xpcshell tests. To quote Nick Fitzgerald: "The strict-warnings-as-an-error
> feels like having some arbitrary linter forced upon our development that
> isn't very useful."
On 5/6/14, 5:40 PM, Fitzgerald, Nick wrote:
On 5/6/14, 5:31 PM, Jonas Sicking wrote:
Are these warnings ever useful enough that this is worth it?
Personally, I think not. Bill seemed to really like them. *shrug*
This was why I thought it might be easier to just make it optional.
IIUC, Eddy'
On 5/6/14, 5:31 PM, Jonas Sicking wrote:
Are these warnings ever useful enough that this is worth it?
Personally, I think not. Bill seemed to really like them. *shrug*
This was why I thought it might be easier to just make it optional.
___
dev-platfo
On Tue, May 6, 2014 at 4:13 PM, Fitzgerald, Nick
wrote:
> Perhaps a more extensible solution would be the option to turn the extra
> warnings on/off for different test suites.
Are these warnings ever useful enough that this is worth it?
/ Jonas
___
dev
On 5/6/14, 3:29 PM, Bill McCloskey wrote:
- Original Message -
From: "Chris Peterson"
To: dev-platform@lists.mozilla.org
Sent: Tuesday, May 6, 2014 3:11:40 PM
Subject: Re: Disabling strict warnings as errors in xpcshell
btw, I believe the JS team now uses the term "ext
- Original Message -
> From: "Chris Peterson"
> To: dev-platform@lists.mozilla.org
> Sent: Tuesday, May 6, 2014 3:11:40 PM
> Subject: Re: Disabling strict warnings as errors in xpcshell
>
> btw, I believe the JS team now uses the term "extra warnings&q
On 5/6/14, 1:49 PM, Eddy Bruel wrote:
Strict warnings as errors has been a continuous source of pain for the
devtools team. Substantial areas of our code area currently not strict
warning free.
The reason this leads to problems is that the way the werror flag is
propagated makes no sense: it is
The most annoying thing for me (other than seemingly arbitrary changes
causing whole suites to fail despite correct functionality) is that it
breaks duck typing and causes code like:
if (obj.quacks) {
...
}
to fail tests. So in these cases, we are forced to write code something
like:
Strict warnings as errors has been a continuous source of pain for the
devtools team. Substantial areas of our code area currently not strict
warning free.
The reason this leads to problems is that the way the werror flag is
propagated makes no sense: it is a context wide flag, which individua
14 matches
Mail list logo
