Well, that's an unsatisfactory answer, completely unsuitable for languages like Rust in which we want to write browsers, kernels, drivers and other low-level things. This is why both Rust and GHC store definitions for inlinable functions.
"A consequence is that GHC must be able to do cross-module, and indeed cross-package, inlining. The idea is simple:
* When compiling a Haskell module Lib.hs, GHC produces object code in Lib.o and an "interface file" in Lib.hi. This interface file contains information about all the functions that Lib exports, including both their types and, for sufficiently small functions, their definitions. * When compiling a module Client.hs that imports Lib, GHC reads the interface Lib.hi. So if Client calls a function Lib.f defined in Lib, GHC can use the information in Lib.hi to inline Lib.f."
- Simon Marlow and Simon Peyton-Jones, http://www.aosabook.org/en/ghc.html
no subject
Date: 2014-09-15 05:16 pm (UTC)"A consequence is that GHC must be able to do cross-module, and indeed cross-package, inlining. The idea is simple:
* When compiling a Haskell module Lib.hs, GHC produces object code in Lib.o and an "interface file" in Lib.hi. This interface file contains information about all the functions that Lib exports, including both their types and, for sufficiently small functions, their definitions.
* When compiling a module Client.hs that imports Lib, GHC reads the interface Lib.hi. So if Client calls a function Lib.f defined in Lib, GHC can use the information in Lib.hi to inline Lib.f."
- Simon Marlow and Simon Peyton-Jones, http://www.aosabook.org/en/ghc.html