[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

froydnj added a comment. In D81865#2293146 , @MaskRay wrote: > In D81865#2293066 , @dblaikie wrote: > >> In D81865#2293059 , @MaskRay wrote: >> >>> @froydnj The committed ver

[clang] 31a3c5f - [clang] use string tables for static diagnostic descriptions

Author: Nathan Froyd Date: 2020-09-24T10:54:28-04:00 New Revision: 31a3c5fb45b78bdaa78d94ffcc9258e839002016 URL: https://github.com/llvm/llvm-project/commit/31a3c5fb45b78bdaa78d94ffcc9258e839002016 DIFF: https://github.com/llvm/llvm-project/commit/31a3c5fb45b78bdaa78d94ffcc9258e839002016.diff

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

This revision was automatically updated to reflect the committed changes. Closed by commit rG31a3c5fb45b7: [clang] use string tables for static diagnostic descriptions (authored by froydnj). Changed prior to commit: https://reviews.llvm.org/D81865?vs=288628&id=294063#toc Repository: rG LLVM

Nika Layzell for XPCOM owner; Simon Giesecke for XPCOM peer

Two important changes to the XPCOM module: Nika Layzell has graciously volunteered to become the XPCOM module owner. Simon Giesecke has agreed to become an XPCOM peer (and even seemed somewhat excited by the possibility =D). If you have XPCOM-related reviews, it's best to use the xpcom-reviewers

stepping down from maintenance roles

Due to my impending departure from Mozilla, I will no longer have the time to serve in a maintenance role for the various modules I am involved in. I am therefore stepping down from those roles. It's been an honor to serve you all. Thanks, -Nathan ___

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

froydnj requested review of this revision. froydnj added a comment. Throwing this back into the review queue. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81865/new/ https://reviews.llvm.org/D81865 ___ cfe-commits mailing list cfe-commits@li

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

froydnj updated this revision to Diff 288628. froydnj added a comment. Updated to use a struct instead of a union for the actual table in an effort to avoid UB. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81865/new/ https://reviews.llvm.org/D81865 Files: clang/lib/Basic/Diagnostic

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

froydnj added a comment. Ping for an opinion on the recent discussion of how to move forward with this patch. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81865/new/ https://reviews.llvm.org/D81865 ___

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

froydnj added a comment. Ping for an opinion on the recent discussion of how to move forward with this patch. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81865/new/ https://reviews.llvm.org/D81865 ___

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

froydnj added a comment. In D81865#2176589 , @dblaikie wrote: > I believe this falls under the (using cppreference ( > https://en.cppreference.com/w/cpp/language/union ) , since it's a bit easier > to read) UB clause: " It's undefined behavior to read fr

[PATCH] D81865: [clang] Use string tables for static diagnostic descriptions

froydnj added a comment. In D81865#2176014 , @bkramer wrote: > Nice, those relocations have annoyed me for years. I'm worried about whether > the way you're accessing StaticDiagInfoDescriptionStringTable might be > undefined behavior. I won't block this

[PATCH] D81865: use string tables for static diagnostic descriptions

froydnj added a comment. Ping. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81865/new/ https://reviews.llvm.org/D81865 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cg

[PATCH] D82388: move "basic" builtins to TableGen

froydnj added a comment. FWIW, an in-progress tree for the proposed move for all the architecture-specific builtins is: https://github.com/froydnj/llvm-project/tree/move-builtins-to-tablegen I don't know if the ARM/NEON/SVE builtins will be easily movable. It looks like they are separately ge

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

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

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 m

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: > > https://youtu.be/rHIkrotSwcc?t=10

Re: Issues cross compiling NSS for arm undefined reference to pthread_atfork

On Thu, Sep 5, 2019 at 8:56 AM Hamish MB wrote: > The build gets a fair way, but eventually fails with: > > Linux2.6_arm_glibc_PTH_DBG.OBJ/pkcs11.o: In function `nsc_CommonInitialize': > /home/wmt/Downloads/nss-3.25.1/nss/lib/softoken/pkcs11.c:3022: undefined > reference to `pthread_atfork' > coll

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 become

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 become

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

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): > > https://botondballo.wordpress.com/2019/07/26/trip-report-c-standards-meeting-in-cologne-july-

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

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 so

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

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

Re: Windows build dependency on 8.3 short names

On Mon, Jul 1, 2019 at 11:00 PM Paul Schauble wrote: > The issue of 8.3 file name is too complex to explain in an error message. I > think the error message should be something like: > ... > I will write the article if requested. We welcome improvements to our documentation and our error message

