Per conversation with :kmoir, I'm going through untriaged bugs in her components and marking the ones which look to be enhancements/tasks with the enhancement severity to get them out of the triage queue.

If this incorrect, please remove the tag.

Eric asked me to write up the list of changes I had to make in order for things to compile with cross-lang LTO. For a local build on Windows the following .mozconfig works for me:

# Use the right compilers and linker:
export CC="clang-cl.exe"
export CXX="clang-cl.exe"
export LINKER="lld-link.exe"

# Enable cross-lang LTO
export RUSTFLAGS=-Clinker-plugin-lto

# Do a release build with ThinLTO enabled
ac_add_options --enable-release
ac_add_options --enable-lto=thin
ac_add_options --host=x86_64-pc-mingw32
ac_add_options --target=x86_64-pc-mingw32

# geckodriver seems to use `link.exe` regardless of the `LINKER` variable above.
# (--enable-linker does not seem to work on Windows?)
ac_add_options --disable-geckodriver

For testing I used clang 8.0 (~rc2?) from mach bootstrap and rustc 1.34.0-nightly (00aae71f5 2019-02-25).

geckodriver seems to be the only problem for local builds.

For things to work on CI, I also had to disable the clang plugin, as shown here:
https://hg.mozilla.org/try/rev/c57d3a67cb1d
I don't know if that is still necessary. It probably was also related to code being compiled with LTO but then linked with a linker that doesn't support it.

# geckodriver seems to use `link.exe` regardless of the `LINKER` variable
above.

glandium: cross-language LTO builds fail in geckodriver because they use link.exe which doesn't understand the bitcode format. I believe you pointed me to bug 1524396 in a different context the other day. Do you think that bug will fix the geckodriver LTO issue too?

It shouldn't matter because it feels like we shouldn't be LTO'ing geckodriver in the first place.

(In reply to Mike Hommey [:glandium] from comment #8)

It shouldn't matter because it feels like we shouldn't be LTO'ing
geckodriver in the first place.

That means we'll have to do something more complicated than a global export RUSTFLAGS=-Clinker-plugin-lto. (Which means I'm probably not the right person to write the patch.)

(In reply to David Major [:dmajor] from comment #9)

(In reply to Mike Hommey [:glandium] from comment #8)

It shouldn't matter because it feels like we shouldn't be LTO'ing
geckodriver in the first place.

That means we'll have to do something more complicated than a global export RUSTFLAGS=-Clinker-plugin-lto. (Which means I'm probably not the right person to write the patch.)

I think all this means is that you need to override RUSTFLAGS for force-cargo-library-{build,check} to include -Clinker-plugin-lto when appropriate. So you need to massage this code:

https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#129-133

to keep what's already there for not-libraries, and and the appropriate flags for libraries.

After talking things over with glandium it sounds like the linker issue has been handled in bug 1524396. We might want to a file a follow up to not LTO geckodriver (and others), but that's not a blocker. We need bug 1538060 for non-Windows builds (that should be landing shortly), but even without that we should be unblocked on Windows. There's a possibility that lib.exe issues might get in the way (bug 1537643) but it's probably worth resuming work on Windows to see if that's an issue or not.

On Win64 builds that are already doing LTO (in practice, this means shippable builds), make the LTO be cross-language.

https://hg.mozilla.org/mozilla-central/rev/5851c65af0e0