emberian/this-week-in-rust 556
Data for this-week-in-rust.org
Miscellaneous Collections
Benchmarks of various hashers
eats a gif, spits out fully decoded frames
Test the downstream impact of Rust crate changes before publishing
https://www.meetup.com/Rust-Berlin/events/252872742/
fuck you
A collection of algorithms and tools for geometric problem solving in HTML5
pull request commentrust-lang/rust-forge
Update username/github link of Gankra
I go by she/her, and thanks!
comment created time in 8 days
PR opened mozilla/uniffi-rs
Cargo has a tendency to mishandle \?\ paths on windows. See: https://github.com/rust-lang/cargo/issues/8626
I was having trouble running cargo build on windows to check the generated
code, and this seems to fix the issue?
pr created time in 13 days
push eventGankra/thin-vec
commit sha 483793378800e692b457a6326affbe46fc385f61
whoops for real doc comment
push time in a month
push eventGankra/thin-vec
commit sha f37d565810c2a9a8d74bfe9501258eaaf8656411
fix doc comment
push time in a month
push eventGankra/thin-vec
commit sha 49d64d0477d7d5ff295bab6baa1291ba21e1b2e1
gecko-ffi overhaul * hopefully fixes auto bit handling on big endian platforms * fixes seeming oversight in auto array reallocation * revamps documentation to discuss gecko-ffi feature * updates to rust 2018
commit sha fe87a9d572fd2adac72d6da47c59112734a4defc
Merge pull request #18 from Gankra/big-endian gecko-ffi overhaul
push time in a month
PR merged Gankra/thin-vec
- hopefully fixes auto bit handling on big endian platforms
- fixes seeming oversight in auto array reallocation
- revamps documentation to discuss gecko-ffi feature
- updates to rust 2018
pr closed time in a month
push eventGankra/thin-vec
commit sha 49d64d0477d7d5ff295bab6baa1291ba21e1b2e1
gecko-ffi overhaul * hopefully fixes auto bit handling on big endian platforms * fixes seeming oversight in auto array reallocation * revamps documentation to discuss gecko-ffi feature * updates to rust 2018
push time in a month
push eventGankra/thin-vec
commit sha 1cdeed314d10af5ac6f277746b455816945df362
even better docs/comments
push time in 2 months
pull request commentGankra/thin-vec
Ok, the docs should be more clear now about the issues with relocating.
comment created time in 2 months
push eventGankra/thin-vec
commit sha 6f43dcac4100fb24fc4858af1d425f883968f0e6
even better docs/comments
push time in 2 months
push eventGankra/thin-vec
commit sha 9abf76c60c15d38ecb54f2133861ba96a8acf0c5
refine comments/impl
push time in 2 months
push eventGankra/thin-vec
commit sha 209d47d4b4e9d855a8ac062a32b08ca06d49e0b6
refine comments/impl
push time in 2 months
push eventGankra/thin-vec
commit sha 149f9b34c47b6dc86c86643f1adc3b75c11ca98c
refine comments/impl
push time in 2 months
pull request commentGankra/thin-vec
I've reworked the impl to be a bit more direct. While the mask/shift constants worked, they were starting to feel like an obfuscated rube-goldberg machine. The new implementation is more direct/descriptive.
comment created time in 2 months
push eventGankra/thin-vec
commit sha 34345f8dc35a106ffcd2e48adcc09364074ed3df
refine comments/impl
push time in 2 months
push eventGankra/thin-vec
commit sha ace0c3c7f7cf054d3c91b639280ac40d5bd32b8a
refine comments/impl
push time in 2 months
Pull request review commentGankra/thin-vec
impl<T> ThinVec<T> { (*ptr).set_cap(new_cap); self.ptr = NonNull::new_unchecked(ptr); } else {- self.ptr = header_with_capacity::<T>(new_cap);+ let mut new_header = header_with_capacity::<T>(new_cap);++ // If we get here and have a non-zero len, then we must be handling+ // a gecko auto array, and we have items in a stack buffer. We shouldn't+ // free it, but we should memcopy the contents out of it and mark it as empty.+ //+ // This leans on the assumption that T has a trivial move constructor,+ // which nsTArray already requires. Furthermore, we assume C++ won't try
The ~only types which don't satisfy this property have significant addresses. e.g. they're intrusive (linked list on stack) or registered with a supervisor (swift/objc weak references).
comment created time in 2 months
Pull request review commentGankra/thin-vec
impl<T> ThinVec<T> { (*ptr).set_cap(new_cap); self.ptr = NonNull::new_unchecked(ptr); } else {- self.ptr = header_with_capacity::<T>(new_cap);+ let mut new_header = header_with_capacity::<T>(new_cap);++ // If we get here and have a non-zero len, then we must be handling+ // a gecko auto array, and we have items in a stack buffer. We shouldn't+ // free it, but we should memcopy the contents out of it and mark it as empty.+ //+ // This leans on the assumption that T has a trivial move constructor,+ // which nsTArray already requires. Furthermore, we assume C++ won't try
I specifically mean the situation where move+delete are implemented such that (pseudo cpp):
auto dest = move(src)
delete(src)
can be rewritten to
memcopy(&dest, src)
forget(src)
That is, when you move from src to dest:
- dest becomes a bitwise copy of src (almost always true)
- src becomes a value whose dtor is a no-op (almost always true)
comment created time in 2 months
Pull request review commentGankra/thin-vec
impl<T> ThinVec<T> { (*ptr).set_cap(new_cap); self.ptr = NonNull::new_unchecked(ptr); } else {- self.ptr = header_with_capacity::<T>(new_cap);+ let mut new_header = header_with_capacity::<T>(new_cap);++ // If we get here and have a non-zero len, then we must be handling+ // a gecko auto array, and we have items in a stack buffer. We shouldn't+ // free it, but we should memcopy the contents out of it and mark it as empty.+ //+ // This leans on the assumption that T has a trivial move constructor,+ // which nsTArray already requires. Furthermore, we assume C++ won't try
(There's a good chance "trivial" is the wrong word here, as it's been a while since I've had to discuss ctor properties)
comment created time in 2 months
Pull request review commentGankra/thin-vec
impl Header { #[cfg(feature = "gecko-ffi")] impl Header { fn cap(&self) -> usize {- (self._cap & CAP_MASK) as usize+ ((self._cap & CAP_MASK) >> CAP_SHIFT) as usize } fn set_cap(&mut self, cap: usize) { debug_assert!(cap & (CAP_MASK as usize) == cap); // FIXME: this is busted because it reads uninit memory // debug_assert!(!self.uses_stack_allocated_buffer());- self._cap = assert_size(cap) & CAP_MASK;++ // NOTE: it's fine that we unconditionally mask out the+ // mIsAutoArray bit, because the Rust side will never+ // construct an auto array and set_cap is only invoked+ // by Rust. Auto arrays only happen when a C++-constructed+ // nsTArray bridges into a ThinVec.+ self._cap = (assert_size(cap) << CAP_SHIFT) & CAP_MASK;
Loading vs Storing a packed value requires inverted operations, no? (Also note the shift is a no-op on little-endian, and the mask is unnecessary when the shift isn't a no-op, because left-shift inserts 0's)
comment created time in 2 months
Pull request review commentGankra/thin-vec
impl<T> ThinVec<T> { (*ptr).set_cap(new_cap); self.ptr = NonNull::new_unchecked(ptr); } else {- self.ptr = header_with_capacity::<T>(new_cap);+ let mut new_header = header_with_capacity::<T>(new_cap);++ // If we get here and have a non-zero len, then we must be handling+ // a gecko auto array, and we have items in a stack buffer. We shouldn't+ // free it, but we should memcopy the contents out of it and mark it as empty.+ //+ // This leans on the assumption that T has a trivial move constructor,+ // which nsTArray already requires. Furthermore, we assume C++ won't try
It's certainly required for interop since Rust can't see the move ctors. That said I thought it was also the case that nsTArray required trivial moves, in the sense that you could e.g. realloc the nsTArray buffer?
comment created time in 2 months
pull request commentGankra/thin-vec
This is addressing the following gecko bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1654807
comment created time in 2 months
pull request commentGankra/thin-vec
I need to review the gecko code for auto arrays, my internet cut out while writing this so I just used my intuition/memory for the reallocation code.
comment created time in 2 months
PR opened Gankra/thin-vec
- hopefully fixes auto bit handling on big endian platforms
- fixes seeming oversight in auto array reallocation
- revamps documentation to discuss gecko-ffi feature
- updates to rust 2018
pr created time in 2 months
pull request commentrust-lang/cargo
Mask out system core.autocrlf settings before resetting git repos
yep, wanted another trailing comma
comment created time in 2 months
push eventGankra/cargo
commit sha 4a1e71072d8eee5647054768e092d3a2484d2dae
Mask out system core.autocrlf settings before resetting git repos This fixes an issue the gecko developers noticed when vendoring on windows. [0] If a user has `core.autocrlf=true` set (a reasonable default on windows), vendoring from a git source would cause all the newlines to be rewritten to include carriage returns, creating churn and platform-specific results. To fix this, we simply set the global cargo checkout's "local" core.autocrlf value before performing a `reset`. This masks out the system configuration without interfering with the user's own system/project settings. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1647582
push time in 2 months
pull request commentrust-lang/cargo
Mask out system core.autocrlf settings before resetting git repos
ok, the test now actually sets up a gitconfig, thanks @ehuss!
comment created time in 2 months
push eventGankra/cargo
commit sha d0dd8491d5920cbf68bbcb7e9723ea40412c1247
Mask out system core.autocrlf settings before resetting git repos This fixes an issue the gecko developers noticed when vendoring on windows. [0] If a user has `core.autocrlf=true` set (a reasonable default on windows), vendoring from a git source would cause all the newlines to be rewritten to include carriage returns, creating churn and platform-specific results. To fix this, we simply set the global cargo checkout's "local" core.autocrlf value before performing a `reset`. This masks out the system configuration without interfering with the user's own system/project settings. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1647582
push time in 2 months
Pull request review commentrust-lang/cargo
Mask out system core.autocrlf settings before resetting git repos
fn config_instructions_works() { .with_stderr_contains("[..]foo/vendor/gitdep/src/lib.rs[..]") .run(); }++#[cargo_test]+fn git_crlf_preservation() {+ // Check that newlines don't get changed when you vendor+ // (will only fail if your system is setup with core.autocrlf=true on windows)
Is the mocking sufficiently robust that this won't mess up the user's system?
comment created time in 2 months
pull request commentrust-lang/cargo
Mask out system core.autocrlf settings before resetting git repos
It wasn't clear to me how I could reliably reproduce my test on any machine, but I did make sure it failed without my changes and a system autocrlf=true.
comment created time in 2 months
PR opened rust-lang/cargo
This fixes an issue the gecko developers noticed when vendoring
on windows. 0 If a user has core.autocrlf=true set
(a reasonable default on windows), vendoring from a git source
would cause all the newlines to be rewritten to include carriage
returns, creating churn and platform-specific results.
To fix this, we simply set the global cargo checkout's "local"
core.autocrlf value before performing a reset. This masks out
the system configuration without interfering with the user's
own system/project settings.
pr created time in 2 months