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 forma
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)
https://bugzilla.m
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
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:
htt
# 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 indicatin
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 but
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 have
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 cod
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 unreadable,
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 initialize-by-
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)] () {
> uniqu
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 m
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 ship
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 what
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.
Y
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.
The Mercurial extensions to interact with Bugzilla -- bzexport and the like --
have been updated to handle 2fa details. No need to add API key support
yourself, or use some sketchy dude's user-repo fix for the issue! ;-) (As at
least three people have considered, two people have actually done
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 std::make_uniq
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/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 b
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
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
le
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
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 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
_
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 semanti
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 var
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_AddRefed sort of struct t
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 i
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 documentat
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)
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. T
Hey all,
mfbt recently picked up mozilla::UniquePtr, 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 safely embed
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/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, no
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.
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 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 c
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 Applicatio
On 01/07/2014 02:23 PM, Boris Zbarsky wrote:
> One reason I've seen 2 preferred to 4 (apart from keeping line lengths down)
> is that:
>
> if (somethingHere() &&
> somethingElse())
> doSomething();
>
> is less clear about what's condition and what's body the if body is than:
>
>
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 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
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
long
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
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 ove
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 inclu
On 12/10/2013 04:32 PM, Jeff Gilbert wrote:
> In my experience, docs for 'our' containers are also miles behind what the
> STL has available.
This, not unfamiliarity to new developers, is the big issue. Developers have
to learn new APIs all the time. STL versus something else shouldn't be that
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 err
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/
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 02:10 PM, Axel Hecht wrote:
> I wonder how far we can get by doing something along the lines we use for
> webfonts, starting to do the best we can with the data we already have, and
> improve once the perfect data is local.
Having the Intl.Foo algorithms returning different data ov
On 10/15/2013 07:18 PM, Brian Smith wrote:
> My (naive) understanding is that the Windows has its own API that does
> what ICU does. I believe that Internet Explorer 11 is an existence
> proof of that. If we used the Windows API on Windows, maybe we could
> avoid building ICU altogether on Windows.
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 adj
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 e
I use http://whereswalden.com/2011/11/03/how-i-organize-my-mozilla-trees/ to
organize all my trees on the one machine I use (a laptop). That's one machine,
so a bit easier to deal with than your "spread around" setup. I develop on
Windows on occasion, but I don't do it often enough for anythin
On 07/30/2013 11:27 AM, Ehsan Akhgari wrote:
> I just landed bug 895322, which removes the MOZ_STATIC_ASSERT macro in C++
> code, and replaces it with the C++11 static_assert keyword. You should use
> static_assert in C++ code from now on.
A belated note: MOZ_STATIC_ASSERT was valid at top level,
Because you don't know the underlying type of, say, uint32_t, it's historically
been difficult to printf them. Common approaches included just assuming %u
would work (and wouldn't generate format-mismatch compiler warnings), or using
%lu and casting to (unsigned long). Bleh.
C99's has macros
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 non-
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
> js
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.
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 syst
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 do
On 07/11/2013 03:09 AM, Nicholas Nethercote wrote:
> On Thu, Jul 11, 2013 at 7:48 AM, Jeff Walden 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 que
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 Mo
Mozilla used to use NS_ABS to compute absolute values, but half a year ago we
switched to std::abs. Unfortunately, practical experience with std::abs has
pointed out various issues with it: the various overloads are confusingly split
across multiple headers, std::abs(int64_t) doesn't always wor
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.
http://mxr.mozilla.org/mozill
On 04/22/2013 04:34 PM, Norbert Lindenberg wrote:
> 3) Related to that, some properties are documented as part of the wrong
> object. For example, the String.prototype documentation shows a length
> property. String.prototype doesn't have this property; String instances do.
String.prototype is a
On 04/04/2013 01:55 PM, Daniel Holbert wrote:
> MSVC C4244 is by far our spammiest MSVC warning -- it's already disabled
> in /js/src due to its low value::trouble ratio.
Actually I think this is a mistake, one that we should fix at some point. I
have very little confidence that all of SpiderMon
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); // n
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 wri
On 11/13/2012 01:34 AM, Robert O'Callahan wrote:
> Why is "using mozilla::RangedPtr" required; is "RangedPtr" ambiguous?
It's not -- just the increasing concern about using-collisions if we open the
whole mozilla namespace, which we'd rather not do because of the possibility
(actuality, for Rang
I read newsgroups too little (or perhaps just enough, or too much, depending),
sorry for the kind-of-late response here...
On 10/10/2012 01:26 AM, ja...@hoppipolla.co.uk wrote:
> Do you have a concrete suggestion for how to improve this, in a way that
> works cross-browser?
Well, the cross-doma
On 11/12/2012 10:44 AM, Robert O'Callahan wrote:
> On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg 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 namespace A, an
On 10/17/2012 04:01 PM, Jim Porter wrote:
> the documentation only seems to say how to use httpd.js in xpcshell. Surely
> there's a simpler way to get started.
Historically httpd.js was designed so you could use it as an XPCOM component,
fully abstracted from anything. It's possible that's brok
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 does not help.
> MOZ_HAVE_CXX11_NULLPTR is defined, however.
The nullptr
81 matches
Mail list logo
