On 9/10/19 7:55 AM, Dave Townsend wrote:
> How often do we go back and land those tests and comments after the fix has
> been in the release builds for a suitable amount of time?
I always land my tests...at some point. I don't know if everyone else
adequately remembers to do so. We don't
Those of you longer in the tooth may remember Firefox was successfully
exploited in Pwn2own 2012...and we didn't have to lift a finger to fix it. We
already had -- in the Firefox release shipping days later. 臘
https://bugzilla.mozilla.org/show_bug.cgi?id=735104 (pwn2own bug)
On 8/6/19 8:16 AM, Anne van Kesteren wrote:
> On Sat, Jul 20, 2019 at 2:05 AM Jeff Walden wrote:
>> (*Only* valid UTF-8: any invalidity, including for WTF-8, is an immediate
>> error, no replacement-character semantics applied.)
>
> Wouldn't adding this allow you to la
On 7/20/19 4:41 PM, Nicholas Nethercote wrote:
> This is excellent news. Do you have any measurements showing perf effects?
Perf changes should have first become visible with the landing of bug 1554362.
There was one quasi-automatically-reported perf improvement, on the Sheets
raptor test:
# Intent to ship: UTF-8 parsing of external
# Intent to ship: Hashbang syntax
## Introduction
As JS metastasizes from the web to Node and shell scripts and the like, it
becomes useful to run scripts directly in the shell and let the shell decide
how. The traditional way to do this is with an initial hashbang (or shebang)
line
On 2/17/19 11:40 PM, Henri Sivonen wrote:
> Rust, which combines the
> perf benefits of -fstrict-aliasing with the understandability of
> -fno-strict-aliasing?
This is not really true of Rust. Rust's memory model is not really defined yet
https://doc.rust-lang.org/reference/memory-model.html
On 2/21/19 11:56 AM, L. David Baron wrote:
> (What's the opinion of TC39 on shipping features that are at stage
> 3? That doesn't seem obvious from
> https://tc39.github.io/process-document/ .)
Stage 3 is traditionally where it becomes okay to ship stuff, and it's the
usual dividing line we
Hi all,
In the distant past, SpiderMonkey APIs consumed source text as two-byte UCS-2
or one-byte |const char*|. Was one-byte text ASCII? UTF-8? EBCDIC?
Something else? Who could say; no one thought about text encodings then. *By
happenstance* one-byte JS text was Latin-1: a byte is a
jsapi.h and jsfriendapi.h are mega-huge, monolithic headers. A one-stop shop
is maybe (maybe) convenient for users. But it's terrible for Gecko and
SpiderMonkey: touching jsapi.h rebuilds the world. (The one-stop shop approach
is also pretty terrible for users because js*api.h are
Recent gcc adds a warning, -Wclass-memaccess, that warns if you use memset or
similar on a non-trivial type -- in other words, a type that requires something
be done to initialize instances of it (set fields, call a user-defined
constructor, init a vptr, etc.). The reason is that
On 11/16/2017 08:35 AM, Ben Kelly wrote:
> I would like to use initialized lambda capture as I think it will allow
> move-only objects to be used in lambdas like this:
>
> UniquePtr uniqueThing = MakeUnique();
> nsCOMPtr r = NS_NewRunnableFunction([uniqueThing =
> Move(uniqueThing)] () {
>
On 12/22/2016 02:22 AM, Eric Rahm wrote:
> The key point for me is that we're hiding the return. I'm fine with the
> more verbose
> explicitly-return-and-make-it-easier-for-the-reviewer-to-call-out-issues
> form. I understand this is going to have differing opinions -- I think
> there's merit to
On 05/14/2016 06:58 AM, Philip Chee wrote:
> Given the "two different implementations rule" is there any suitable
> alternative to ICU? I mean besides rolling our own.
No, or at least not something cross-platform. It's probably possible to do
something using Windows APIs, that would only be
On 04/30/2016 01:26 PM, L. David Baron wrote:
> I still find it sad that ECMAScript Intl came (as I understand it)
> very close to just standardizing on a piece of software (ICU)
I'm fuzzy on the details as well, but I don't believe it was ever going to be
the case that the spec would be "do
On 04/29/2016 08:30 AM, sn...@snorp.net wrote:
> The engineers in Platform consistently want to dismiss mobile-specific
> issues, and this is a great example. If you really want to get ICU into
> Fennec, find a way to do it without bloating the APK size instead of bullying
> the Fennec folks.
On 04/28/2016 10:00 AM, Jonathan Kew wrote:
> Thoughts?
Another option is to ship a WinXP-specific Firefox build that doesn't provide
ICU and ECMAScript's Intl functionality.
This would break anyone's expectation that any version of Firefox past the
mid-30s somewhere has Intl available in it.
On 08/02/2015 07:17 AM, smaug wrote:
MakeAndAddRef would have the same problem as MakeUnique. Doesn't really tell
what type is returned.
For the MakeUnique uses I've added (doubtless many more have popped up since),
I've pretty much always tried to use |auto|. MakeUnique, and
Seeing this a touch late, commenting on things not noted yet.
On 04/27/2015 12:48 PM, Ehsan Akhgari wrote:
I think we should change it to require the usage of exactly one of these
keywords per *overridden* function: virtual, override, and final. Here
are the advantages:
* It is a more
On 12/26/2014 07:24 AM, Wesley Hardman wrote:
s = Some text;
console.log(s);
With javascript.options.strict set to true, it outputs ReferenceError:
assignment to undeclared variable s. Are there any advantages to actually
fixing it? The code obviously works just fine either way.
It's
On 12/22/2014 08:08 AM, Paolo Amadini wrote:
Maybe we could make available
an opt-in code linting solution - and these typos would become errors,
not warnings,
One substantial problem from a JS engine point of view is that we're
implementing a specification. That specification says these
On 12/23/2014 10:48 AM, L. David Baron wrote:
Our convention has always been to pass raw pointers, generally with
the assumption that the caller is expected to ensure the pointer
lives across the function call.
Like Eric, I would like us to move away from this convention over time, or at
On 12/17/2014 08:31 AM, Nathan Froyd wrote:
It's worth noting that enums with explicit types don't work in all cases
with our current B2G compiler, see bug 1058561.
Also gcc will wrongly warn (and you can't turn off the warning, even in -Werror
builds) if you use |enum Foo : T| as the type of
On 10/01/2014 12:57 AM, Kan-Ru Chen (陳侃如) wrote:
It seems all the compilers we use support the c++11 in template,
could we start using it in new code?
Go ahead. It's already in pretty wide use, actually, but old habits (and
caution) die hard with a lot of people.
Jeff
Bah, stupid broken newsgroup threading meaning I thought nobody'd replied to
the original message yet. :-(
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 09/18/2014 04:18 PM, Kent James wrote:
Substituting var for let does not result in code that behaves identically to
previous code, so I can't see why that would be proposed.
The proposal would be to perform the substitution only for let at body level
of a function. (And for global let --
On 08/15/2014 12:03 AM, Gijs Kruitbosch wrote:
Last I checked, AMO's review flagging tools were all regex-based. I doubt
even issue 1 is easily regex-able. :-(
Pretty sure they do syntax checks, at least, I think using Reflect.parse, or at
least with an embedded SpiderMonkey, unsure which.
On 08/14/2014 10:57 AM, Chris Peterson wrote:
Does chrome and add-on JS code default to JSVERSION_1_8?
It defaults to the latest version, whatever that is, so warning doesn't end up
being reasonable.
I do not think the SpiderMonkey team is smart enough to have implemented both
the old
On 08/12/2014 10:06 AM, Ehsan Akhgari wrote:
It could also be solved with making operator T*() explicit, but neither of
these options are something that we can use in our code base today.
So at risk of adding yet another flavor of thing: why not introduce an
already_AddRefedT sort of struct
On 08/13/2014 07:44 AM, Ehsan Akhgari wrote:
If that is the goal, then I don't agree that is a useful outcome at all. I
*do* wish that there were better *and* safer ways of doing more things
automatically but ownership transfers are inherently unsafe operations that
are expressed using
An issue with MakeUnique that I forgot to mention: you can't pass literal
nullptr to MakeUnique.
This problem happens because gcc 4.6 doesn't support true nullptr, and that
interacts poorly with perfect forwarding. See the long comment in mfbt/Move.h
for details. *Only* b2g-ics will break
On 08/05/2014 07:02 AM, David Rajchenbach-Teller wrote:
If this obsoletes some of mfbt/Scoped.h, can you remove/document this?
I already replaced the file-description comment with
/* DEPRECATED: Use UniquePtr.h instead. */
and repeated the same thing at the very start of class-level
On 08/01/2014 03:48 AM, Neil wrote:
Only UniquePtr's own copy and assignment operators should take UniquePtr.
Other call sites should either take const UniquePtr (if they will not take
ownership of the pointer), UniquePtr (if they may or may not need to take
ownership of the pointer) or
Hey all,
mfbt recently picked up mozilla::UniquePtrT or T[], a smart pointer for
objects created using |new| or |new[]|. UniquePtr will automatically |delete|
or |delete[]| its pointer when it's destroyed. (You can also define custom
deletion policies if you want.)
Additionally, you can
On 07/31/2014 04:52 PM, Robert O'Callahan wrote:
Is there anything blocking us from mass-removing nsAutoPtr/nsAutoArrayPtr
in favour of UniquePtr?
I'm not unsure what the state of mass-rewriting tools are these days, to start.
But assuming they're up to snuff, there might or might not be.
On 04/28/2014 05:59 AM, Henri Sivonen wrote:
Hopefully we didn't remove collation rules, since that's the part we
are supposed to be using ICU for! :-)
I'm uncertain exactly what the terminology means necessarily for us, but
intl/icu-patches/genrb-omitCollationRules.diff exists because a flag
On 04/24/2014 05:49 AM, Till Schneidereit wrote:
Questions:
* Are we building and shipping dead code in ICU on B2G?
I don't know the state of ICU on B2G, but if we have it enabled there, then
almost certainly, yes.
There's doubtless *some* dead code in the ICU we build, yes. (I
On 04/25/2014 02:10 AM, Henri Sivonen wrote:
Different means old, right? Having an old version is a correctness
problem, if the CLDR has changed since.
Depends what's considered correctness. The ECMA Internationalization API
doesn't specify behavior, so older just means not-as-good, not
On 04/01/2014 09:44 AM, Trevor Saunders wrote:
b2g jb using gcc 4.7 was what I guessed as well, but
http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-hamachi/1396314004/b2g_mozilla-central_hamachi_dep-bm72-build1-build10.txt.gz
seems to provide some evidence to the
On 04/01/2014 02:32 PM, Ehsan Akhgari wrote:
What do people feel about my proposal? Do you think it improves writing
and reviewing thread safe code to be less error prone?
As I said in the bug, not particularly. I don't think you can program with
atomics in any sort of brain-off way, and I
On 03/28/2014 02:01 PM, Andrew Sutherland wrote:
It's my understanding that the existing idiom used throughout the Thunderbird
tree is still okay to do since the prototype chain is created at object
initialization time and so there's no actual mutation of the chain:
function Application()
On 01/07/2014 02:20 AM, Ms2ger wrote:
Based on the discussion in #jsapi yesterday, I'm not sure that most JS
hackers is necessarily accurate.
I think there's a rough consensus. And I'd note only a few of us were really
active in that conversation, and I'm going somewhat off memory of what
On 01/06/2014 04:27 PM, Robert O'Callahan wrote:
That's just not true, sorry. If some module owner decides to keep using
NULL or PRUnichar, or invent their own string class, they will be corrected.
At least the former isn't true, as far as I remember. It took convincing to
get JS to move over
On 01/06/2014 04:46 PM, Jason Orendorff wrote:
I'm fine with changing SpiderMonkey in whatever way is necessary to stop
these threads forever.
Pretty sure I've said the same thing in other places, that we should have
something everyone hates and use it everywhere. Definitely I've said it to
I'm writing this list, so obviously I'm choosing what I think is on it. But I
think there's rough consensus on most of these among JS hackers.
JS widely uses 99ch line lengths (allows a line-wrap character in 100ch
terminals). Given C++ symbol names, especially with templates, get pretty
On 01/06/2014 08:35 PM, Joshua Cranmer wrote:
And a '_' at the end of member names requires less typing than 'm' + capital
letter?
This started, and still largely is, an Ion convention. Lots of existing code
doesn't use it, and I haven't much worked on code that does. But as I said,
I'm
On 12/16/2013 03:09 PM, Gregory Szorc wrote:
Perhaps Reflect.parse() could grow a new option to expose comment nodes or
could attach comment metadata to specific node types?
It's really not possible to do the latter. Comments don't appertain to
specific nodes at all. They're just random
On 12/16/2013 01:17 PM, Gregory Szorc wrote:
Does SpiderMonkey expose documentation blocks to the AST? If not, should it?
No, and probably not. Comments are not tokens, so they're not in the AST.
Right now SpiderMonkey pretty much just throws them away (except to the extent
the comment
On 11/15/2013 03:01 PM, Jeff Walden wrote:
You need to compile as C++11 to use sufficiently Mozilla headers.
...sufficiently-recent, that is.
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev
You need to compile as C++11 to use sufficiently Mozilla headers. If you look
at the error you're getting, it's clear your compiler isn't treating
|static_assert| as referring to the built-in construct in C++11. Adding
-std=c++0x or -std=gnu++0x to your commandline should get you past this
On 11/02/2013 05:24 PM, bbo...@gmail.com wrote:
2.0 Creating a .mozconfig file
Make that creating a mozconfig file. Both names are supported, but mozconfig
is preferable: it's visible in directory listings and such, and it's easier to
create on Windows.
Jeff
On 10/16/2013 12:45 AM, Karl Tomlinson wrote:
When sync I/O is performed to read in-binary-object data, how is
that better?
Just readahead?
Readahead, it being part of the binary/libxul/whatever so already one coherent
file to load, etc. I'm not aware that you can reasonably predict
On 10/15/2013 06:06 PM, Benjamin Smedberg wrote:
Do we need this data for any language other than the language Firefox ships
in? Can we just include the relevant language data in each localized build of
Firefox, and allow users to get other language data via downloadable language
packs,
On 10/10/2013 02:27 PM, Axel Hecht wrote:
I agree with the sentiment, but not on the eample.
Having been a peer of the XSLT module back in the days, we started with a
rather js DOM like implementation, and moved over to a pure nsIContent etc
impl, and each step there won us an order of
On 10/02/2013 06:06 PM, Botond Ballo wrote:
Having to repeat 'expr' is rather unfortunate, and C++14
fixes that. You can now write:
auto function(A a, B b)
{
return expr;
}
The only restriction is
that if there are multiple return
On 09/04/2013 05:24 AM, Benjamin Smedberg wrote:
MOZ_OVERRIDE implies virtual, you get a compile error when you put
MOZ_OVERRIDE on a non virtual
It does? That surprises me (it certainly wasn't the original intent of
NS_OVERRIDE). There are certainly cases where we want to override
On 08/20/2013 09:01 AM, Boris Zbarsky wrote:
DOMJSClass.h only needs various forward-declarations, mostly. The exceptions
are:
2) It needs the definition of JSClass, for a member of the DOMJSClass struct
and the DOMIfaceAndProtoJSClass struct. Unfortunately, this is defined in
jsapi.h
On 08/02/2013 08:09 PM, Brian Smith wrote:
2. It is reasonable to expect that std::whatever works as the C++ standard
says it should. It isn't reasonable to expect mozilla::Whatever to work
exactly like std::whatever. And, often, mozilla::Whatever isn't actually
the same as std::whatever.
Why
On 07/31/2013 01:25 AM, Brian Smith wrote:
Anyway, it would be easier to swallow the dependency on MFBT if it wasn't
so large (over 100 files now), if it tried to be (just) a polyfill for
missing standard library features, and if it could easily be used
independently of the Gecko build system.
On 07/21/2013 11:44 AM, Justin Lebar wrote:
That's a fair point. Maybe we should call ours mozilla::Move and
mozilla::Forward instead. That way we can still easily change them to
std::move and std::forward, but there's no possibility of a collision.
This is pretty much always what we've done
On 07/11/2013 03:09 AM, Nicholas Nethercote wrote:
On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden jwalden+...@mit.edu wrote:
Establishing one-day turnaround time on reviews, or on requests, would
require a lot more polling on my review queue.
You poll your review queue? Like, by visiting
On 07/09/2013 07:17 PM, Joshua Cranmer wrote:
I've said this before, not sure it's written in wiki-stone, maybe it should
be: if you get a review request, respond same-day either with the actual
review, or an ETA or promise to review by a certain date.
For reviewers who are not Mozilla
For anyone who's not reading planet (or hasn't read it in the last fifteen
minutes ;-) ), I recently landed a new mfbt header that exposes slightly safer
versions of memset(.., 0, ...), memcpy, and memcmp for use on C++ types,
particularly ones where sizeof(T) 1.
Gecko (not specs) has a concept of writable [Replaceable] attributes. It uses
them for these properties:
window.innerWidth
window.innerHeight
window.outerWidth
window.outerHeight
window.screenX
window.screenY
window.opener
window.status
window.name
In our implementation, a
On 12/20/2012 03:38 PM, Boris Zbarsky wrote:
On 12/20/12 12:14 PM, Jeff Walden wrote:
Setting it creates a shadowing property on window itself, using the exact
value passed in.
// Current Gecko
alert(typeof window.screenX); // number
window.screenX = 123;
alert(typeof
On 11/12/2012 10:44 AM, Robert O'Callahan wrote:
On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg za...@panix.com wrote:
The scenario I'm concerned with is when a .cpp file does 'using namespace
A;' and then goes on to define a bunch of its *own* symbols; later someone
adds a symbol to
On 09/21/2012 05:07 AM, Henri Sivonen wrote:
What's the type of nullptr on Mac OS X 10.7 debug build? On tryserver,
the compiler complains that there’s no nullptr_t in namespace std when
using std::nullptr_t. Including cstddef does not help.
MOZ_HAVE_CXX11_NULLPTR is defined, however.
The
67 matches
Mail list logo
