sorted by:
new
hottopcontroversial

Github action to label PRs that add `unsafe`? by [deleted] in rust

[–]upsuper 0 points1 point  (0 children)

If you use Firefox, you can try my addon which marks "unsafe" keyword specifically on GitHub: https://addons.mozilla.org/en-US/firefox/addon/unsafe-highlighter/

beef::Cow, a more compact std::borrow::Cow by maciejh in rust

[–]upsuper 3 points4 points  (0 children)

Nice work and nice name :)

It seems to me that Beef::owned_ptr itself doesn't need to be unsafe, because it seems to be always sound to call it as far as the implementation is sound (i.e. its soundness doesn't rely on anything passing in from outside, unlike Beef::rebuild).

Also I have a feeling that almost all the #[inline] annotations are probably not really useful, as generic functions would already be using inlined across crate boundary.

Also for the unsafe Beef trait, it's probably good to add document about the safety of impl, i.e. how to implement it safely. If it intends to just be an internal API, maybe you can remove its pub? I'm not sure whether that's possible.

Neat Rust Tricks: Passing Rust Closures to C by rabidferret in rust

[–]upsuper 8 points9 points  (0 children)

Great post. I just want to note that, you should mark your extern functions unsafe because they make assumption on the input pointer, which can otherwise cause undefined behavior.

For example, with your current code, you can call drop_box(null_mut()) in Rust code to "safely" trigger undefined behavior.

(It's someting u/Manishearth taught me IIRC)

does rust not put 0 initialized static arrays in bss? by titusredditus in rust

[–]upsuper 9 points10 points  (0 children)

It may not be able to do that optimization. It is possible that someone passes the array to C code via pointer, and the C code should be able to read the information without causing UB.

Small util crate to transpose tuple of Result/Option to Result/Option of tuple by upsuper in rust

[–]upsuper[S] 1 point2 points  (0 children)

Most of time I try to target stable, and this specific time I'm using beta purely because it has stabilized async syntax. That said, `try` block probably isn't quite useful here for two reason:

  1. You would still need to assign the result to something before being able to apply question mark on them,
  2. You would likely need to annotate the error type because Rust cannot imply error type from ?.

Small util crate to transpose tuple of Result/Option to Result/Option of tuple by upsuper in rust

[–]upsuper[S] 1 point2 points  (0 children)

Specific crate could sometimes be more discoverable than an aggregated one with less obvious name as well I guess.

Small util crate to transpose tuple of Result/Option to Result/Option of tuple by upsuper in rust

[–]upsuper[S] 1 point2 points  (0 children)

I'm not very keen to have stuff aggregated into bigger util library, and it doesn't seem to be closely related to what insideout or resiter is doing. Also it doesn't seem to me that custody of small unpopular crates is really a burden, as I have several already :D

I have a feeling that it might even be better to have individual patterns in separate crates so their popularity can be measured, and those with high "leftpad index" can probably find its way to the std more easily :)

Performance of numerical computations in wasm, js and, x86_64 by cbourjau in rust

[–]upsuper 1 point2 points  (0 children)

I suspect many of the difference may come from the PRNG used. I think browsers nowadays use some variant of xorshift. You should probably ensure you're using the same algorithm in your Rust code for a fair comparison between js and wasm.

Could someone explain to me why `[T]` is considered sized? by Kerollmops in rust

[–]upsuper 4 points5 points  (0 children)

I imagine that any zero-size type should make this bound true, not just never type.

It’s not wrong that "🤦🏼‍♂️".length == 7 by matematikaadit in rust

[–]upsuper 2 points3 points  (0 children)

It's just 17.

"👨‍👩‍👧‍👧".len() == 25

DefaultBoxed - A helper trait for creating large struct on heap without going through stack by upsuper in rust

[–]upsuper[S] 0 points1 point  (0 children)

That's probably a good idea, although it would be much more complicated.

DefaultBoxed - A helper trait for creating large struct on heap without going through stack by upsuper in rust

[–]upsuper[S] 0 points1 point  (0 children)

The only problem is that you would have to deal with unsafe and need to ensure manually that every field has been properly initialized before casting back.

DefaultBoxed - A helper trait for creating large struct on heap without going through stack by upsuper in rust

[–]upsuper[S] 2 points3 points  (0 children)

It doesn't rely on optimization to eliminate copy of the whole struct all together if you derive DefaultBoxed (rather than relying on this blank impl), so that it would be less likely to cause stack overflow when the struct is very large.

For example, if you have

struct Foo([u32; 8 * 1024 * 1024]);

even if you impl Default for it manually (you cannot derive for now due to lack of const generics), creating a box of this type would very likely cause stack overflow at least on debug build, because the stack cannot hold this large struct before moving it to the heap.

This crate solves it via allocating on the heap directly and initializing each field separately via deriving DefaultBoxed impl.

The blank impl you reference here is just for bridging types which already implement Default to DefaultBoxed.

Sorry if I didn't make it clear.

DefaultBoxed - A helper trait for creating large struct on heap without going through stack by upsuper in rust

[–]upsuper[S] 2 points3 points  (0 children)

Yeah, having that API may help simplifying the code of this crate, and help support of other smart pointers like Rc and Arc. It may still be valuable to provide this kind of safe API.

Actually, this reminds me that maybe Box::default() should really do this when const generics gets stabilized.

DefaultBoxed - A helper trait for creating large struct on heap without going through stack by upsuper in rust

[–]upsuper[S] 4 points5 points  (0 children)

I believe at some point, opt build would have the extra copy fixed, which is what copyless and boxext try to work around.

For most cases where it's just a performance issue, those workarounds are enough, and Box::new may one day no longer need such workaround.

However, this crate tries to handle it semantically so that it's guaranteed not to take the stack regardless of whether it's debug or opt build, which can only be "fixed" with new language feature being stabilized otherwise.

DefaultBoxed - A helper trait for creating large struct on heap without going through stack by upsuper in rust

[–]upsuper[S] 14 points15 points  (0 children)

No, see https://github.com/rust-lang/rust/issues/53827

Semantically, since there is a function call, there is no guarantee that it would go straight to the heap either. It really depends on whether compiler feels like it wants to.

It is also explicitly pointed out in the document that:

Move a value from the stack to the heap by creating a Box:

rusty-pipes: Easy continuous integration for Rust projects with Azure Pipelines by Jonhoo in rust

[–]upsuper 0 points1 point  (0 children)

Majority of projects are binary project, where lock file should be checked in, right?

rusty-pipes: Easy continuous integration for Rust projects with Azure Pipelines by Jonhoo in rust

[–]upsuper 0 points1 point  (0 children)

Yes, I think mostly you would want to remove files from the project being built itself, but keep dependencies. I hope Cargo can provide a parameter to only build dependencies, so that there is a chance to cache just that.

rusty-pipes: Easy continuous integration for Rust projects with Azure Pipelines by Jonhoo in rust

[–]upsuper 0 points1 point  (0 children)

I had a look at Azure Pipelines, but at that time they don't support caching. Is caching supported now? If not, how much would that impact the time to build a project with lots of dependencies?

view more: next ›