Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread Kris Maglione
On Tue, Aug 01, 2017 at 05:16:54PM -0700, Jim Blandy wrote: I have to ask: does anyone recall the benchmarks that showed that bounds checks or vector reallocations were a measurable performance hit in this code? If we don't, we should just write simple, obviously correct code. If we do, there

Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread Jim Blandy
I have to ask: does anyone recall the benchmarks that showed that bounds checks or vector reallocations were a measurable performance hit in this code? If we don't, we should just write simple, obviously correct code. If we do, there should be a comment to that effect, or something to convey to

Re: Extensions and Gecko specific APIs

2017-08-01 Thread mconca
On Monday, July 31, 2017 at 11:09:03 PM UTC-6, Andrew Swan wrote: > For further discussion about the longer term strategy, I would suggest > following up with Kev Needham who oversees all of addons. Also, Mike Conca > just started as the product manager for WebExtensions. But to be fair to >

Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread Kris Maglione
On Tue, Aug 01, 2017 at 01:28:37PM -0700, Eric Rahm wrote: Both AppendElements and SetLength default initialize the values, there's no intermediate uninitialzed state. SetCapacity doesn't initialize the values, but they're also not indexable -- we have release bounds assertions -- unless you try

Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread Eric Rahm
Both AppendElements and SetLength default initialize the values, there's no intermediate uninitialzed state. SetCapacity doesn't initialize the values, but they're also not indexable -- we have release bounds assertions -- unless you try really hard. nsTArray doesn't support emplace although it

Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread Kris Maglione
On Tue, Aug 01, 2017 at 12:57:31PM -0700, Eric Rahm wrote: nsTArray has various Append methods, in this case just using the infallible AppendElements w/o out a SetCapacity call would do the job. Another option would be to use SetLength which would default initialize the new elements. If we're

Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread Eric Rahm
nsTArray has various Append methods, in this case just using the infallible AppendElements w/o out a SetCapacity call would do the job. Another option would be to use SetLength which would default initialize the new elements. If we're trying to make things fast-but-safeish in this case, the

Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread Kris Maglione
On Tue, Aug 01, 2017 at 12:31:24PM -0400, 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 = *sockets.AppendElement(fallible);

Re: New minimum Rust version policy for Firefox

2017-08-01 Thread Bobby Holley
This is great - thanks Ralph! On Tue, Aug 1, 2017 at 11:53 AM, Ralph Giles wrote: > We've formalized a new plan for when we update the minimum-required Rust > version for building Firefox. Starting later this week we'll require the > latest stable Rust two weeks after it is

New minimum Rust version policy for Firefox

2017-08-01 Thread Ralph Giles
We've formalized a new plan for when we update the minimum-required Rust version for building Firefox. Starting later this week we'll require the latest stable Rust two weeks after it is released. This means we'll start requiring Rust 1.19.0 August 3rd. If you compile mozilla-central and haven't

Re: Actually-Infallible Fallible Allocations

2017-08-01 Thread David Major
I don't think that anyone deliberately set out to write the code this way. Likely this is fallout from the mass-refactorings in bug 968520 and related bugs. I'd recommend working with poiru and froydnj to see if there's any automated follow-up we could do to remove/improve this pattern. On Tue,

Actually-Infallible Fallible Allocations

2017-08-01 Thread Alexis Beingessner
TL;DR: we're using fallible allocations without checking the result in cases where we're certain there is enough space already reserved. This is confusing and potentially dangerous for refactoring. Should we stop doing this? - I was recently searching through our codebase to look at all

Photon Engineering Newsletter #10

2017-08-01 Thread Justin Dolske
(via https://dolske.wordpress.com/2017/08/01/photon-engineering-newsletter-10/ ) Woo yeah! Time for Photon newsletter #10 ! Nightly-57 this week Way back in newsletter #2