We just landed some new checks [0] for `mach vendor rust` that should make
it behave reliably on Windows. If you were unaware, the command had a
tendency to produce different results on Windows, up to and including
deleting random files!
The issues were upstream cargo bugs that have all been fixed
Just chiming in here with some brief extra context on the performance of
Result (which I really need to do a writeup about so that I can just link
it):
TL;DR performance of Result is usually fine, but can randomly be a huge
problem. However there's also improvements for this on the (distant)
horiz
Is dogfoodability at all platform-specific for fission? i.e. is windows the
only platform that is really actively developed/maintained? (as would make
sense at this stage)
More concretely, I was under the impression that fission had webrender as a
dependency, is that mandatory? Is it actually enfo
With webrender we've had pretty good results from always defaulting to
MOZ_RELEASE_ASSERT, as users are often mildly decent at producing an STR.
But perhaps we're luckier in that everyone dogfooding webrender was more
willing to figure things out than a nightly user?
On Mon, Sep 17, 2018 at 3:31 P
On Thu, Jul 12, 2018 at 11:03 PM, Robert O'Callahan
wrote:
> On Fri, Jul 13, 2018 at 11:40 AM, Steve Fink wrote:
>
> > On 07/12/2018 04:27 PM, Cameron McCormack wrote:
> >
> >> On Fri, Jul 13, 2018, at 6:51 AM, Kris Maglione wrote:
> >>
> >>> I actually have a patch sitting around with helpers t
x27;incremental = falseoverflow-checks = false
On Tue, Mar 13, 2018 at 9:24 AM, Alexis Beingessner wrote:
> The defaults of the various cargo profiles are documented here:
> https://doc.rust-lang.org/cargo/reference/manifest.html
>
> The relevant entry is:
>
> # The benchmarking pr
The defaults of the various cargo profiles are documented here:
https://doc.rust-lang.org/cargo/reference/manifest.html
The relevant entry is:
# The benchmarking profile, used for `cargo bench` and `cargo test
--release`.[profile.bench]opt-level = 3debug = falserpath = falselto =
falsedebug-asser
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 t
I'm currently trying to improve the C++ <-> Rust FFI story a bit. I just
posted a draft proposal to add a mode to rustc that has it output the ABI
details of all public types:
https://internals.rust-lang.org/t/stabilizing-a-machine-readable-zprint-type-sizes/5525
This would theoretically reduce ou
9 matches
Mail list logo
