and the workaround
playground

evaluation order differs for primitive types
playground
reference

from lib never-say-never
GitHub

more fields ⇒ smaller type (nightly-only)
playground
GitHub issue comment

this code compiles and runs without panicking
thanks to @asokol123 for bringing it
original tweet by @m_ou_se
code on playground
relevant RFC with rationale for this design decision

commented lines do not compile, the rest compiles
thanks to @wafflelapkin for correction!
playground

how syn parses Rust literals (which are already parsed inside of proc_macro)
AFAIK there’s no better way to do it

syn code
internal representation of a Literal
IRLO thread

reversal of control to prevent boxing in object-safe traits
playground

type-erased generic outparams
playground

kinda obvious in retrospect
playground
there’s one deref missing and the whole Box gets coerced to dyn Any

std::mem::uninitialized() initializes memory
playground
core library code

rules for temporary lifetime extension are syntactic, not semantic
playground
about temporary lifetimes

you can just fabricate a vtable in Rust. no one can stop you.

playground

(that’s obviously UB tho)

so, a quick PSA moment

The Rust Foundation (not to be confused with The Rust Project, who actually develop Rust) is currently planning to put up trademark policies that are so restrictive that this channel would be affected. essentially, they want to prohibit usage of the word “Rust” in names of any projects, including non-commercial. (they also banned a bunch of stuff like modifying Rust logo and selling Rust merch).

that’s kinda awful. if you also find this policy kinda awful, please, express your disagreement in the feedback form. as far as I understand, it would be open for a week.

sorry for offtop & pinning, I hope that won’t happen again.

I wrote a longish post about this one since snippet alone doesn’t explain it well
Post: deref specialization in const contexts

useful in macro expansions / codegen
playground
similar trick ICEd on 1.59: Rust issue