Re: Revisiting modelines in source files

On 2015-06-17 1:04 PM, Andrew McCreight wrote: As Boris said, for our particular emacs modeline there is no prompt. Actually, in some JS files I'm getting a prompt when opening them - js-indent-level isn't considered a safe variable by emacs. (although it's pretty easy to mark them as

Fwd: mozilla::TemporaryRef is gone; please use already_AddRefed

With regard to what #2 is doing, I threw the following into a file with nsRefPtr, and got clang to dump the AST: struct Foo {void AddRef() {} void Release() {}}; nsRefPtrFoo bar; void foo() { Foo* x = true ? nullptr : bar; } `-FunctionDecl 0x103805750 line:943:1, line:945:1 line:943:6 foo

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

On Fri, Jul 3, 2015 at 8:56 AM, Neil n...@parkwaycc.co.uk wrote: Sure, but that won't stop someone from writing ArgFoo foo = ReturnFoo2(); will it? Something like that is fairly trivial for a static analysis system like our clang plugin to catch, if we want to create a type like that.

Re: Fwd: mozilla::TemporaryRef is gone; please use already_AddRefed

; would look like Foo* x = (true ? nullptr : bar).get(); which is much more obviously inefficient. On 2015-07-06 8:49 AM, Neil wrote: Michael Layzell wrote: In summary, the nsRefPtr is copied into a temporary in its side of the conditional. The nullptr is cast to a struct Foo*, which

Re: Intent to migrate the permissions database to use origins instead of host names

The patches I am working on already use Bobby Holley's OriginAttributes, in fact we use the origin attribute on the nsIPrincipal, and only expose an nsIPrincipal from the API. Internally, we use the origin attribute for serialization, but to external consumers of the API, all that is available

Re: MozPromises are now in XPCOM

We have a static analysis for this right now: https://dxr.mozilla.org/mozilla-central/source/build/clang-plugin/tests/TestNoRefcountedInsideLambdas.cpp And there is potential for more static analyses if we decide that we need them. We also have bug 1157788 if we decide at some point that we

Intent to Implement: Selection Events

Summary: We currently require webpages to poll the current selection when they want to be notified of changes to the user's selection.This patch adds two events, selectstart and selectionchange, which allow the website to detect when the selection is changed. selectstart is fired when the user

Intent to Ship: Updated third-party iframe storage behavior

Summary: Currently, there are inconsistent rules about the availability of persistent storage in third-party iframes across different types of storage (such as caches, IndexedDB, localstorage, sessionstorage, and cookies). We are looking to unify these behaviors into a consistent set of rules

Re: Now measuring Firefox size per-commit. What else should we be tracking?

I'd love it if we could get better stats for build times. Not only is it handy for making sure they don't grow out of control, but we can also use it to make sure that our static analysis doesn't add an unacceptable level of overhead on compilation. On Wed, Nov 4, 2015 at 12:10 PM, Andreas

MOZ_CRASH-invoked crashes are now annotated

Bugs 1183355 and 1209958 have now landed on inbound, which means that crashes caused by MOZ_CRASH in release builds will now be annotated, and the annotation reasons should be visible on crash-stats. Currently the crash will be annotated with any string literals passed to the MOZ_CRASH macro, so

Re: C++ feature proposal: specialize conversions for type of usage (local, member, parameter, etc.)

This would probably be implemented for us with the static analysis, and an attribute MOZ_PARAMETER_ONLY_RESULT. I don't know how hard that would be to implement, but it looks a lot like the work I'm doing in https://bugzilla.mozilla.org/show_bug.cgi?id=1191540, so I imagine that once I figure out

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

We're already working on a static analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1180993 which will prevent code like that from passing try. Hopefully that will help with your concerns. On 2015-07-07 12:59 PM, Seth Fowler wrote: I brought this up on IRC, but I think this is worth

Re: mozilla::TemporaryRef is gone; please use already_AddRefed

On 2015-07-07 6:37 AM, Aryeh Gregor wrote: Did you check whether this actually occurs in an optimized build? C++ allows temporaries to be optimized away under some circumstances, e.g., when returning a local variable. It would make a lot of sense to me if it allowed the temporary created by a

Re: MOZ_RAII has landed on inbound

ron > > > On 9/12/2015 3:06 PM, Michael Layzell wrote: > >> Hey everyone, >> >> Bug 1201190 (https://bugzilla.mozilla.org/show_bug.cgi?id=1201190) just >> landed on inbound, which means that we now have access to the new >> annotation MOZ_RAII. This is

Re: Return-value-optimization when return type is RefPtr

We pass T* as an argument to a function too often for this to e practical. The best solution is probably to remove the conversion from RefPtr&& to T* which is I believe what froydnj is planning to do. This requires ref qualifiers for methods, which isn't supported in MSVC 2013, but is supported

Re: Static analysis for "use-after-move"?

I have already written a basic analysis for use-after-move semantics which just hasn't been reviewed yet. I'm not sure if it's what you'd be looking for (take a look at the tests). https://bugzilla.mozilla.org/show_bug.cgi?id=1186706 Michael On Fri, Apr 29, 2016 at 12:14 AM, Jim Blandy

Re: Faster gecko builds with IceCC on Mac and Linux

h <gijskruitbo...@gmail.com >> > >> wrote: >> >> What about people not lucky enough to (regularly) work in an office, >>> including but not limited to our large number of volunteers? Do we intend >>> to set up something public for people to use? >>>

Re: Faster gecko builds with IceCC on Mac and Linux

isunderstanding how this works? > > > > > > ~ Gijs > > > > > > > > > > > >> On Mon, Jul 4, 2016 at 4:39 PM, Gijs Kruitbosch < > gijskruitbo...@gmail.com > > >> > > > >> wrote: > > >> > > >

Faster gecko builds with IceCC on Mac and Linux

If you saw the platform lightning talk by Jeff and Ehsan in London, you will know that in the Toronto office, we have set up a distributed compiler called `icecc`, which allows us to perform a clobber build of mozilla-central in around 3:45. After some work, we have managed to get it so that macOS

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

Thanks a ton for your work on this! This makes working on rust code in gecko much easier, and makes importing libraries from the ecosystem simpler as well (if a tad tedious). On Mon, Aug 8, 2016 at 1:21 PM, Bobby Holley wrote: > +1. This is an important step forward.

Re: Intent to Implement and Ship: Large-Allocation Header

chance of multiple content process only differences affecting the program. On Wed, Jan 18, 2017 at 4:03 PM, Martin Thomson <m...@mozilla.com> wrote: > On Thu, Jan 19, 2017 at 9:21 AM, Michael Layzell > <mich...@thelayzells.com> wrote: > > Security & Privac

Intent to Implement and Ship: Large-Allocation Header

Summary: Games implemented on the web platform using WASM or asm.js use large contiguous blocks of allocated memory as their backing store for game memory. For complex games, these allocations can be quite large, sometimes as large as 1GB. In 64-bit builds, we have no problem finding a large

Re: Intent to Implement and Ship: Large-Allocation Header

t; On Thu, Jan 19, 2017 at 10:17 AM, Michael Layzell > <mich...@thelayzells.com> wrote: > > @Martin There is a pref (dom.ipc.processCount.webLargeAllocation - > default > > 2) which controls the maximum number of processes which may be allocated > to > > Lar

Re: A reminder about MOZ_MUST_USE and [must_use]

It wouldn't be too hard to automatically generate Result wrapper methods automatically for all of our XPIDL interfaces. I had a prototype branch at one point which did this on the rust side, as part of my now-dead rust XPIDL bindings. That would convert a good number of our fallable

Re: Intent to Implement and Ship: Large-Allocation Header

On Thu, Jan 19, 2017 at 3:58 AM, wrote: > Hey, > > a bunch of questions: > > how will you handle synchronous scripting between that process and other > frames from the same origin that aren't in that dedicated process? > If there are other toplevel windows within the

Re: New [must_use] property in XPIDL

We already have mozilla::Unused in mfbt/Unused.h. You can use it as `mozilla::unused << SomethingReturningAValue();`. I believe that the existing static analyses which look at unused variables respect this. On Tue, Aug 23, 2016 at 9:47 AM, Eric Rescorla wrote: > Fair enough. I

Re: Converting assertions into release assertions

We already have implemented that static analysis but haven't enabled it yet, because static analysis doesn't run on windows machines: https://bugzilla.mozilla.org/show_bug.cgi?id=1223932 On Fri, Sep 23, 2016 at 12:51 PM, Bobby Holley wrote: > On Fri, Sep 23, 2016 at 9:30

Re: Error handling with MOZ_MUST_USE

We also have a static analysis attribute MOZ_MUST_USE_TYPE which can be added to class declarations to ensure that those declarations are always used when they are returned. We currently are using it to annotate already_AddRefed values. If there are other types which universally should be checked

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

-17 10:08 AM, Michael Layzell wrote: > > I don't think we have any particularity good tools for this right now. A > > while ago I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1320179 > to > > add a separate crate like the nsstring crate which provides the nsresult > >

Re: Third Party Library Alert Service

I also want this information programmatically for the clang plugin at some point. It will be useful for many of the checks which we can't enforce on third party code due to not being able to / wanting to modify them directly. Right now we have a decent number of check-specific whitelists which

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

I don't think we have any particularity good tools for this right now. A while ago I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1320179 to add a separate crate like the nsstring crate which provides the nsresult bindings. If we are starting to get more use cases for it we probably want to

Re: Proper way to return nsresult from Rust before Stylo is mandatory?

On Sun, Mar 26, 2017 at 11:26 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com > > <mailto:ehsan.akhg...@gmail.com>> wrote: > > > > On 2017-03-17 10:08 AM, Michael Layzell wrote: > > > I don't think we have any particularity good tools for this right >

Re: Is there a way to improve partial compilation times?

I'm pretty sure that by the time we're reaching that number of cores we'll be blocked on preprocessing, as preprocessing occurs on the local machine (where the header files are), and on network I/O. I imagine that peak efficiency is well below 2k machines. In addition, there's some unavoidable

New ErrorResult::Throw Static Analysis

Bug 1331434 is on inbound, and it adds a new static analysis and an attribute called MOZ_MUST_RETURN_FROM_CALLER. This attribute is currently attached to ErrorResult::Throw. This analysis is intended to help catch buggy code which performs logic like: if (!foo) {

Re: Intent to ship:

This also seems like a feature which some users may want to disable, for example in order to reduce bandwidth usage on certain websites (I'm not sure how bad the impact would be bug *shrug*). I imagine we should add a pref if possible before shipping this feature. On Mon, Jul 31, 2017 at 1:25

Re: More Rust code

On Mon, Jul 10, 2017 at 9:41 AM, smaug wrote: > ipdl? or do you mean idl? or perhaps webidl? > Also, xpconnect doesn't deal with rust, and our chrome code still heavily > relies on idl+xpconnect. > I have written https://bugzilla.mozilla.org/show_bug.cgi?id=1293362, which

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

On Tue, May 9, 2017 at 12:05 PM, Boris Zbarsky wrote: > On 5/9/17 11:41 AM, Nathan Froyd wrote: > >> I think I would feel a little >> better about this rule if we permitted it only for types that deleted >> assignment operators. Not sure if that's really practical to enforce.

Re: Improving visibility of compiler warnings

I don't have enough time to work on a proper solution, but I wrote a simple rust wrapper which just consumes stderr from the wrapped process, and doesn't write it out unless the internal command exited with a non-zero exit code. I figured I'd post it in case anyone else finds it useful.

Re: Improving visibility of compiler warnings

, Michael Layzell <mich...@thelayzells.com> wrote: > I don't have enough time to work on a proper solution, but I wrote a > simple rust wrapper which just consumes stderr from the wrapped process, > and doesn't write it out unless the internal command exited with a non-zero > exit c

Re: Gecko Profiler Win64 stability

You've done a fantastic job of making it more stable - thank you. I'll make sure to flag you on any more synchronization issues I run into. On Thu, May 18, 2017 at 3:04 PM, David Major wrote: > Hi, > > The Gecko Profiler used to be notoriously unstable on 64-bit Windows. (If

Re: Improving visibility of compiler warnings

With regard to ALLOW_COMPILER_WARNINGS, I'm strongly of the opinion that we should be providing an option to hide all warnings from modules marked as ALLOW_COMPILER_WARNINGS now, as they are only in "external" libraries which most of us are not working on, and they really clog up my compiler

Re: Mixing nsresult and Result code

I also don't like the NS_TRY name, it seems too close to MOZ_TRY. I would prefer to avoid names which are identical except s/NS/MOZ/. Perhaps NSRESULT_TRY would be a better name? It makes it clear that it is performing the try against the nsresult type. On Mon, May 8, 2017 at 10:17 AM, Ehsan

BHR Project Status

In the last few months we've been putting work into making the data which we collect from the Background Hang Reporter (BHR) more usable and actionable. We use BHR to measure the frequency and cause of browser hangs (when the main thread's event loop doesn't process events for 128ms or longer).

Re: Eiminating nsIDOM* interfaces and brand checks

Accidentally sent this off-list. On Fri, Sep 1, 2017 at 12:14 PM, Michael Layzell <mich...@thelayzells.com> wrote: > I personally like the style of (2) the most, The isWhatever style methods > are too verbose, and I don't think that adding more code which depends on > behavio