Assist writing/using crates that should not have any code inlined into dependent crates

[steveklabnik]

Issue by huonw
Friday Aug 01, 2014 at 03:50 GMT

For earlier discussion, see rust-lang/rust#16159

This issue was labelled with: A-an-interesting-project, A-lint in the Rust repository

---

AIUI, a license like the LGPL can be linked into a non-(L)GPL program only if it can be completely substituted for a replacement by the user (i.e. dynamically linked, with no inlined code/constants etc.). This means a LGPL Rust crate can only be used in non-(L)GPL programs if no code is inlined or otherwise codegened from it (e.g. generics).

We could have lint(s) that makes writing and using such libraries easier by warning/marking items that require codegen in the user crate (e.g. generics) and those that recommend copying data/code from one crate into another (e.g. non-#[inline(never)] statics, #[inline] functions). Note that the latter doesn't require inlining, and so doesn't necessarily have to be included in the first lint.

This could even include a #[no_inlining] extern crate some_lgpl_crate; attribute, that doesn't read crate metadata (making the compiler ignore #[inline] attributes and the AST metadata in that crate, and disallowing instantiating generic functions).

#![warn(items_requiring_crosscrate_inlining)]
#![warn(public_inlinable_items)]

static FOO: uint = 10; // warning: statics can be inlined by default, consider adding #[inline(never)]

pub fn foo<T>(...) { // warning: generic functions require inlining
   // ...
}

#[inline] // warning: inline attribute on public item
pub fn bar(...) {
    // ...
}

#[no_inlining]
extern crate foo;

fn main() {
    foo::bar::<int>() // error: instantiating generic function from crate `foo`, which is marked no_inlining

    // not inlined, just called as a non-#[inline] function would be
    foo::some_inlinable_function();
}