Re: What is future of editor mode-lines after the switch to clang-format?

[Tom Tromey]

Nathan> Unfortunately, it doesn't look like .dir-locals.el provides any way to
Nathan> set file modes, e.g. setting python-mode for moz.build file

That's correct, it's a hole in dir-locals (there's already a bug filed
against Emacs for this).  It's also easy to document how to update
auto-mode-alist, though.  Separate bits of elisp are already needed for
eslint, so requiring a bit more isn't really so bad.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent To Require Manifests For Vendored Code In mozilla-central

[Tom Tromey]

>> this should be: https://goo.gl/QZyz4x for the full specification.

Some code in DevTools is vendored by dropping webpack bundles into the tree.
The bundles are created by running a yarn command in the source repository;
this also copies the bundle into an M-C tree.

If these directories are going to have a moz.yaml, then either this
process will have to be changed upstream, or the moz.yaml spec will have
to change to account for this.

An example is devtools/client/shared/source-map

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: #pragma once?

[Tom Tromey]

> "Marco" == Marco Bonardo  writes:

Marco> See the previous pragma once proposal:
Marco> 
https://groups.google.com/forum/#!msg/mozilla.dev.platform/PgDjWw3xp8k/PLYQc5xoWmsJ

Something I didn't see in that thread is that, at least with GCC, pragma
once does not scale well.  See 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770

This could be somewhat fixed in GCC, but it never seemed worthwhile to
me, because header guards are easy and portable.  Also pragma once
always struck me as one of those things that crept in back when GCC was
lax about adding extensions.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Tom Tromey]

> "David" == L David Baron  writes:

David> I agree it would be good to have a somewhat more "proper" spec for
David> this.  In terms of process,  I think probably the most important
David> (and lowest overhead) aspect of "proper" is having the revision
David> history of the specification in publicly visible version control
David> (such as github), and a way for people to raise issues that will be
David> looked at.

How would I go about starting this?
I have never done anything with web standards before.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: SourceMap header

[Tom Tromey]

> "Boris" == Boris Zbarsky  writes:

>> https://github.com/source-map/source-map-rfc

Boris> Are there any plans to have a standard here?

All I found was this:
https://groups.google.com/forum/#!topic/mozilla.dev.js-sourcemap/SD8sZ_7VFpw

... my reading of that was that there wasn't interest on our part at the
time.  I suppose we could reopen that.

Boris> It really would be good
Boris> to have all UAs converge on a single format here, both for the header
Boris> and for the sourcemap itself, especially if we're going to have an
Boris> unprefixed name for the header...  Speaking of which, is there a plan
Boris> to register this header with IANA (see
Boris> )?

I believe there is a single format for the header and the sourcemap
itself; it's just that the spec is that Google doc and the way to change
the spec is to submit a PR against the (very quiet) RFC repo on github.

I'm not aware of anybody registering the header with the IANA.  However
I've only been working in this area for a few weeks.

Boris> Is there any web-page-observable behavior change from sourcemaps
Boris> (e.g. .stack on exceptions?), or is it all about how devtools behave?

It's only observable using devtools.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: SourceMap header

[Tom Tromey]

I intend to turn support for the SourceMap response header on by default
in nightly, and let it ride the trains.  It has not been developed
behind a preference.  The existing X-SourceMap header will still be used
if SourceMap is not seen; this matches the behavior of Chrome and
WebKit.

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1346936

Link to standard: 
https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit#

Testing: As far as I know there are no web-platform-tests; but we do
have mochitests for the feature.


The intent-to-ship guidelines say:

An Intent to Ship requires either a web platform test suite or such
issues to be filed explaining why such a test suite is currently
impossible or in the progress of being upstreamed.

In this case I think this does not apply, because as far as I'm aware
source maps are not part of any standard process; rather there is:

https://github.com/source-map/source-map-rfc

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Tom Tromey]

> "Bill" == Bill McCloskey  writes:

Bill> As part of the Quantum DOM project, we're going to be "labeling" all
Bill> runnables in the browser to say which document they're operating on.

I wonder whether this can be used to fix the various "run to completion"
bugs we've encountered in the debugger.  I don't know if I understand
the problems there well enough to do them justice, but basically the
issue is that the debugger needs to delay some runnables but not others,
and the approach currently used lets some slip through.  This shows up
in a very confusing way for the user, like some XHR callbacks still
being invoked while supposedly paused in the debugger.

The meta bug for the devtools side of this is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1074448
It has links to all the scenarios where we've encountered the bad behavior.

The wish-list fix is:
https://bugzilla.mozilla.org/show_bug.cgi?id=715376
aka "implement per-page event queue, to allow timeout 
grouping/prioritization/etc".
I wonder specifically if Quantum DOM is going to fix this one.

thanks,
Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Tom Tromey]

> "Paul" == Paul Adenot  writes:

Paul> Do we know whether `set follow-fork-mode child` in gdb would work ? If
Paul> not, can we fix it ? It would be a pretty good experience for most
Paul> developers that only care about the child.

I try it from time to time and file bugs with upstream gdb for the
problems I run into.  It works ok-ish but I wouldn't really recommend it
yet.  There's ongoing work in gdb to make this work more nicely, but I
don't think there's any easy place to track it.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux distro readiness for Rust in Gecko

[Tom Tromey]

> "Henri" == Henri Sivonen  writes:

Henri> Ubuntu and Fedora don't have any version of rustc anywhere at
Henri> all.

For Fedora it's in COPR, but of course that's not official, just
something to play with.

You can follow the Fedora Rust packaging process here:

https://bugzilla.redhat.com/show_bug.cgi?id=915043

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Tom Tromey]

