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

it’s possible to work around the “bounds with different associated types are not considered disjoint” limitation by using a helper trait

thanks to Marin Veršić, author of the disjoint_impls crate for publishing this trick!

playground
rust-lang/rust issue

oh, and also I published this one trick as a crate: https://github.com/GoldsteinE/dyngo

implicit use of a trait we’re currently implementing leaks through a module
bonus points to anyone who finds any related documentation (please tell me in the comments if you do!)
playground
thanks to @kanashimia for showing me this

(also yay 200 subscribers!)

you can access the return type of a macro by unifying it with some variable
playground

postmono const expression conditions
note that you’d also need to do a similar check for alignment, which is omitted for brevity
UPD: as @arjentix pointed out, this will also only work in cargo build/cargo test; the check will be skipped in cargo check
playground

a bit late to the party, but couldn’t pass this one
method resolution depends on compiler’s mutable internal state, which you can observe by calling a method on an integer literal
playground
Rust issue (two Zulip threads linked inside)
CI failures for naive fix

it compiles.
playground