Re: Crash Reporting module added

h I've added > to simplify reviews. Currently I'm the module owner and sole peer but > I'd like to ask Nathan Froyd to join me as a peer. Nathan has already > handled a large number of reviews and contributed important chang

Re: Proposal: Move node from 8.11 to 10.15 and npm to 6.4

Apparently upgrading Node is the thing du jour, because Mark was just emailing dev-builds about a more conservative upgrade (to Node 8.12) several weeks ago. :) AFAIK, the primary limitation is what sort of Node version support our Linux distributions have. You can see this information for key s

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 ma

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 so

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 en

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 l

[PATCH] D57838: [clang-cl] support /Oy- on aarch64

froydnj added a comment. Thanks for the review, @mstorsjo. Would you please land this for me? I don't have commit access. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D57838/new/ https://reviews.llvm.org/D57838 __

[PATCH] D57838: [clang-cl] support /Oy- on aarch64

froydnj created this revision. froydnj added a reviewer: mstorsjo. Herald added subscribers: cfe-commits, kristof.beyls, javed.absar. Herald added a project: clang. MSVC supports /Oy- on aarch64, so clang-cl should too. Repository: rC Clang https://reviews.llvm.org/D57838 Files: lib/Driver

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 Cas

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_ --enable-pgo

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

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, stop-the-pr

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: Help needed: building with -finstrument-functions

On Sun, Nov 11, 2018 at 1:25 AM Victor Porof wrote: > 1. Built this simple trace.cpp: > https://gist.github.com/victorporof/e9809e33c4dc67ef388672791c4c80cd > - Used `clang++ trace.cpp -mmacosx-version-min=10.9 -c -o trace.o` > - I’m building this without `-finstrument-functions`, obviously. > >

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 versio

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 use

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 a

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 needed. > > Would p

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, 2018 at 6:18 AM, Jonatha

Re: incremental compilation for opt Rust builds

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

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: [dev-servo] Standalone NDK concerns?

FWIW, the Android team is planning on making standalone toolchains obsolete in the relatively near future (the roadmap says later this year): https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md#make-standalone-toolchains-obsolete -Nathan On Tue, Mar 6, 2018 at 7:46 PM, Josh Bo

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 separate file as I orig

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 out with a weird error w

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 >> treatment. First of all we'd have a list

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 think it's more > important to m

Re: [PATCH][PR c++/82888] smarter code for default initialization of scalar arrays

On Fri, Nov 17, 2017 at 8:50 AM, Jason Merrill wrote: > On Thu, Nov 16, 2017 at 11:21 AM, Nathan Froyd wrote: >> diff --git a/gcc/cp/init.c b/gcc/cp/init.c >> index c76460d..53d6133 100644 >> --- a/gcc/cp/init.c >> +++ b/gcc/cp/init.c >> @@ -4038,6 +4038,15 @

[PATCH][PR c++/82888] smarter code for default initialization of scalar arrays

Default-initialization of scalar arrays in C++ member initialization lists produced rather slow code, laboriously setting each element of the array to zero. It would be much faster to block-initialize the array, and that's what this patch does. The patch works for me, but I'm not sure if it's the

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

Re: Fennec now builds with clang instead of gcc

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

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

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

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" footnote at https://help.ubun

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 Coop

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 Coop

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 foo; > } Can you provide

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 >> Along with the tracking issue: https://

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 that

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 &mSocket = *sockets.AppendElement(fall

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 counting is a garbage collect

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

Re: Announcing MozillaBuild 3.0 Release

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

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 big problem ? > > At least

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 less sure of how some of

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

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 still really confus

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 > cases where regul

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) > require rust-encoding. H

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 > other built-in apis. Of

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 but of course chang

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

Re: Linux builds now default to -O2 instead of -Os

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

upcoming requirements changes for Stylo builds + request for help

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

Re: Improving visibility of compiler warnings

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

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

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

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 tests--including but

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

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

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 always heard, Gecko-wise

Re: Representing a pointer to static in XPConnected JS?

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

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 what amount to dummy A

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 i

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 before we link libxul.

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

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 https://doc.rust-lang.org/std/env/fn.var.

[dev-servo] build-time bindgen support for Stylo has landed on mozilla-inbound

Bug 1302028, build-time bindgen support for Stylo, has landed. Bindgen support is automatically enabled for --enable-stylo builds (including stylo-incubator integration builds); use --disable-stylo-build-bindgen if you need to disable it for any reason. The bindgen support assumes that you have a

  1   2   3   4   5   6   7   >