On Thu, Feb 6, 2020 at 9:12 AM Boris Zbarsky wrote:
> 3) While ErrorResult::Throw taking just an nsresult still exists, it is
> deprecated and new code should not be adding new calls to it if that can
> be avoided.
>
We are attempting to add a static analysis that blocks new uses of
`NS_NewNamed
Bug 1560664 [0] stuck on central, so all of mozilla-central is compiled as
C++17 now.
Most C++17 language features should be usable; whether library features are
fully implemented across all of our supported compilers/standard libraries
is yet to be determined [5]. I will be updating our C++ usag
On Wed, Oct 30, 2019 at 11:36 AM Tom Ritter wrote:
>
> I will claim that the most common behavior of developers is to leave
> XPCOM_DEBUG_BREAK alone and not set it to any particular value. I bet most
> people haven't even heard of this or know what it does.
>
> With that env var unset, in Debug m
On Mon, Oct 14, 2019 at 3:58 AM Henri Sivonen wrote:
> On Mon, Oct 14, 2019 at 9:05 AM Gerald Squelart wrote:
> >
> > I'm in the middle of watching Chandler Carruth's CppCon talk "There Are No
> > Zero-Cost Abstractions" and there's this interesting insight:
> > https://youtu.be/rHIkrotSwcc?t=10
It is my pleasure to announce that Nika and Kris are XPCOM peers.
Nika has been doing great work in and around XPIDL: modernizing XPIDL
(Array, yay!), reorganizing the way we access XPIDL metadata at
runtime, and bringing the excitement of XPIDL to Rust.
Kris noticed that Nika was going to become
Hi all,
In working on upgrading our C++ support to C++17 [1], we've run into
some issues [2] surrounding the newly-introduced `std::byte` [3],
various Microsoft headers that pull in definitions of `byte`, and
conflicts between the two when one has done `using namespace std;`,
particularly at globa
On Sat, Jul 27, 2019 at 1:42 PM Botond Ballo wrote:
> If you're interested in some more details about what happened at last
> week's meeting, my blog post about it is now available (also on
> Planet):
>
> https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-
On Mon, Jul 22, 2019 at 11:45 AM Bobby Holley wrote:
> Can you confirm which types of builds enable this? Does --enable-release turn
> it on?
If you really want to build this locally, you can add `export
MOZ_LTO=cross` in your mozconfig. `--enable-release` does not
automatically enable LTO (cro
Hi all,
We now have link-time optimization (LTO) between Rust and C++ code
enabled on Nightly for all platforms (bug 1486042 [1]). There have
been some concerns about potential slowdowns when crossing the C++ <=>
Rust boundary due to non-inlineable function calls, and Stylo needed
to implement so
On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> It is, however, super poignant to me that uint32_t-indexing-on-x64 is
> pessimal, as that's precisely what our ns* containers (nsTArray) use
> for size, /unlike/ their std::vector counterparts, which will be using
> the more-optimal size_t.
nsT
The LLVM development list has been having a similar discussion,
started by a proposal to essentially follow the Google style guide:
http://lists.llvm.org/pipermail/llvm-dev/2019-June/132890.html
The initial email has links you can follow for more information. I
recommend starting here:
https://
TL;DR: We're making some changes to how inlined functions are handled
in our crash reports on non-Windows platforms in bug 524410. This
change should mostly result in more understandable crash stacks for
code that uses lots of inlining, and shouldn't make things any worse.
Some crash signatures ma
On Fri, Mar 15, 2019 at 9:32 AM Xidorn Quan wrote:
> Should we have some kind of policy to address duplicate dependencies in Gecko
> as well? Maybe I'm missing something but I don't think I'm aware of any
> previous discussion about this.
I remember IRC discussions about this, but there were so
On Wed, Feb 27, 2019 at 9:05 AM Axel Hecht wrote:
>
> Am 27.02.19 um 14:39 schrieb Nathan Froyd:
> > On Wed, Feb 27, 2019 at 6:22 AM Kartikaya Gupta wrote:
> >> On Wed, Feb 27, 2019 at 3:40 AM Axel Hecht wrote:
> >>>
> >>> Can we please not force
On Wed, Feb 27, 2019 at 6:22 AM Kartikaya Gupta wrote:
> On Wed, Feb 27, 2019 at 3:40 AM Axel Hecht wrote:
> >
> > Can we please not force bootstrap?
>
> +1. In general bootstrap isn't "rock solid" enough to force people
> into running it.
If people have problems with bootstrap (it doesn't do en
On Fri, Feb 8, 2019 at 9:08 AM Andreas Tolfsen wrote:
> Whilst I donāt have first hand experience, Phabricator has been
> known to struggle with large patches, such as the result of upgrading
> cargo dependencies under third_party/rust. Was a bug ever filed
> on this?
Bug 1492214 was filed for l
On Thu, Jan 10, 2019 at 6:15 PM Kyle Machulis wrote:
> In an effort to bring Marie Kondo memes to dev-platform, I'd like to
> propose an XPCOM tidying project.
+1.
> - Removal of [noscript] methods in interfaces in favor of direct calls via
> Cast() where possible.
> - Direct getters through Cas
On Fri, Jan 4, 2019 at 11:57 AM Nicholas Alexander
wrote:
> One reason we might not want to stop producing opt builds: we produce
> artifact builds against opt (and debug, with --enable-debug in the local
> mozconfig). It'll be very odd to have --enable-artifact-build and
> _require_ --enable-pgo
I'm excited to announce that we have bona fide arm64 windows nightlies
available for download!
https://archive.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
featuring full updater and installer support; see the
firefox-66.0a1.en-US.win64-aarch64* files in that directory. Thanks
to Tom
We have PREPROCESSED_IPDL_SOURCES in moz.build, which should at least
let you preprocess IPDL files before they get compiled. There are no
uses in the tree, but there are tests, so ideally you should not run
into *too* many issues.
-Nathan
On Thu, Dec 13, 2018 at 11:45 AM wrote:
>
>TL;DR: Is
On Thu, Dec 6, 2018 at 6:10 PM Gijs Kruitbosch wrote:
> Can someone elaborate on what this means for debugging on Windows, and
> for our onboarding story on Windows?
At least in terms of stepping through, examining variables, etc.,
clang-cl is on par with MSVC. If there are specific, stop-the-pr
On Fri, Nov 30, 2018 at 1:51 PM Ehsan Akhgari wrote:
> I think these are all great points. It seems like for Emacs, it is not
> actually necessary to sprinkle modelines across all of the files in your
> repository (per https://bugzilla.mozilla.org/show_bug.cgi?id=1023839#c7).
> For Vim, Benjamin
On Wed, Nov 21, 2018 at 4:45 AM David Teller wrote:
> What is our policy on using Unix signals on Firefox? I am currently
> reviewing a patch by external contributors that involves inotify's
> signal API, and I assume it's a bad idea, but I'd like to ask around
> first before sending them back to
On Wed, Aug 8, 2018 at 9:50 AM, Dirkjan Ochtman wrote:
> A related question: is there some place where I can follow along with plans
> relating to Rust upgrades for mozilla-central? As a Linux distribution
> packager, that might be useful information. (I remember seeing there was a
> Rust upgrade
On Wed, Aug 8, 2018 at 7:07 AM, wrote:
> What is plan for future Firefox ESR versions? Will ESR version require for
> build new Rust versions as they are releasing or will it stay on version on
> which was required for first ESR revision?
The plan is to keep the ESR versions on the Rust versio
JS-only builds now require that a suitable rustc and cargo be found at
configure time (bug 1444141, currently on inbound). The version
requirements are identical to Gecko's version requirements (Rust
1.27.0 at the time of this writing) and will be bumped in tandem with
Gecko's version requirement
On Wed, Jul 18, 2018 at 4:54 PM, Botond Ballo wrote:
> On Wed, Jul 18, 2018 at 4:13 PM, Boris Zbarsky wrote:
>> Am I correct in my reading that this would require the C++ standard library
>> to include an implementation of the web platform?
>
> Either to include one, or to be able to find and use
On Thu, Jun 28, 2018 at 7:35 PM, Emilio Cobos Ćlvarez wrote:
> Oh, I didn't realize that those peers were the only ones to be able to
> update the style guide, sorry. I guess it makes sense.
>
> I can revert the change if needed and try to get sign-off from some of
> those.
>
> Apologies again, I
Thanks for raising these points.
On Tue, Jun 26, 2018 at 10:02 PM, Adam Gashlin wrote:
> * Already vendored crates
> Can I assume any crates we have already in mozilla-central are ok to use?
> Last year there was a thread that mentioned making a list of "sanctioned"
> crates, did that ever come a
On Fri, Apr 13, 2018 at 9:37 AM, Emilio Cobos Ćlvarez wrote:
> Those changes I assume were generated with clang-format / clang-format-diff
> using the "Mozilla" coding style, so I'd rather ask people to agree in
> whether we prefer that style or other in order to change that if needed.
>
> Would p
FWIW, all these complaints (and more) have been raised in the bug.
I'm not entirely sure what we're going to do yet, but rest assured
that people are definitely aware of the issues.
Thanks,
-Nathan
On Fri, Apr 13, 2018 at 8:31 AM, Kartikaya Gupta wrote:
> On Fri, Apr 13, 2018 at 6:18 AM, Jonatha
On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen wrote:
> On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd wrote:
>> (Our release builds use -O2 for Rust code.)
>
> What does cargo bench use by default?
> (https://internals.rust-lang.org/t/default-opt-level-for-release-builds/4
Hi all,
In bug 1437627, I turned on incremental compilation for Rust for local
developer opt builds as the default behavior. Debug builds should be
using incremental compilation already, and automation builds continue
to *not* use incremental compilation, due to environmental
considerations that
On Wed, Jan 17, 2018 at 10:47 AM, Gabriele Svelto wrote:
> 1) Introduce a new observer service that would live alongside the
> current one (nsIObserverService2?). This will use a machine-generated
> list of topics that will be held within the interface itself instead of
> a separate file as I orig
On Thu, Jan 4, 2018 at 4:44 PM, Gabriele Svelto wrote:
> On 04/01/18 22:39, Ben Kelly wrote:
>> Or make your "generator"
>> create the idl which then creates the js/c++?
>
> I tried as that could have worked! Unfortunately it doesn't seem to be
> possible ATM. mach bailed out with a weird error w
On Wed, Jan 3, 2018 at 5:30 PM, Ben Kelly wrote:
> On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto wrote:
>> So after validating my approach in that bug (which is almost ready) I've
>> thought that it might be time to give the observer service the same
>> treatment. First of all we'd have a list
On Fri, Nov 24, 2017 at 11:35 AM, Eric Rescorla wrote:
> On Thu, Nov 23, 2017 at 4:00 PM, smaug wrote:
>> I guess I'd prefer UniquePtr::New() over MakeUnique to be more clear about
>> the functionality.
>
> This seems like a reasonable argument in isolation, but I think it's more
> important to m
C++14 constructs are now usable in mozilla-central and related trees.
According to:
https://developer.mozilla.org/en-US/docs/Using_CXX_in_Mozilla_code
this opens up the following features for use:
* binary literals (0b001)
* return type deduction
* generic lambdas
* initialized lambda captures
*
On Sun, Oct 29, 2017 at 7:37 PM, Kris Maglione wrote:
> On Sun, Oct 29, 2017 at 07:15:50PM -0400, Nathan Froyd wrote:
>>
>> For non-Android platforms, the good news here is that compiling Fennec
>> with clang was the last major blocker for turning on C++14 support.
>
>
Hi all,
Bug 1163171 has been merged to mozilla-central, moving our Android
builds over to using clang instead of GCC. Google has indicated that
the next major NDK release will render GCC unsupported (no bugfixes
will be provided), and that it will be removed entirely in the near
future. Switchin
On Thu, Oct 26, 2017 at 9:34 AM, Henri Sivonen wrote:
> As for the computer at hand, I want to put an end to this Nvidia
> obstacle to getting stuff done. It's been suggested to me that Radeon
> RX 560 would be well supported by distro-provided drivers, but the
> "*2" footnote at https://help.ubun
Does this user have a bugzilla :alias so that folks submitting patches
via MozReview or similar can just write r=build-peer or something,
rather than having to manually select the appropriate shared queue
after submitting their patch for review?
-Nathan
On Wed, Oct 11, 2017 at 1:41 PM, Chris Coop
On Fri, Oct 6, 2017 at 5:00 AM, Henri Sivonen wrote:
> Do we already have a C++ analog of Rust's test::black_box() function?
We do not.
> Specifically, this isn't the answer for GCC:
> void* black_box(void* foo) {
> asm ("":"=r" (foo): "r" (foo):"memory");
> return foo;
> }
Can you provide
On Thu, Sep 7, 2017 at 10:04 AM, Ben Kelly wrote:
> On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon
> wrote:
>
>> Here's the RFC of the overflow builtins:
>> http://clang-developers.42468.n3.nabble.com/RFC-Introduce-
>> overflow-builtins-td3838320.html
>> Along with the tracking issue: https://
TL; DR: apply
https://github.com/froydnj/gecko-dev/commit/12a80904837c60e2fc3c68295b79c42eb9be6650.patch
to get faster --enable-optimize local builds if you are working on
Stylo or touching Rust in any way. Please try to not commit it along
with your regular patches. =D
You may have noticed that
On Tue, Aug 1, 2017 at 12:31 PM, Alexis Beingessner
wrote:
> I was recently searching through our codebase to look at all the ways we
> use fallible allocations, and was startled when I came across several lines
> that looked like this:
>
> dom::SocketElement &mSocket = *sockets.AppendElement(fall
On Wed, Aug 2, 2017 at 7:37 AM, Enrico Weigelt, metux IT consult
wrote:
> On 31.07.2017 13:53, smaug wrote:
>> Reference counting is needed always if both JS and C++ can have a
>> pointer to the object.
>
> Anybody already thought about garbage collection ?
Reference counting is a garbage collect
Earlier this week, bug 1347963 landed, introducing a new
mozilla::RecursiveMutex type. A RecursiveMutex instance may be
acquired on the same thread while said thread is already holding the
lock; such behavior with mozilla::Mutex would result in deadlocks.
While we already have a recursively-acqui
On Mon, Jul 24, 2017 at 6:21 PM, Enrico Weigelt, metux IT consult
wrote:
> On 24.07.2017 20:40, Nathan Froyd wrote:
>> Sure, it's daily business for us, too. Mike cited examples in his
>> response (e.g. we cannot compile natively on 32-bit systems, Android
>> inc
On Mon, Jul 24, 2017 at 4:25 PM, Enrico Weigelt, metux IT consult
wrote:
> On 24.07.2017 16:00, Mike Hoye wrote:
>> Unfortunately we have to build _for_ a number of our supported operating
>> systems without being able to build _on_ those operating systems.
>
> Is that a big problem ?
>
> At least
On Thu, Jul 6, 2017 at 2:28 AM, Simon Sapin wrote:
> Would it make sense to allow arbitrary Cargo sub-commands? In Servo I end up
> using `mach cargo update` for manipulating Cargo.lock, `mach cargo rustc`
> for passing debugging options to the compiler, etc.
Maybe! I'm less sure of how some of
Cargo recently added a subcommand, `cargo check`, to perform type
checking of Rust crates without the additional step of code
generation. As code generation tends to dominate Rust compilation
times, `cargo check` speeds up the edit-borrow checker-bewilderment
cycle.
This command is now available
On Tue, Jun 20, 2017 at 12:19 PM, Ehsan Akhgari wrote:
> On 06/20/2017 08:34 AM, Nathan Froyd wrote:
>> There is some kind of interaction with the underlying machine (see
>> comment 104 in said bug, where the binaries perform identically on a
>> local machine, but differen
On Tue, Jun 20, 2017 at 3:59 AM, Julian Seward wrote:
> On 20/06/17 05:58, Boris Zbarsky wrote:
>> On 6/19/17 11:22 PM, Gregory Szorc wrote:
>>> The decision to strip Nightly builds does not come lightly. Read 1338651
>>> comment 111 and later for the ugly backstory.
>>
>> It's still really confus
On Thu, Jun 15, 2017 at 2:02 PM, Brendan Dahl wrote:
> Headless will run less of the platform specific widget code and I don't
> recommend using it for platform specific testing. It is targeted more at
> web developers and testing regular content pages. There definitely will be
> cases where regul
On Thu, Jun 15, 2017 at 6:32 AM, Henri Sivonen wrote:
> encoding_rs landed delivering correctness, safety, performance and
> code size benefits as well as new functionality.
Thanks for working on this.
> * We don't have third-party crates in m-c that (unconditionally)
> require rust-encoding. H
On Wed, Jun 14, 2017 at 2:14 PM, Andrew Swan wrote:
> Sorry, this was misleading, I meant this as a narrow comment about the
> (still hypothetical!) scenario where something is prototyped as an
> experiment but we're in the process of landing it in m-c along with all the
> other built-in apis. Of
On Wed, Jun 14, 2017 at 12:54 PM, Steve Fink wrote:
> On 06/14/2017 09:23 AM, Andrew Swan wrote:
>> I would hope that if we have promising or widely used webextension
>> experiments, that the relevant peers would be aware of them when reviewing
>> changes that might affect them but of course chang
Hi all,
Bug 1341404 has landed on mozilla-inbound, bringing --disable-optimize
--enable-debug builds to our infrastructure on our Tier 1 desktop
platforms. Folks have complained several times this year that various
changes silently broke this style of build because said style was not
tested. Ide
On Thu, Jun 1, 2017 at 8:51 PM, Mike Hommey wrote:
> I'll take on the
> occasion to remind or inform people that recent versions of GCC (all
> versions we support, actually), and clang >= 4.0 support a -Og flag,
> which is a level of optimization that is meant to be more debuggable, so
> I'd advis
Bug 1356991 (build Stylo in nightly, but keep Stylo pref'd off) will
be landing soonish, and building Stylo requires Clang (as a separate
tool from the primary compiler) on all platforms. On Tier 1
platforms, `mach bootstrap` will be downloading Clang from our
infrastructure, instead of installing
On Sat, May 20, 2017 at 6:36 AM, Martin Thomson wrote:
> Hmm, these are all -Wsign-compare issues bar one, which is fixed
> upstream. We have an open bug tracking the warnings
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1307958 and specifically
> https://bugzilla.mozilla.org/show_bug.cgi?id=1
On Thu, May 11, 2017 at 5:15 PM, Jeff Muizelaar wrote:
> On Fri, Apr 14, 2017 at 10:46 AM, Nathan Froyd wrote:
>> With these options, you get a browser that runs quickly (i.e. no DEBUG
>> assertions in C++ code), but still lets you debug the Rust code you
>> might be wor
On Mon, May 8, 2017 at 1:26 PM, Alex Gaynor wrote:
> Top-line question: Do you rely on being able to run mochitests from a
> packaged build (`--appname`)?
I don't think it's a *fundamental* part of development workflows, but
I know folks have found value in being able to run tests--including
but
On Tue, May 9, 2017 at 10:39 AM, Boris Zbarsky wrote:
> On 5/9/17 9:17 AM, Nathan Froyd wrote:
>> The argument I have always heard, Gecko-wise and elsewhere [1], is to
>> prefer pointers for modification
>
> This is for primitive-typed out or inout params, right?
I don&#
On Tue, May 9, 2017 at 5:58 AM, Emilio Cobos Ćlvarez wrote:
> Personally, I don't think that the fact that they're not used as much as
> they could/should is a good argument to prevent their usage, but I don't
> know what's the general opinion on that.
The argument I have always heard, Gecko-wise
On Thu, May 4, 2017 at 12:32 PM, Henri Sivonen wrote:
> On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd wrote:
>> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen wrote:
>>> Is it feasible (with reasonably low effort) to introduce a new XPIDL
>>> type that is a pointer to
On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen wrote:
> Is it feasible (with reasonably low effort) to introduce a new XPIDL
> type that is a pointer to a non-refcounted immutable static object in
> C++ and still gets bridged to JS?
You can certainly have static objects with what amount to dummy
A
Bug 1353810, recently merged to central, adds a new configure option
--enable-debug-rust. This option enables compiling the Rust code
in-tree with debug-friendly settings (no optimization, multiple
codegen units for faster compiles, etc. etc.) even if you are
compiling with --disable-debug. The i
On Fri, Mar 17, 2017 at 6:31 PM, Mike Hommey wrote:
> On Fri, Mar 17, 2017 at 03:53:14PM -0400, Boris Zbarsky wrote:
>> On 3/17/17 3:40 PM, Ted Mielczarek wrote:
>> > We do try to build js/src pretty early in the build
>>
>> We do? It's always the last thing I see building before we link libxul.
We do not. Bug 1299187 is related to such work, but that bug only
covers unexporting symbols that 3rd party software would access. bz
has filed a few bugs for removing nsIDOM* methods that only existed
due to 3rd party compat concerns, but I don't think there's been
systematic evaluation of what'
On Thu, Feb 23, 2017 at 1:25 AM, Henri Sivonen wrote:
>> Alternately you could just generate it at build time, and we could pass
>> the path to $(DIST)/include in a special environment variable so you
>> could put the header in the right place.
>
> So just https://doc.rust-lang.org/std/env/fn.var.
On Fri, Dec 23, 2016 at 6:39 PM, wrote:
> On Saturday, December 24, 2016 at 3:08:21 AM UTC+11, Nathan Froyd wrote:
>> paves the way for being able to compile in C++14
> So, can we start using the good stuff right now, or should we wait for a
> proper "go" signal?
W
As per the subject. This job is strictly for smoketest purposes;
there are no tests being run on the result of the build.
As these are tier-2 builds, build failures will not be cause for
backouts. However, as clang complains about a wider range of problems
than our current MSVC builds do, and as
On Fri, Dec 23, 2016 at 11:37 AM, Mike Hoye wrote:
> On 2016-12-23 11:08 AM, Nathan Froyd wrote:
>> Bug 1322792 has landed on inbound, which changes configure to require
>> GCC 4.9 to build; our automation switched over to GCC 4.9 for our
>> Linux builds earlier this week.
Bug 1322792 has landed on inbound, which changes configure to require
GCC 4.9 to build; our automation switched over to GCC 4.9 for our
Linux builds earlier this week. (Android builds have been using GCC
4.9 for some time.)
This change paves the way for being able to compile in C++14 mode for
all
On Mon, Aug 22, 2016 at 7:39 PM, R Kent James wrote:
> On 8/21/2016 9:14 PM, Nicholas Nethercote wrote:
>> I strongly encourage people to do likewise on
>> any IDL files with which they are familiar. Adding appropriate checks isn't
>> always easy
>
> Exactly, and I hope that you and others restrai
On Mon, Aug 15, 2016 at 9:56 AM, Henri Sivonen wrote:
> Relatedly, on the topic of MFBT Range and GSL, under the subject "C++
> Core Guidelines" Jim Blandy wrote:
>> One of the main roles of MFBT is to provide polyfills for features
>> standardized in C++ that we can't use yet for toolchain reaso
evealed no obvious mentions of Rust.)
I filed bug 1294083[1] to track/discuss.
Thanks
-Nathan
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1294083
On Wed, Aug 10, 2016 at 10:56 AM, Dave Townsend wrote:
> Does MozillaBuild include the appropriate version of rust?
>
> On Wed, Aug 10, 2016
TL; DR: As the subject says, although the patch is not yet on
mozilla-central. You may want to pre-emptively update your Rust
before the build system requires you to.
We've not been particularly aggressive with requiring new Rust
versions, but with the release of 1.10, we wanted to start compilin
On Mon, Aug 8, 2016 at 6:41 AM, Andreas Tolfsen wrote:
> This is great, but as of pulling central this morning I canāt build
> because configure complains about missing cargo. Iāve filed
> https://bugzilla.mozilla.org/show_bug.cgi?id=1293219 about this.
Thanks for the report, I'll take a look.
TL; DR: Bug 1231764 has landed on mozilla-central; the build system
now invokes cargo to build all the Rust code in m-c. This should
result in a better Rust developer experience, as well as making it
easier to import Rust libraries into m-c.
For gritty details, read on.
If you have new Rust libr
On Mon, Jun 27, 2016 at 2:01 PM, Jet Villegas wrote:
> Shing Lyu from our Taipei Layout team reports a 25% page load improvement
> in Servo from moving to a hashtable lookup from an iterator search of the
> public suffix list ( https://publicsuffix.org/ )
>
> Should Gecko do the same thing and rep
On Fri, May 27, 2016 at 6:34 AM, Kurt Roeckx wrote:
> On 2016-05-27 03:50, Nathan Froyd wrote:
>> Given the standard library's pervasive use of exceptions, and our
>> aversion to the same, if you are using a standard library header
>> that's not listed here:
>
On Thu, May 26, 2016 at 10:08 PM, Mike Hommey wrote:
> On Thu, May 26, 2016 at 09:50:56PM -0400, Nathan Froyd wrote:
>> This change also means that any non-Tier-1 platforms (FxOS, for
>> instance) that don't provide a C++11 standard library will probably
>> break in v
[CC mobile-firefox-dev and dev-fxos for notes below.]
Bug 1246743 (Mac libc++ support) and bug 1273934 (Android libc++
support for local development builds) have landed on mozilla-central.
This change means that all of our Tier-1 platforms now have a
more-or-less conformant C++11 standard library.
On Fri, May 20, 2016 at 11:18 AM, Armen Zambrano G. wrote:
> On 2016-05-19 08:29 PM, Mike Hommey wrote:
>> It's also not possible to *trigger* new TC jobs on treeherder ; like,
>> pushing with no try syntax and filling what you want with "Add new
>> jobs". Or using "Add new job" after realizing yo
On Thu, May 19, 2016 at 1:58 PM, Tobias B. Besemer
wrote:
> Question is:
> If Mozilla will really "Backout MSVC 2015 from aurora" because 2 people are
> not able to configure there PCs right in BIOS ???
> https://bugzilla.mozilla.org/show_bug.cgi?id=1270664
Perhaps those people deliberately disa
libstdc++ has a "debug" mode:
https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
which adds checks for iterator safety and algorithm preconditions.
Bug 1270832, recently landed on inbound, turns this mode on for debug
builds via our wrapped C++ headers. Please file a bug if you find
On Thu, May 5, 2016 at 5:36 PM, wrote:
> Out of interest, what is the situation on Linux? Which C++11 standard library
> will you be using? Will you be shipping your own copy as a shared library, or
> will you be using the system one? If I understand correctly, I assume you
> cannot link agai
On Wed, May 4, 2016 at 1:12 PM, Henri Sivonen wrote:
> Cool! Thank you!
>
> What impact, if anything, does this have on
> https://bugzilla.mozilla.org/show_bug.cgi?id=1208262 (adopting
> Microsoft's Guidelines Support Library or an approximation thereof)?
It gets us closer to a world where the st
On Tue, May 3, 2016 at 10:57 AM, Nathan Froyd wrote:
> As the subject suggests. It is also strongly suggested that you now
> use NDK r11b or above for your local Android development; this is what
> automation uses and what |mach bootstrap| installs.
It's worth pointing ou
As the subject suggests. It is also strongly suggested that you now
use NDK r11b or above for your local Android development; this is what
automation uses and what |mach bootstrap| installs.
This change leaves Mac as our only tier-1 platform without a C++11
standard library.
Given the recent ann
On Fri, Apr 29, 2016 at 7:54 AM, Gerald Squelart wrote:
> Now, for maximum defensiveness, shouldn't we go even further?
>
> How about: Make 'MOZ_MUST_USE' implicit for all functions/methods (except
> void of course, probably methods returning T&, and maybe more as they come
> up).
> When a resul
Bug 1163224 has landed on inbound, which means that Gecko builds with
--enable-rust now support multiple Rust crates. This change is
intended to make the lives of people developing Rust components
easier, and it comes with several caveats:
1) There is zero support for interdependencies between cr
On Wed, Apr 20, 2016 at 8:59 AM, James Graham wrote:
> On 20/04/16 13:53, Josh Matthews wrote:
>> Servo has a script [1] that runs on the build machine that executes
>> --manifest-update and checks whether the contents of MANFEST.json is
>> different before and after. We could do the same for Geck
Re-ping on this thread. It would be really useful to have a decision
one way or the other for figuring out exactly how a C++11 STL on OS X
is going to work.
-Nathan
On Thu, Mar 24, 2016 at 12:51 PM, Ralph Giles wrote:
> Discussion seems to have wound down. Is there a decision on this?
>
> -r
>
On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto wrote:
> On this topic, did anyone experiment with trying to lighten the
> synchronization burden when handling nsEventQueues? Both nsThread and
> nsThreadPool acquire a mutex each time we need to get the next runnable;
> we could pull out all pendi
On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
wrote:
> I've been unhappy with the fact that our event loop uses refcounted objects
> by default. *Most* runnables are pure-C++ and really don't need to be
> refcounted/scriptable.
I've been thinking about this too. gfx has a separate thread po
On Thu, Mar 10, 2016 at 5:25 PM, Mike Hommey wrote:
> On Thu, Mar 10, 2016 at 01:03:43PM -0500, Benjamin Smedberg wrote:
> > This will affect approximately 1.2% of our current release population.
> Here
> > are the specific breakdowns by OS version:
> >
> > 10.6
> > 0.66%
> > 10.7
> >
1 - 100 of 168 matches
Mail list logo
