Re: Some changes to how errors are thrown from Web IDL methods

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

mozilla-central is now on C++17

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++

Re: Proposal: Replace NS_ASSERTION with MOZ_ASSERT and then remove it.

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

Re: Passing UniquePtr by value is more expensive than by rref

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: > >

Nika Layzell and Kris Maglione are now XPCOM peers

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

[C++] Intent to eliminate: `using namespace std;` at global scope

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

Re: Upcoming C++ standards meeting in Cologne

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): > >

Re: cross-language LTO enabled on nightly for all platforms

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

cross-language LTO enabled on nightly for all platforms

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

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

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.

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

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:

crash reporting, inline functions, and you

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

Re: Duplicate dependency policy for Rust in mozilla-central?

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

Re: PSA: Min clang / libclang requirement was updated not long ago...

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

Re: PSA: Min clang / libclang requirement was updated not long ago...

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

Re: Moving reviews to Phabricator

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

Re: XPCOM Tidying Proposal

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

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

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_

arm64 windows nightlies now available

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

Re: Disabling IPC protocol with build flags?

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:

Re: Dropping support for compiling with MSVC in the near future

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,

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

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

Re: Signals in Firefox

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

Re: Rust version required to build Firefox ESR versions

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

Re: Rust version required to build Firefox ESR versions

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

JS builds now depend on Rust

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

Re: C++ standards proposal for a embedding library

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

Re: Coding style: Making the `e` prefix for enum variants not mandatory?

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

Re: Rust crate approval

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

Re: Coding style: brace initialization syntax

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

Re: redundant(?) code churn and code style issues in bug 525063

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,

Re: incremental compilation for opt Rust builds

On Tue, Mar 13, 2018 at 3:10 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > On Tue, Mar 13, 2018 at 2:56 AM, Nathan Froyd <nfr...@mozilla.com> wrote: >> (Our release builds use -O2 for Rust code.) > > What does cargo bench use by default? > (https://internals.rus

incremental compilation for opt Rust builds

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

Re: Revised proposal to refactor the observer service

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

Re: Refactoring proposal for the observer service

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

Re: Refactoring proposal for the observer service

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 >>

Re: Hiding 'new' statements - Good or Evil?

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

mozilla-central now compiles with C++14

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

Re: Fennec now builds with clang instead of gcc

On Sun, Oct 29, 2017 at 7:37 PM, Kris Maglione <kmagli...@mozilla.com> 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 turni

Fennec now builds with clang instead of gcc

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.

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

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"

Re: Experimenting with a shared review queue for Core::Build Config

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

Re: C++ function that the optimizer won't eliminate

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

Re: Re: Firefox and clang-cl

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

how to make your local --enable-optimize builds compile Rust faster

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

Re: Actually-Infallible Fallible Allocations

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 =

Re: refcounting [WAS: More Rust code]

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

new locking primitive: RecursiveMutex

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

Re: Announcing MozillaBuild 3.0 Release

On Mon, Jul 24, 2017 at 6:21 PM, Enrico Weigelt, metux IT consult <enrico.weig...@gr13.net> 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

Re: Announcing MozillaBuild 3.0 Release

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

Re: `mach cargo check` now available

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

`mach cargo check` now available

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

Re: Profiling nightlies on Mac - what tools are used?

On Tue, Jun 20, 2017 at 12:19 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> 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

Re: Profiling nightlies on Mac - what tools are used?

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

Re: Shipping Headless Firefox on Linux

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

Re: New character encoding conversion API

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) >

Re: Changing .idl files

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 >

Re: Changing .idl files

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

--disable-optimize --enable-debug builds added to infra

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.

Re: new configure option: --enable-debug-rust

On Thu, May 11, 2017 at 5:15 PM, Jeff Muizelaar <jmuizel...@mozilla.com> wrote: > On Fri, Apr 14, 2017 at 10:46 AM, Nathan Froyd <nfr...@mozilla.com> wrote: >> With these options, you get a browser that runs quickly (i.e. no DEBUG >> assertions in C++ code), but still l

Re: Running mochitest on packaged builds with the sandbox

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

Re: Using references vs. pointers in C++ code

On Tue, May 9, 2017 at 10:39 AM, Boris Zbarsky <bzbar...@mit.edu> 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 in

Re: Using references vs. pointers in C++ code

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

Re: Representing a pointer to static in XPConnected JS?