>> That assumes that the 'Foo' of aFoo is stable across function
>> boundaries, which is not always the case.

Ehsan> No, it doesn't.  In the scenario above, all you're looking for is when
Ehsan> a value was computed, so you can quickly see an aDuck, aQuack,
Ehsan> aFoopyFoo and determine that the value was passed down from the
Ehsan> caller, until you get to a call site which passes in something that
Ehsan> doesn't start with an 'a'.

It was mentioned elsewhere in this thread that some code assigns to
arguments.  In these cases going up to the point of origination may miss
the spot that actually introduced the value.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to alter the coding style to not require the usage of 'virtual' where 'override' is used

[Tom Tromey]

Trevor> One might wish to mark Foo::IsAFoo override so the compiler
Trevor> checks it shadows Base::IsAFoo but both are still non virtual.

Yes, I agree, one might.  But that doesn't really have any bearing on
the present.

Right now, override is defined as only making sense on virtual
functions.  And, I think we should only develop using the language we
have -- not hypothetical future changes to the language.

Plus, we have automated rewriting tools.  If we're positing that C++
might change in this way, then I think it's equally valid to posit that
the tools will also change appropriately.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Testing for expected crashes in both C++ and js, for printf checking

[Tom Tromey]

Axel> The other "easy" way to reduce impact here is to reduce the use of
Axel> nsTextFormatter, or create a replacement that doesn't crash. L20n
Axel> would be one, or maybe there's C++ template stuff that can "taint"
Axel> values with their original types.

Tom> I don't think there is a compile-time solution to this part of problem,
Tom> because the substitution is done at runtime.

Tom> I think what is needed for this problem is a runtime check to verify
Tom> that the translated format string is consistent with the "primary" one.

I was thinking about this more and I realized you were correct.

If the formatter is a variadic template function, then it's possible to
ensure at runtime that a particular format option corresponds to the
type of the actual argument.

This approach would supply runtime safety.  Instead of crashing, the
formatter could return an error.

I think compile-time checking is also worth doing.  Maybe it's even
possible using some scary combination of constexpr and variadic
templates; fun!, though I imagine a compiler plugin is simpler.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Testing for expected crashes in both C++ and js, for printf checking

[Tom Tromey]

Axel> The other "easy" way to reduce impact here is to reduce the use of
Axel> nsTextFormatter, or create a replacement that doesn't crash. L20n
Axel> would be one, or maybe there's C++ template stuff that can "taint"
Axel> values with their original types.

Tom> I don't think there is a compile-time solution to this part of problem,
Tom> because the substitution is done at runtime.

Tom> I think what is needed for this problem is a runtime check to verify
Tom> that the translated format string is consistent with the "primary" one.

I was thinking about this more and I realized you were correct.

If the formatter is a variadic template function, then it's possible to
ensure at runtime that a particular format option corresponds to the
type of the actual argument.

This approach would supply runtime safety.  Instead of crashing, the
formatter could return an error.

I think compile-time checking is also worth doing.  Maybe it's even
possible using some scary combination of constexpr and variadic
templates; fun!, though I imagine a compiler plugin is simpler.

Tom
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Testing for expected crashes in both C++ and js, for printf checking

[Tom Tromey]

> "Axel" == axel-4eJtQOnFJqFBDgjK7y7TUQ  
>  writes:

Axel> We can only do this in the compiler if we actually compiled each
Axel> localized version by itself.

Yes, I see what you mean.

Axel> The other "easy" way to reduce impact here is to reduce the use of
Axel> nsTextFormatter, or create a replacement that doesn't crash. L20n
Axel> would be one, or maybe there's C++ template stuff that can "taint"
Axel> values with their original types.

I don't think there is a compile-time solution to this part of problem,
because the substitution is done at runtime.

I think what is needed for this problem is a runtime check to verify
that the translated format string is consistent with the "primary" one.

Tom

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Testing for expected crashes in both C++ and js, for printf checking

[Tom Tromey]

> "Axel" == axel-4eJtQOnFJqFBDgjK7y7TUQ  
>  writes:

Axel> I'm talking actual crashes, and I don't know how we would fix the
Axel> text formatter. I'm glancing at
Axel> 
http://mxr.mozilla.org/mozilla-central/source/xpcom/glue/nsTextFormatter.cpp#778,
Axel> and I had no idea how to fix the C++ API there.

Axel> bug 1133554#c2 is a bug where we got it wrong in en-US, too. Doesn't
Axel> crash, but produces undesirable results.

Axel> Note, folks using the stringbundle.formatStringFromName just use a
Axel> wstring array. The only code paths affected are those that get the
Axel> string, and explicitly call into nsTextFormatter from c++.

I think the best answer for C++ is to write a compiler plugin to do
format checking.

GCC already has code to check that a format string matches the
arguments.  However, it can't be applied in several places in the tree
because:

* Various printf-likes in the tree extend the list of formats.
  For example, JS uses %hs to print a char16_t*.
  (And nsTextFormatter uses %S for this same thing, oops.)

* The in-tree printf-likes sometimes use the same format characters as
  printf to mean different things.  For example, nspr uses %l to mean
  32-bit, whereas printf uses it to mean sizeof(long).

* Some printf-likes, like nsTextFormatter, use a char16_t* as the format
  string.

There are GCC bugs open about all of these.

There's also the issue of looking up the format string in a message
catalog.  GCC has support for this, too, but I don't know offhand
whether it can handle the approach used here.

It's possible to fix all these things in the compilers.  The advantage
of a plugin is that nobody has to wait for a compiler upgrade to use it
to find the bugs.

I think it's worth doing.  Before I learned about the various problems,
I took a stab at using the GCC format attributes, and amidst all the
nit-picking there are some genuine bugs.

Tom


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform