rustc: Add official support for weak failure #14293

alexcrichton · 2014-05-19T18:11:12Z

This commit is part of the ongoing libstd facade efforts (cc #13851). The
compiler now recognizes some language items as "extern { fn foo(...); }" and
will automatically perform the following actions:

The foreign function has a pre-defined name.
The crate and downstream crates can only be built as rlibs until a crate
defines the lang item itself.
The actual lang item has a pre-defined name.

This is essentially nicer compiler support for the hokey
core-depends-on-std-failure scheme today, but it is implemented the same way.
The details are a little more hidden under the covers.

In addition to failure, this commit promotes the eh_personality and
rust_stack_exhausted functions to official lang items. The compiler can generate
calls to these functions, causing linkage errors if they are left undefined. The
checking for these items is not as precise as it could be. Crates compiling with
-Z no-landing-pads will not need the eh_personality lang item, and crates
compiling with no split stacks won't need the stack exhausted lang item. For
ease, however, these items are checked for presence in all final outputs of the
compiler.

It is quite easy to define dummy versions of the functions necessary:

#[lang = "stack_exhausted"]
extern fn stack_exhausted() { /* ... */ }

#[lang = "eh_personality"]
extern fn eh_personality() { /* ... */ }

cc #11922, rust_stack_exhausted is now a lang item
cc #13851, libcollections is blocked on eh_personality becoming weak

This commit is part of the ongoing libstd facade efforts (cc rust-lang#13851). The compiler now recognizes some language items as "extern { fn foo(...); }" and will automatically perform the following actions: 1. The foreign function has a pre-defined name. 2. The crate and downstream crates can only be built as rlibs until a crate defines the lang item itself. 3. The actual lang item has a pre-defined name. This is essentially nicer compiler support for the hokey core-depends-on-std-failure scheme today, but it is implemented the same way. The details are a little more hidden under the covers. In addition to failure, this commit promotes the eh_personality and rust_stack_exhausted functions to official lang items. The compiler can generate calls to these functions, causing linkage errors if they are left undefined. The checking for these items is not as precise as it could be. Crates compiling with `-Z no-landing-pads` will not need the eh_personality lang item, and crates compiling with no split stacks won't need the stack exhausted lang item. For ease, however, these items are checked for presence in all final outputs of the compiler. It is quite easy to define dummy versions of the functions necessary: #[lang = "stack_exhausted"] extern fn stack_exhausted() { /* ... */ } #[lang = "eh_personality"] extern fn eh_personality() { /* ... */ } cc rust-lang#11922, rust_stack_exhausted is now a lang item cc rust-lang#13851, libcollections is blocked on eh_personality becoming weak

brson · 2014-05-19T22:16:18Z

Why do the lang items themselves need to be extern fns? Is it because the weak symbol is the same as the lang item symbol and the names must be exactly the same? Given the current system, I might prefer that the lang items are allowed to continue being normal rust functions but are inlined into a wrapper with a known symbol name, but if we convert intrinsics to lang items then there will be additional precedent for having extern lang items (I still might like the wrappers though so the lang items don't have to artifically use a specific name).

Finally, if we are going to demand that certain Rust-specific symbols always exist, I would prefer they start with __rust_ to make it absolutely clear these are implementation details.

luqmana · 2014-05-19T23:08:32Z

src/libstd/rt/unwind.rs

@@ -212,7 +212,23 @@ pub mod eabi {
    }

    #[lang="eh_personality"]
+    #[cfg(not(stage0))]
+    extern fn eh_personality(


Should this be extern "C" fn?

The default ABI for an extern fn is not "C", so the string should be optional.

Was "not" a typo?

extern fn foo() {} let _: extern "C" fn() = foo;

compiles fine.

Oh whoops, yes, I mean to say that the default ABI is "C"

This commit is part of the ongoing libstd facade efforts (cc #13851). The compiler now recognizes some language items as "extern { fn foo(...); }" and will automatically perform the following actions: 1. The foreign function has a pre-defined name. 2. The crate and downstream crates can only be built as rlibs until a crate defines the lang item itself. 3. The actual lang item has a pre-defined name. This is essentially nicer compiler support for the hokey core-depends-on-std-failure scheme today, but it is implemented the same way. The details are a little more hidden under the covers. In addition to failure, this commit promotes the eh_personality and rust_stack_exhausted functions to official lang items. The compiler can generate calls to these functions, causing linkage errors if they are left undefined. The checking for these items is not as precise as it could be. Crates compiling with `-Z no-landing-pads` will not need the eh_personality lang item, and crates compiling with no split stacks won't need the stack exhausted lang item. For ease, however, these items are checked for presence in all final outputs of the compiler. It is quite easy to define dummy versions of the functions necessary: #[lang = "stack_exhausted"] extern fn stack_exhausted() { /* ... */ } #[lang = "eh_personality"] extern fn eh_personality() { /* ... */ } cc #11922, rust_stack_exhausted is now a lang item cc #13851, libcollections is blocked on eh_personality becoming weak

bharrisau · 2014-05-22T10:26:45Z

Not sure if I've missed something here, but with this change shared libs are now defining rust_eh_personality ? So if I try to link a binary using two rust shared libs I'll get linker errors for multiple definitions. Is there a work around?

huonw · 2014-05-22T10:50:51Z

Are you hitting that in practice? (If so, file a bug.)

…truct, r=Veykril feat: implement tuple return type to tuple struct assist This PR implements the `convert_tuple_return_type_to_struct` assist, for converting the return type of a function or method from a tuple to a tuple struct. Additionally, it moves the `to_camel_case` and `char_has_case` functions from `case_conv` to `stdx` so that they can be used similar to `to_lower_snake_case`. [tuple_return_type_to_tuple_struct.webm](https://github.com/rust-lang/rust-analyzer/assets/52933714/2803ff58-fde3-4144-9495-7c7c7e139075) Currently, the assist puts the struct definition above the function, or above the nearest `impl` or `trait` if applicable and only rewrites literal tuples that are returned in the body of the function. Additionally, it only attempts to rewrite simple tuple pattern usages with the corresponding tuple struct pattern but does so across files and modules. I think that this is sufficient for the majority of use cases but I could be wrong. One thing I'm still not sure how to approach is handling `Self` and generics/lifetimes in the tuple type to be extracted. I was thinking of either manually figuring out what lifetimes and generics are in scope and using them (sort of similar to the `generate_function` assist) or maybe using `ctx.sema.resolve_type` and `generic_params` on `hir::Type` but this seems to not deal with lifetimes. Closes rust-lang#14293

brson mentioned this pull request May 19, 2014

Make std a facade #13851

Closed

9 tasks

luqmana reviewed May 19, 2014
View reviewed changes

bors closed this May 21, 2014

bors merged commit 6efd166 into rust-lang:master May 21, 2014

alexcrichton deleted the weak-lang-items branch May 21, 2014 16:14

bharrisau mentioned this pull request May 22, 2014

Static libs are doubling up on new lang item definitions #14355

Closed

alexcrichton mentioned this pull request May 31, 2014

Make rust_stack_exhausted a lang item #11922

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

rustc: Add official support for weak failure #14293

rustc: Add official support for weak failure #14293

alexcrichton commented May 19, 2014

brson commented May 19, 2014

luqmana May 19, 2014

alexcrichton May 20, 2014

huonw May 20, 2014

alexcrichton May 20, 2014

bharrisau commented May 22, 2014

huonw commented May 22, 2014

rustc: Add official support for weak failure #14293

rustc: Add official support for weak failure #14293

Conversation

alexcrichton commented May 19, 2014

brson commented May 19, 2014

luqmana May 19, 2014

Choose a reason for hiding this comment

alexcrichton May 20, 2014

Choose a reason for hiding this comment

huonw May 20, 2014

Choose a reason for hiding this comment

alexcrichton May 20, 2014

Choose a reason for hiding this comment

bharrisau commented May 22, 2014

huonw commented May 22, 2014