On Thu, May 4, 2017 at 12:32 PM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > On Thu, May 4, 2017 at 4:27 PM, Nathan Froyd <nfr...@mozilla.com> wrote: >> On Thu, May 4, 2017 at 3:08 AM, Henri Sivonen <hsivo...@hsivonen.fi> wrote: >>> Is it feasible (with reaso

Re: Representing a pointer to static in XPConnected JS?

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

new configure option: --enable-debug-rust

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

Re: windows build anti-virus exclusion list?

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

Re: Tracking bug for removals after XPCOM extensions are no more?

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

Re: Should cheddar-generated headers be checked in?

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

Re: GCC 4.9 now required to build on Linux/Android

On Fri, Dec 23, 2016 at 6:39 PM, <gsquel...@mozilla.com> 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 > prope

tier-2 Windows clang-cl static analysis builds running on inbound

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

Re: GCC 4.9 now required to build on Linux/Android

On Fri, Dec 23, 2016 at 11:37 AM, Mike Hoye <mh...@mozilla.com> 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 >> Lin

GCC 4.9 now required to build on Linux/Android

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

Re: New [must_use] property in XPIDL

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

Re: snake_case C++ in m-c (was: Re: C++ Core Guidelines)

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

Re: Rust 1.10 (to be) required to build Firefox with --enable-rust

On Wed, Aug 10, 2016 at 6:18 AM, Nathan Froyd <nfr...@mozilla.com> wrote: >> >> 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. >> >>

Rust 1.10 (to be) required to build Firefox with --enable-rust

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

Re: Rust code in mozilla-central now builds via cargo

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,

Re: [dev-servo] 25% Improvement in page load time!

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

Re: C++11 standard library support enabled on all Tier-1 platforms

On Fri, May 27, 2016 at 6:34 AM, Kurt Roeckx <k...@roeckx.be> 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 liste

Re: C++11 standard library support enabled on all Tier-1 platforms

On Thu, May 26, 2016 at 10:08 PM, Mike Hommey <m...@glandium.org> 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 &

C++11 standard library support enabled on all Tier-1 platforms

[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

Re: Tier-1 for Linux 64 Debug builds in TaskCluster on March 14 (and more!)

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

Re: What is "Process Type = content" in "mozilla crash reports"?

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

libstdc++ debug mode enabled in debug builds

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

Re: libc++ enabled for Android / C++11 standard library update

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

Re: libc++ enabled for Android / C++11 standard library update

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

Re: libc++ enabled for Android / C++11 standard library update

On Tue, May 3, 2016 at 10:57 AM, Nathan Froyd <nfr...@mozilla.com> 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 wor

libc++ enabled for Android / C++11 standard library update

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

Re: MOZ_WARN_UNUSED_RESULT has been renamed as MOZ_MUST_USE

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

multiple Rust crates are now supported

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

Re: Please use "web-platform-tests --manifest-update" for updating wpt tests

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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

Re: Removing the Chromium event loop

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

Re: Removing the Chromium event loop

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

Re: Intent to deprecate: MacOS 10.6-10.8 support

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 > >

nsAutoArrayPtr has been removed, please use UniquePtr<T[]> instead

As the subject says, via bug 1229985. Please also be advised that nsAutoPtr will suffer a similar fate in the not-too-distant future, so writing new code with UniquePtr will make your code better and the removal not take any longer than it needs to. Thanks, -Nathan

Re: Gecko/Firefox stats and diagrams wanted

On Tue, Feb 9, 2016 at 12:31 PM, Nicholas Alexander <nalexan...@mozilla.com> wrote: > I also wanted to try to find some diagrams to show how Firefox and Gecko >> work/their architecture, from a high level perspective (not too insane a >> level of detail, but reasonable)

Re: Use of C++11 std::unique_ptr for the WOFF2 module

On Mon, Feb 1, 2016 at 4:29 AM, Frédéric Wang wrote: > I tried updating the source code of WOFF2 to the latest upstream > version. Unfortunately, try server builds fail on OSX and mobile devices > because the C++11 class std::unique_ptr does not seem to be available. > IIUC

Re: Moving FirefoxOS into Tier 3 support

On Mon, Jan 25, 2016 at 12:30 PM, Ehsan Akhgari wrote: > For example, for a long time b2g partners held back our minimum supported > gcc. Now that there are no such partner requirements, perhaps we can > consider bumping up the minimum to gcc 4.8? (bug 1175546) > > I'm

  1   2   >