In this #InfoQ article, Vitaly Bragilevsky shares findings and insights about the Rust community and ecosystem, and discusses the peculiarities and pitfalls of starting new projects in #Rustlang or migrating from other languages.
The theme is going to be announced at the submission opening - you can use it, but it's optional since the jam only wants to get people to write games in Rust.
I was (and still am) looking into various Rust build integration issues over the last weeks, specifically when integrating Rust code into existing C code bases.
Today I ran into one that is very easy to fix, and that e.g. shaves off half of the shared library size from librsvg.
Distros might want to do this explicitly in their builds for now.
Make sure to always pass --gc-sections (or equivalent) to the linker when linking a Rust staticlib into an executable or shared library. And in case of the latter, also make sure to only exports the symbols you want to export (librsvg did that part correctly).
Apparently this was also not mentioned anywhere in the Rust docs, and from looking around there seem to be more projects that are not aware of this. So I also added a section about this to the Rust docs (well, reference).
I've spent a good part of my weekend working on upgrading the GStreamer Rust bindings on Servo. The presentation by Martin Robinson from @igalia at @rustnl was a real inspiration.
I just published my first Rust :rust: crate: https://crates.io/crates/presage. I don't think anyone beside me will ever use it but I still felt very nervous 😬.
In the new Rust Windows kernel GDI code, there is a new global allocator registered named gdi_alloc::Win32Allocator . It calls Win32AllocPool with a fun new pool tag name, "Rust"!
For the specific GDI objects, there are still allocations made with the existing GDI-specific pool tags.
It looks like the rgncore::scan::ScanBuilder<gdi_alloc::TaggedAllocator<_>> object uses the existing GDI pool tag Gscn ( i.e. GDITAG_SCAN_ARRAY) for vector allocations. (Probably gdi_alloc::TaggedAllocator<_> requires specifying a pool tag)
I also see Gedg (i.e. GDITAG_EDGE) being used in gdi_rust::region::from_path::GlobalEdgeTable::add_edge, and gdi_rust::region::from_path::ActiveEdgeTable::new
, among other places.
The Rust code in the new win32kbase_rs.sys in the Windows Kernel can also panic. What happens when it does?
There are several places where a panic is invoked in the code - they include bounds check failures (core::panicking::panic_bounds_check), indexing into a slice outside of the length of that slice (core::slice::index::slice_start_index_len_fail_rt), and assertion failures (core::panicking::assert_failed). These all eventually take a common code path through the following series of function calls:
This calls into a custom panic handler, seh_unwind::implementation::raise_exception, which calls RtlRaiseException, imported from the main ntoskrnl binary!
Maybe I need to unlearn some old OOP habits when working with #rustlang but ... for the following code:
trait Bonus { ... }
trait A { ... }
trait B { ... }
impl<T: A> Bonus for T { ... }
impl<T: B> Bonus for T { ... }
I get the following Rust compiler error:
conflicting implementations of trait filters::Bonus [E0119]
Shouldn't I get this error only when I attempt to implement both traits A and B for some type T? As long as they're mutually exclusive, I am not sure I get why the compiler is complaining. How would you go about it?
@daridrea Hmmm ... The intent of the code I shared is to say: if you implement either trait A or B, you get the Bonus trait for free. They're blanket implementations, much like the Into implementation which you get for free once you implement the From trait.
In my opinion, as long as there is no instance in the code where one type implements both A and B (directly or indirectly), then there should be no problem. But it seems the compiler is preemptively blocking this probably because it cannot prove the two traits are indeed mutually exclusive (but I don't get why it cannot prove that).
Something is still not clicking for me regarding some of the semantics of the language, but I am slowly getting there 🙂
@daridrea indeed, I made things a bit more explicit by using wrapper structures and implementing the traits for those wrappers instead of implementing them for a generic type. This works for me now, albeit with a bit more verbosity. Thanks for your replies!
I don't get why the default for #rustlang is 4-space tabs. It's a pretty verbose language, so you'd think you want the extra horizontal room, no? I'm glad I can easily change it with rustfmt.toml though!
@ambihelical@AstraKernel@edward and as I said, all tab using projects I've seen everywhere, including the Linux kernel, end up with messy space and tab mixes