Skip to content
← All tracks

Macros, FFI and Type-Driven Design

Rust

`macro_rules!`, the C boundary (libc is already linked, so FFI is problem-rich here), and making the compiler enforce your design instead of your documentation.

This track is written for Rust, which isn't the mode you're browsing in.

0 / 20 solved · 8 articles
Continue →
  1. 1. Why macros exist: code that writes code Read
  2. 2. Not solved yet. Your first macro_rules!: matchers and transcribers
  3. 3. Not solved yet. Fragment specifiers: the complete tour
  4. 4. Not solved yet. expr is atomic, tt is not: the precedence trap
  5. 5. Not solved yet. Repetition: $(...),* and friends
  6. 6. Not solved yet. Nested repetition and zipping metavariables
  7. 7. Not solved yet. Counting repetitions without ${count} (which is still unstable)
  8. 8. Not solved yet. Macro recursion and incremental TT munchers
  9. 9. Not solved yet. Internal rules and push-down accumulation
  10. 10. Not solved yet. Callbacks and TT bundling
  11. 11. Not solved yet. Macro hygiene: why your variable didn't leak
  12. 12. Not solved yet. Follow-set rules: why the compiler rejects your matcher
  13. 13. Debugging macros when expansion goes wrong Read
  14. 14. Not solved yet. Building std's macros: vec!, matches!, a HashMap literal
  15. 15. Not solved yet. A mini DSL: compile-time expression evaluation
  16. 16. The real limits of macro_rules! Read
  17. 17. Procedural macros: the three kinds Read
  18. 18. How #[derive(Debug)] works, and attribute macros demystified Read
  19. 19. Function-like proc macros and proc-macro hygiene Read
  20. 20. Choosing: generics, macro_rules!, or a proc macro Read
  21. 21. What an ABI is, and why FFI exists Read
  22. 22. Not solved yet. Calling C from Rust: libc is already linked
  23. 23. Not solved yet. Edition 2024: unsafe extern blocks and safe declarations
  24. 24. Not solved yet. Edition 2024: #[unsafe(no_mangle)] and calling Rust from C in one file
  25. 25. Not solved yet. C strings, ownership across the boundary, and FFI-safe types
  26. 26. Not solved yet. Nullable pointer optimization, callbacks and qsort
  27. 27. Not solved yet. Opaque pointers, variadics, and the FFI hazard catalogue
  28. 28. Not solved yet. Type-driven design: newtypes, smart constructors, builders, typestate

Check yourself

4 questions · one attempt each

These do not count toward finishing the track. They are here to catch the things that are easy to read past.

0 / 4

Why must a struct passed to C be marked #[repr(C)]? 

#[repr(C)]
struct Point { x: i32, y: i32 }

extern "C" { fn takes(p: Point); }
Question 1 of 4