Update emscripten
This updates emscripten to 1.38.15, which is based on LLVM 6.0.1 and would allow us to drop code for handling LLVM 4.
The main issue I ran into is that exporting statics through `EXPORTED_FUNCTIONS` no longer works. As far as I understand exporting non-functions doesn't really make sense under emscripten anyway, so I've modified the symbol export code to not even try.
Closes#52323.
Emscripten only provides an export mechanism for functions.
Exporting statics does not make sense conceptually in this case,
and will result in emcc undefined function errors.
Implement by-value object safety
This PR implements **by-value object safety**, which is part of unsized rvalues #48055. That means, with `#![feature(unsized_locals)]`, you can call a method `fn foo(self, ...)` on trait objects. One aim of this is to enable `Box<FnOnce>` in the near future.
The difficulty here is this: when constructing a vtable for a trait `Foo`, we can't just put the function `<T as Foo>::foo` into the table. If `T` is no larger than `usize`, `self` is usually passed directly. However, as the caller of the vtable doesn't know the concrete `Self` type, we want a variant of `<T as Foo>::foo` where `self` is always passed by reference.
Therefore, when the compiler encounters such a method to be generated as a vtable entry, it produces a newly introduced instance called `InstanceDef::VtableShim(def_id)` (that wraps the original instance). the shim just derefs the receiver and calls the original method. We give different symbol names for the shims by appending `::{{vtable-shim}}` to the symbol path (and also adding vtable-shimness as an ingredient to the symbol hash).
r? @eddyb
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
This commit takes a different approach to add the `crate::` prefix to
item paths than previous commits. Previously, recursion was stopped
after a prelude crate name was pushed to the path. It is theorized that
this was the cause of the linking issues since the same path logic is
used for symbol names and that not recursing meant that details were
being missed that affect symbol names. As of this commit, instead of
ceasing recursion, a flag is passed through to any subsequent recursive
calls so that the same effect can be achieved by checking that flag.
In the 2018 edition, when suggesting traits to import that implement a
given method that is being invoked, suggestions will now include the
`crate::` prefix if the suggested trait is local to the current crate.
This function isn't strictly tied to LLVM (it's more of a utility) and
it's now near an analogous, almost identical `filename_for_input` (for
rlibs and so forth).
Also this means not depending on the backend when one wants to know the
accurate .rmeta output filename.
In investigating [an issue][1] with `panic_implementation` defined in an
executable that's optimized I once again got to rethinking a bit about the
`rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of
been non-stop tweaking these items ever since their inception, and this
continues to the trend.
The crux of the bug was that in the reachability we have a [different branch][2]
for non-library builds which meant that weak lang items (and std internal
symbols) weren't considered reachable, causing them to get eliminiated by
ThinLTO passes. The fix was to basically tweak that branch to consider these
symbols to ensure that they're propagated all the way to the linker.
Along the way I've attempted to erode the distinction between std internal
symbols and weak lang items by having weak lang items automatically configure
fields of `CodegenFnAttrs`. That way most code no longer even considers weak
lang items and they're simply considered normal functions with attributes about
the ABI.
In the end this fixes the final comment of #51342
[1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019
[2]: 35bf1ae257/src/librustc/middle/reachable.rs (L225-L238)
