Add Context::from_dwarf constructor

[RReverser]

When one already has a gimli::Dwarf object created with a custom gimli::Dwarf::load invocation, it's not very convenient to deconstruct it to separate sections just to create a Context.

Given that Context already uses gimli::Dwarf internally, let's expose an additional constructor that allows to take it.

[coveralls]

Coverage increased (+0.08%) to 73.669% when pulling 75324ac on RReverser:from-dwarf into ef392cb on gimli-rs:master.

[RReverser]

thread 'correctness' panicked at 'incorrect name '<T as core::convert::From<T>>::from'', tests/correctness.rs:34:9

Huh, that's... interesting. I wonder if it's really related to my changes?

[fitzgen]

I don't get that error, but I do get a panic in rustc-test:

~/addr2line
$ RUST_BACKTRACE=1 cargo test --all
   Compiling cpp_demangle v0.2.4
   Compiling addr2line v0.10.0 (/home/fitzgen/addr2line)
    Finished dev [unoptimized + debuginfo] target(s) in 4.80s
     Running target/debug/deps/addr2line-f6f69d806e0a463d

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/correctness-83b7dd2ff949f276

running 3 tests
test zero_sequence ... ok
test zero_function ... ok
test correctness ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

     Running target/debug/deps/output_equivalence-eedcf0d8cf62fecb

running 32 tests
thread 'main' panicked at 'io error when running tests: Custom { kind: Other, error: ColorOutOfRange }', /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-test-0.3.0/src/lib.rs:263:19
stack backtrace:
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', src/libcore/result.rs:1084:5
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.35/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.35/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:47
   3: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:36
   4: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   5: std::panicking::default_hook
             at src/libstd/panicking.rs:214
   6: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:477
   7: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:384
   8: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:339
   9: rustc_test::test_main
             at /home/fitzgen/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-test-0.3.0/src/lib.rs:263
  10: output_equivalence::main
             at tests/output_equivalence.rs:140
  11: std::rt::lang_start::{{closure}}
             at /rustc/521d78407471cb78e9bbf47160f6aa23047ac499/src/libstd/rt.rs:64
  12: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:49
  13: std::panicking::try::do_call
             at src/libstd/panicking.rs:296
  14: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:80
  15: std::panicking::try
             at src/libstd/panicking.rs:275
  16: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  17: std::rt::lang_start_internal
             at src/libstd/rt.rs:48
  18: std::rt::lang_start
             at /rustc/521d78407471cb78e9bbf47160f6aa23047ac499/src/libstd/rt.rs:64
  19: main
  20: __libc_start_main
  21: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.35/src/backtrace/libunwind.rs:88
   1: backtrace::backtrace::trace_unsynchronized
             at error: test failed, to rerun pass '--test output_equivalence'

[fitzgen]

Either way, I suspect that this test is just flaky, not that it is related to this PR.

[RReverser]

FWIW that error was from Travis failure logs.

[philipc]

That nightly build in travis has been failing for a while. I'll try to get around to looking into it before we do another addr2line release.

[philipc]

Thanks!