rust/src/test/run-pass/invoke-external-foreign.rs

// xfail-fast
// aux-build:foreign_lib.rs

// The purpose of this test is to check that we can
// successfully (and safely) invoke external, cdecl
// functions from outside the crate.

extern mod foreign_lib;

fn main() {
    let foo = foreign_lib::rustrt::last_os_error();
}
core: Clean up comments and exports 2012-03-10 02:04:09 -06:00			`// xfail-fast`
Change 'native' and 'crust' to 'extern'. This comes with a terminology change. All linkage-symbols are 'extern' now, including rust syms in other crates. Some extern ABIs are merely "foreign". The term "native" is retired, not clear/useful. What was "crust" is now "extern" applied to a _definition_. This is a bit of an overloading, but should be unambiguous: it means that the definition should be made available to some non-rust ABI. 2012-06-26 18:18:37 -05:00			`// aux-build:foreign_lib.rs`
work around bug when calling c-stack-cdecl fns from outside crate In the main test, I call the wrapper instead of the native fn, as intended. I also added an xfail-test that exercises the broken code path. Will file a bug. Description of the broken code path: The code path is that when we look up the external identifier we go through trans_external_path() -> type_of_ty_param_kinds_and_ty() -> type_of_fn_from_ty() -> type_of_fn(), and type_of_fn() adds a lot of external parameters. Problem is, I guess, that we don't pass the native ABI (or even the fact that it's a native function!), just the types and kinds of the parameters. 2011-10-21 14:14:01 -05:00
			`// The purpose of this test is to check that we can`
Add "cdecl" as synonym for "c-stack-cdecl" 2011-11-09 18:04:07 -06:00			`// successfully (and safely) invoke external, cdecl`
work around bug when calling c-stack-cdecl fns from outside crate In the main test, I call the wrapper instead of the native fn, as intended. I also added an xfail-test that exercises the broken code path. Will file a bug. Description of the broken code path: The code path is that when we look up the external identifier we go through trans_external_path() -> type_of_ty_param_kinds_and_ty() -> type_of_fn_from_ty() -> type_of_fn(), and type_of_fn() adds a lot of external parameters. Problem is, I guess, that we don't pass the native ABI (or even the fact that it's a native function!), just the types and kinds of the parameters. 2011-10-21 14:14:01 -05:00			`// functions from outside the crate.`

Convert 'use' to 'extern mod'. Remove old 'use' syntax 2012-09-11 19:46:20 -05:00			`extern mod foreign_lib;`
core: Clean up comments and exports 2012-03-10 02:04:09 -06:00
work around bug when calling c-stack-cdecl fns from outside crate In the main test, I call the wrapper instead of the native fn, as intended. I also added an xfail-test that exercises the broken code path. Will file a bug. Description of the broken code path: The code path is that when we look up the external identifier we go through trans_external_path() -> type_of_ty_param_kinds_and_ty() -> type_of_fn_from_ty() -> type_of_fn(), and type_of_fn() adds a lot of external parameters. Problem is, I guess, that we don't pass the native ABI (or even the fact that it's a native function!), just the types and kinds of the parameters. 2011-10-21 14:14:01 -05:00			`fn main() {`
Change 'native' and 'crust' to 'extern'. This comes with a terminology change. All linkage-symbols are 'extern' now, including rust syms in other crates. Some extern ABIs are merely "foreign". The term "native" is retired, not clear/useful. What was "crust" is now "extern" applied to a _definition_. This is a bit of an overloading, but should be unambiguous: it means that the definition should be made available to some non-rust ABI. 2012-06-26 18:18:37 -05:00			`let foo = foreign_lib::rustrt::last_os_error();`
re-enable tests for #1058 and #1059 2011-11-18 18:29:01 -06:00			`}`