Support using LLVM's libunwind as the unwinder implementation

[petrhosek]

This avoids the dependency on host libraries such as libgcc_s which
may be undesirable in some deployment environments where these aren't
available.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[rust-highfive]

⚠️Warning⚠️

• These commits modify submodules.

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:2060500d:start=1552287844715727058,finish=1552287846353950989,duration=1638223931
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:00:00] Submodule 'src/doc/embedded-book' (https://github.com/rust-embedded/book.git) registered for path 'src/doc/embedded-book'
[00:00:00] Submodule 'src/doc/nomicon' (https://github.com/rust-lang-nursery/nomicon.git) registered for path 'src/doc/nomicon'
[00:00:00] Submodule 'src/doc/reference' (https://github.com/rust-lang-nursery/reference.git) registered for path 'src/doc/reference'
[00:00:00] Submodule 'src/doc/rustc-guide' (https://github.com/rust-lang/rustc-guide.git) registered for path 'src/doc/rustc-guide'
[00:00:00] Submodule 'src/libunwind/libunwind' (https://git.llvm.org/git/libunwind.git) registered for path 'src/libunwind/libunwind'
[00:00:00] Submodule 'src/tools/cargo' (https://github.com/rust-lang/cargo.git) registered for path 'src/tools/cargo'
[00:00:00] Submodule 'src/tools/clippy' (https://github.com/rust-lang-nursery/rust-clippy.git) registered for path 'src/tools/clippy'
[00:00:00] Submodule 'src/tools/miri' (https://github.com/rust-lang/miri.git) registered for path 'src/tools/miri'
[00:00:00] Submodule 'src/tools/rls' (https://github.com/rust-lang-nursery/rls.git) registered for path 'src/tools/rls'
---
[00:03:59] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/docs/conf.py:251: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:111: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:122: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:124: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:125: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:127: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:131: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:236: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:237: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:240: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:243: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:245: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:246: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:247: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:254: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:256: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:258: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:259: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:261: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:265: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:310: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:312: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:314: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:318: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:323: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:340: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:341: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:342: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:343: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:347: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:348: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:352: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:375: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:376: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:379: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:382: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:383: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:387: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:390: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:391: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:405: trailing whitespace
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:427: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/include/mach-o/compact_unwind_encoding.h:428: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/config.h:69: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:479: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:481: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:483: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:492: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:494: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-seh.cpp:496: line longer than 100 chars
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:79: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:116: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:120: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:129: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/src/Unwind-EHABI.cpp:712: TODO is deprecated; use FIXME
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/test/libunwind/test/__init__.py: empty file
[00:03:59] tidy error: /checkout/src/libunwind/libunwind/test/libunwind/__init__.py: empty file
[00:04:01] some tidy checks failed
[00:04:01] [00:04:01] [00:04:01] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:01] [00:04:01] [00:04:01] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:01] Build completed unsuccessfully in 0:00:43
[00:04:01] Build completed unsuccessfully in 0:00:43
[00:04:01] make: *** [tidy] Error 1
[00:04:01] Makefile:68: recipe for target 'tidy' failed
The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1c4c1b0a
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
Mon Mar 11 07:08:19 UTC 2019
---
travis_time:end:0cde8db0:start=1552288100375095301,finish=1552288100380276874,duration=5181573
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0564bd60
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:00f918c3
travis_time:start:00f918c3
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:018f50bb
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[fbstj]

shouldn't this be the libunwind from the LLVM monorepo?

[IsaacWoods]

Especially since we already have a llvm-project submodule with a copy of libunwind in tree, that would be better imo

[petrhosek]

I'm fine switching to llvm-project, but that version is behind upstream and is missing some important changes to libunwind that removed the C++ standard library dependency. We need to roll it first.

[cramertj]

r? @alexcrichton

[cramertj]

Looks like the travis failures are coming from tidy errors in src/libunwind/libunwind. I believe that directory will have to be added to this list.

[alexcrichton]

Thanks for this @petrhosek! I had no idea it was so easy to pull this in :)

To get an idea, are y'all thinking of turning this on by default for Fuchsia? Additionally, do you know if there are other targets which may wish to turn this on by default? Turning this on by default seems like a tantalizing proposition at this point, but we probably can't take a dependency on a C++ compiler just yet and we'd also want to give this some time to bake.

In terms of llvm-project and such, when you say upstream to you mean rust-lang's fork of the llvm-project repo? If that's all that's necessary to update I think we'll want to go ahead and pull the necessary patches into our fork and then use the src/llvm-project directory. If it's a case of LLVM's own monorepo vs the sub-repos they have then this seems like a fine temporary holdover.

I'm also somewhat surprised that there's no source level changes here, even for platforms like MSVC. This seems to have build logic for MSVC/Linux/macOS, but I was wondering if you'd tested it there as well? MSVC for example I thought we only used kernel32.dll things rather than a linked in unwinder.

[petrhosek]

Thanks for this @petrhosek! I had no idea it was so easy to pull this in :)

To get an idea, are y'all thinking of turning this on by default for Fuchsia? Additionally, do you know if there are other targets which may wish to turn this on by default?

Yes, we plan to enable this for our Rust toolchain build. This is currently a blocker for deployment in our internal Linux environment since we don't have libgcc_s available there, but we would also like to use it for Fuchsia.

Turning this on by default seems like a tantalizing proposition at this point, but we probably can't take a dependency on a C++ compiler just yet and we'd also want to give this some time to bake.

To clarify, this requires only C++ compiler, not C++ standard library (once we bring in the libuwind changes).

In terms of llvm-project and such, when you say upstream to you mean rust-lang's fork of the llvm-project repo? If that's all that's necessary to update I think we'll want to go ahead and pull the necessary patches into our fork and then use the src/llvm-project directory. If it's a case of LLVM's own monorepo vs the sub-repos they have then this seems like a fine temporary holdover.

Yes, that's what I had in mind. I'd be fine using rust-lang's fork if we can cherry-pick the necessary patches (assuming that's easier than rolling the entire repository forward):

llvm/llvm-project@7fac517
llvm/llvm-project@90bcfaa

I'm also somewhat surprised that there's no source level changes here, even for platforms like MSVC. This seems to have build logic for MSVC/Linux/macOS, but I was wondering if you'd tested it there as well? MSVC for example I thought we only used kernel32.dll things rather than a linked in unwinder.

I haven't tested the change on those platforms yet. It might be safer to restrict this only for Linux and Fuchsia. I'd expect macOS to be safe as well since libunwind is already being used there as the default unwinder. I'm less familiar with the status on Windows.

[mati865]

I'm less familiar with the status on Windows.

AFAIK Dwarf unwinding doesn't work yet so it cannot be used for i686-pc-windows-gnu (SJIJ works but Dwarf is faster), SEH used by x86_64-pc-windows-gnu is in a good shape.
This commit would need backporting for it to build:
llvm/llvm-project@6ccad0a#diff-2467f5cba1ecc34d53f4480cd654aa55

[alexcrichton]

@petrhosek ok cool, that all sounds great!

In that case how about:

• Let's cherry-pick changes to our llvm-project fork. If necessary though we can fast-forward, but that's normally a pretty big hassle.
• For now this'll be left turned off, but the config changes here look perfect for threading it through.
• I'd personally prefer to leave only the supported platforms in for now, letting new support be added explicitly and tested as it's added (so probably leaving out the Windows/MSVC/Darwin support for now).

How's that sound?

(and just to confirm, LLVM's libunwind has the same API as the libgcc_s one we expect, so that's why there's no source-level changes necessary on Linux?)

[petrhosek]

@petrhosek ok cool, that all sounds great!

In that case how about:

• Let's cherry-pick changes to our llvm-project fork. If necessary though we can fast-forward, but that's normally a pretty big hassle.

How do you do that? Do I need to send those changes as pull requests to your llvm-project fork or can you or someone else just cherry pick them directly?

• For now this'll be left turned off, but the config changes here look perfect for threading it through.
• I'd personally prefer to leave only the supported platforms in for now, letting new support be added explicitly and tested as it's added (so probably leaving out the Windows/MSVC/Darwin support for now).

How's that sound?

SGTM

(and just to confirm, LLVM's libunwind has the same API as the libgcc_s one we expect, so that's why there's no source-level changes necessary on Linux?)

Yes, it's designed to be a drop-in replacement. We're using LLVM's libunwind in our C/C++ toolchain for both Linux and Fuchsia without any problems.

[alexcrichton]

Oh sorry yeah, a cherry-pick would be doing the cherry-pick locally and then sending a PR to https://github.com/rust-lang/llvm-project/tree/rustc/8.0-2019-01-16. I can merge that and then afterwards the submodule can be updated here

[bors]

☔ The latest upstream changes (presumably #59226) made this pull request unmergeable. Please resolve the merge conflicts.

[alexcrichton]

@petrhosek when rebasing this can you also update the llvm-project submodule to rust-lang/llvm-project@8f80418? I was testing out an experimental change in #58854 on a separate branch, and that PR merged, so I've merged my temporary branch into the master branch of rust-lang/llvm-project which should have both your changes and my changes

[alexcrichton]

Ah actually in parallel as well we have another submodule update which includes the changes needed for this PR as well as the ones I mentioned previously (JFYI)

[mati865]

Ping @petrhosek, this PR requires rebase. LLVM submodule has been updated by another PR so it's no longer necessary.

[bors]

☔ The latest upstream changes (presumably #59464) made this pull request unmergeable. Please resolve the merge conflicts.

[petrhosek]

Ping? Would it be possible to take a look again?

[rust-highfive]

The job x86_64-gnu-llvm-6.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

travis_time:end:09c31340:start=1554230093841327556,finish=1554230096317889139,duration=2476561583
$ git checkout -qf FETCH_HEAD
travis_fold:end:git.checkout
Encrypted environment variables have been removed for security reasons.
See https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
$ export SCCACHE_BUCKET=rust-lang-ci-sccache2
$ export SCCACHE_REGION=us-west-1
$ export GCP_CACHE_BUCKET=rust-lang-ci-cache
Setting environment variables from .travis.yml
---
[00:02:00] ######################################################################## 100.0%
[00:02:00] extracting /checkout/obj/build/cache/2019-03-20/cargo-beta-x86_64-unknown-linux-gnu.tar.gz
[00:02:00] Updating crates.io index
[00:02:15] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:15] Build completed unsuccessfully in 0:00:31
[00:02:15] make: *** [prepare] Error 1
[00:02:15] Makefile:69: recipe for target 'prepare' failed
[00:02:16] Command failed. Attempt 2/5:
[00:02:16] Command failed. Attempt 2/5:
[00:02:16] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:16] Build completed unsuccessfully in 0:00:00
[00:02:16] Makefile:69: recipe for target 'prepare' failed
[00:02:16] make: *** [prepare] Error 1
[00:02:18] Command failed. Attempt 3/5:
[00:02:18] Command failed. Attempt 3/5:
[00:02:19] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:19] Build completed unsuccessfully in 0:00:00
[00:02:19] Makefile:69: recipe for target 'prepare' failed
[00:02:19] make: *** [prepare] Error 1
[00:02:22] Command failed. Attempt 4/5:
[00:02:22] Command failed. Attempt 4/5:
[00:02:22] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:22] Build completed unsuccessfully in 0:00:00
[00:02:22] make: *** [prepare] Error 1
[00:02:22] Makefile:69: recipe for target 'prepare' failed
[00:02:26] Command failed. Attempt 5/5:
[00:02:26] Command failed. Attempt 5/5:
[00:02:26] error: the lock file /checkout/Cargo.lock needs to be updated but --locked was passed to prevent this
[00:02:26] Build completed unsuccessfully in 0:00:00
[00:02:27] make: *** [prepare] Error 1
[00:02:27] Makefile:69: recipe for target 'prepare' failed
[00:02:27] The command has failed after 5 attempts.
---
travis_time:end:0a5a4668:start=1554230256764929768,finish=1554230256771327382,duration=6397614
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:1c66074c
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb --batch -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:090c841e
travis_time:start:090c841e
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:11d77aa8
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

[alexcrichton]

Oops sorry didn't realize this was ready to go again! If you want to run ./x.py build it should regenerate the lock file early on and that should be all that's necessary now!

Otherwise this lgtm, so

@bors: delegate+

[bors]

✌️ @petrhosek can now approve this pull request

[petrhosek]

@bors r+

[bors]

📌 Commit 6c0c9a00f9d4ee7c7c136bddf9b5a9f76b4acee5 has been approved by petrhosek

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout llvm-unwind(switch to your branch)
2. git fetch upstream master(retrieve the latest master)
3. git rebase upstream/master -p(rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self llvm-unwind --force-with-lease(update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

warning: Cannot merge binary files: Cargo.lock (HEAD vs. heads/homu-tmp)
Auto-merging src/bootstrap/lib.rs
Auto-merging Cargo.lock
CONFLICT (content): Merge conflict in Cargo.lock
Automatic merge failed; fix conflicts and then commit the result.

[petrhosek]

@bors r+

[bors]

📌 Commit 86d1678 has been approved by petrhosek

[tesuji]

@petrhosek You might want to use bors r=<approver> instead.

[bors]

⌛ Testing commit 86d1678 with merge f717b58...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: petrhosek
Pushing f717b58 to master...

[jethrogb]

Is there a reason you're not just invoking CMake?

[petrhosek]

We could use CMakeLists.txt, the reason I avoided it was to reduce the dependencies, especially since libunwind's build is very minimal.

I'm not sure if it's necessarily going to reduce the need for maintenance. libunwind's CMake build is also evolving, and most new flags are usually gated on options which would need to be reflected here as well.