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 calls to using
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) {
aRv.Throw(NS_ERROR_FAILURE)
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 lat
I mostly use tasks when writing tests, so I mostly have questions about how
it's use in that situation will be affected.
Can we pass async functions everywhere where we use `add_task` in tests
already? If we can't, is there a tracking bug for converting all of the
test systems to support it?
Can y
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 i
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 coul
I don't think it would be too hard. At one point I had a WIP patch which
implemented it, but I would have to dig it up again.
I'll see if I can get a patch up for the crate in my spare time.
On Sun, Mar 26, 2017 at 11:26 PM, Ehsan Akhgari
wrote:
> On 2017-03-17 10:08 AM, Michael
There are patches up for nserror bindings in bug 1320179 (
https://bugzilla.mozilla.org/show_bug.cgi?id=1320179).
If people have API design opinions, you can let me know on the bug.
On Mon, Mar 27, 2017 at 10:22 PM, Ehsan Akhgari
wrote:
> On 2017-03-27 5:10 PM, Michael Layzell wrote:
&g
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 Akhg
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.
>>
>
> Hmm. I wond
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
> you're curious: it
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 output
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.
https://git
, Michael Layzell
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 code. I figured I&#x
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
while I'm not actively
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 PM,
Accidentally sent this off-list.
On Fri, Sep 1, 2017 at 12:14 PM, Michael Layzell
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
> behavior we might want to remove fro
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). The
We could also do something like C++14's `make_unique`, which invokes
the constructor for you. Maybe `mkRefPtr(Arguments, To,
Some, Object, Constructor)`? (That way we wouldn't need the overhead on
each declaration - we could use static analysis to prevent direct
construction if we wanted).
Th
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 f
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 s
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 w
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 a static-analysis annotation, intended to be
placed on RAII guards. It will cause the static analysis to cause
compil
I've updated it with some information about MOZ_RAII.
On Mon, Sep 14, 2015 at 3:02 PM, Aaron Klotz wrote:
> Can you please update
> https://developer.mozilla.org/en-US/docs/Using_RAII_classes_in_Mozilla
> with this information?
>
> Thanks,
>
> Aaron
>
>
> On
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 MO
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 h
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 Tolfsen
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 wrote:
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 in
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
t;
>> 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?
>>>
>>> ~ Gijs
>>>
&g
m I misunderstanding how this works?
> > >
> > > ~ Gijs
> > >
> > >
> > >
> > >> On Mon, Jul 4, 2016 at 4:39 PM, Gijs Kruitbosch <
> gijskruitbo...@gmail.com
> > >> >
> > >> wrote:
> > >>
> >
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. Thanks Nathan!
>
> On Mon, A
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 wouldn't be agains
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 AM, Ted Mielczarek
> wr
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 w
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
enough
lower chance of multiple content process only
differences affecting the program.
On Wed, Jan 18, 2017 at 4:03 PM, Martin Thomson wrote:
> On Thu, Jan 19, 2017 at 9:21 AM, Michael Layzell
> wrote:
> > Security & Privacy Concerns: none
>
> I doubt that this is true. You have
17 at 10:17 AM, Michael Layzell
> wrote:
> > @Martin There is a pref (dom.ipc.processCount.webLargeAllocation -
> default
> > 2) which controls the maximum number of processes which may be allocated
> to
> > Large-Allocation processes. Any requests past that number
>
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 loading window's unit of
rel
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 safe,
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 are
On Fri, Jul 3, 2015 at 8:56 AM, Neil wrote:
> Sure, but that won't stop someone from writing Arg 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.
Restricting certain types t
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() {}};
nsRefPtr bar;
void foo() {
Foo* x = true ? nullptr : bar;
}
`-FunctionDecl 0x103805750 line:943:6 foo 'void
(void)'
`-CompoundStmt
x = true ? nullptr : bar;
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 str
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 t
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 ta
47 matches
Mail list logo
