Commit Graph

787 Commits

Author SHA1 Message Date
Cameron Taggart
2b1fc16153 update stacker to 0.1.11 to unbreak build for wasm32-unknown-unknown 2020-08-17 10:57:53 -06:00
Matthew Jasper
c4f91bb281 Fix rustc_serialize unit tests 2020-08-14 17:34:32 +01:00
Matthew Jasper
cbcef3effc Rework rustc_serialize
- Move the type parameter from `encode` and `decode` methods to
  the trait.
- Remove `UseSpecialized(En|De)codable` traits.
- Remove blanket impls for references.
- Add `RefDecodable` trait to allow deserializing to arena-allocated
  references safely.
- Remove ability to (de)serialize HIR.
- Create proc-macros `(Ty)?(En|De)codable` to help implement these new
  traits.
2020-08-14 17:34:30 +01:00
bors
d69b0997d7 Auto merge of #75431 - ehuss:platform-support, r=Mark-Simulacrum
Move platform support to the rustc book.

This moves the [Platform Support](https://forge.rust-lang.org/release/platform-support.html) page from the forge to the rustc book. There are several reasons for doing this:

* The forge is not really oriented towards end-users (it mostly contains infrastructure, governance and policy, internal team pages, etc.). This platform support page is useful to user to know which targets are supported.
* This page can now be updated in-sync with any PRs that add or remove a target, or change its status.
* This is now automatically checked on CI to verify the list does not get out of sync. Currently it only checks the presence/absence of an entry, but more sophisticated checks could be added in the future.

I'm not 100% certain this is the best location, but I think it fits. I'd like to see the rustc guide continue to grow, including things like linking information and more platform-specific details.
2020-08-13 06:17:25 +00:00
Eric Huss
ce717476ff Add a script to verify the Platform Support page is up-to-date. 2020-08-12 08:40:22 -07:00
Igor Matuszewski
cb40a1c4c9 Update RLS and Rustfmt 2020-08-12 01:25:46 +02:00
Tyler Mandry
c18b64c866
Rollup merge of #75378 - petrochenkov:isident, r=Mark-Simulacrum
Introduce `rustc_lexer::is_ident` and use it in couple of places

Implements the suggestion from https://github.com/rust-lang/rust/pull/74537#issuecomment-662261979.
2020-08-11 12:28:32 -07:00
Dylan DPC
992988bbc5
Rollup merge of #75315 - Mark-Simulacrum:save-temps, r=ecstatic-morse
Avoid deleting temporary files on error

Previously if the compiler error'd, fatally, then temporary directories which
should be preserved by -Csave-temps would be deleted due to fatal compiler
errors being implemented as panics.

cc @infinity0

(Hopefully) fixes #75275, but I haven't tested
2020-08-11 01:56:34 +02:00
Vadim Petrochenkov
20c5044465 Introduce rustc_lexer::is_ident and use it in couple of places 2020-08-11 00:08:04 +03:00
Josh Stone
997a766b32 Upgrade indexmap to 1.5.1, now using hashbrown! 2020-08-09 12:25:21 -07:00
Mark Rousskov
2627eedde9 Avoid deleting temporary files on error
Previously if the compiler error'd, fatally, then temporary directories which
should be preserved by -Csave-temps would be deleted due to fatal compiler
errors being implemented as panics.
2020-08-09 08:28:15 -04:00
Amanieu d'Antras
99f0052151 Update hashbrown to 0.8.2 2020-08-08 15:03:47 +01:00
Nicholas Nethercote
3dc8a36958 Eliminate librustc_hir's dependency on librustc_session. 2020-08-08 12:03:44 +10:00
Nicholas Nethercote
e539dd65f8 Eliminate the SessionGlobals from librustc_ast.
By moving `{known,used}_attrs` from `SessionGlobals` to `Session`. This
means they are accessed via the `Session`, rather than via TLS. A few
`Attr` methods and `librustc_ast` functions are now methods of
`Session`.

All of this required passing a `Session` to lots of functions that didn't
already have one. Some of these functions also had arguments removed, because
those arguments could be accessed directly via the `Session` argument.

`contains_feature_attr()` was dead, and is removed.

Some functions were moved from `librustc_ast` elsewhere because they now need
to access `Session`, which isn't available in that crate.
- `entry_point_type()` --> `librustc_builtin_macros`
- `global_allocator_spans()` --> `librustc_metadata`
- `is_proc_macro_attr()` --> `Session`
2020-08-08 12:03:42 +10:00
Amanieu d'Antras
d51b7b229a Update hashbrown to 0.8.1 2020-08-07 07:03:12 +01:00
Nicholas Nethercote
d93277b915 Remove GCX_PTR.
We store an `ImplicitCtxt` pointer in a thread-local value (TLV). This allows
implicit access to a `GlobalCtxt` and some other things.

We also store a `GlobalCtxt` pointer in `GCX_PTR`. This is always the same
`GlobalCtxt` as the one within the `ImplicitCtxt` pointer in TLV. `GCX_PTR`
is only used in the parallel compiler's `handle_deadlock()` function.

This commit does the following.
- It removes `GCX_PTR`.
- It also adds `ImplicitCtxt::new()`, which constructs an `ImplicitCtxt` from a
  `GlobalCtxt`. `ImplicitCtxt::new()` + `tls::enter_context()` is now
  equivalent to the old `tls::enter_global()`.
- Makes `tls::get_tlv()` public for the parallel compiler, because it's
  now used in `handle_deadlock()`.
2020-08-03 09:40:41 +10:00
Yuki Okushi
21ebf6900d
Rollup merge of #75010 - Aaron1011:feature/remove-old-deps, r=Mark-Simulacrum
Update elasticlunr-rs and ammonia transitive deps

This removes all dependencies on pre-1.0 proc-macro ecosystem crates
(syn, quote, and proc-macro2)
2020-08-03 01:05:22 +09:00
bors
12799ad60c Auto merge of #74899 - sajattack:libc_0.2.74_bump, r=jonas-schievink
bump libc version to 0.2.74
2020-08-02 07:23:14 +00:00
Aaron Hill
70ba491b78
Update elasticlunr-rs and ammonia transitive deps
This removes all dependencies on pre-1.0 proc-macro ecosystem crates
(syn, quote, and proc-macro2)
2020-08-01 21:15:53 -04:00
Aaron Hill
183947f6ba
Move 'probably equal' methods to librustc_parse
This is preparation for PR #73084
2020-08-01 21:12:49 -04:00
Oliver Scherer
c7290379be Remove chrono feature from tracing 2020-08-01 16:24:52 +02:00
Oliver Scherer
358e21ee78 Disable log support 2020-07-31 22:42:09 +02:00
Oliver Scherer
ec7230fea2 Move from log to tracing 2020-07-31 22:38:20 +02:00
bors
c058a8b8dc Auto merge of #74682 - alexcrichton:backtrace-gimli-round-2, r=Mark-Simulacrum
std: Switch from libbacktrace to gimli (take 2)

This is the second attempt to land https://github.com/rust-lang/rust/pull/73441 after being reverted in https://github.com/rust-lang/rust/pull/74613. Will be gathering precise perf numbers here in this take.

Closes #71060
2020-07-30 23:22:09 +00:00
bors
6e50a225fd Auto merge of #74923 - ehuss:update-cargo, r=Mark-Simulacrum
Update cargo

14 commits in aa6872140ab0fa10f641ab0b981d5330d419e927..974eb438da8ced6e3becda2bbf63d9b643eacdeb
2020-07-23 13:46:27 +0000 to 2020-07-29 16:15:05 +0000
- Fix O0 build scripts by default without `[profile.release]` (rust-lang/cargo#8560)
- Emphasize git dependency version locking behavior. (rust-lang/cargo#8561)
- Update lock file encodings on changes (rust-lang/cargo#8554)
- Fix sporadic lto test failures. (rust-lang/cargo#8559)
- build-std: Fix libraries paths following upstream (rust-lang/cargo#8558)
- Flag git http errors as maybe spurious (rust-lang/cargo#8553)
- Display builtin aliases with `cargo --list` (rust-lang/cargo#8542)
- Check manifest for requiring nonexistent features (rust-lang/cargo#7950)
- Clarify test name filter usage (rust-lang/cargo#8552)
- Revert Cargo Book changes for default edition (rust-lang/cargo#8551)
- Prepare for not defaulting to master branch for git deps (rust-lang/cargo#8522)
- Include `+` for crates.io feature requirements in the Cargo Book section on features (rust-lang/cargo#8547)
- Update termcolor and fwdansi versions (rust-lang/cargo#8540)
- Cargo book nitpick in Manifest section (rust-lang/cargo#8543)
2020-07-30 02:05:48 +00:00
Eric Huss
89d7906acd Update cargo 2020-07-29 11:02:05 -07:00
Xavier Denis
f07607f47a Move mir-opt tests to toplevel 2020-07-29 17:36:03 +02:00
Paul Sajna
7baa87fccf bump libc version to 0.2.74 2020-07-29 01:10:57 -07:00
Alex Crichton
06d565c967 std: Switch from libbacktrace to gimli
This commit is a proof-of-concept for switching the standard library's
backtrace symbolication mechanism on most platforms from libbacktrace to
gimli. The standard library's support for `RUST_BACKTRACE=1` requires
in-process parsing of object files and DWARF debug information to
interpret it and print the filename/line number of stack frames as part
of a backtrace.

Historically this support in the standard library has come from a
library called "libbacktrace". The libbacktrace library seems to have
been extracted from gcc at some point and is written in C. We've had a
lot of issues with libbacktrace over time, unfortunately, though. The
library does not appear to be actively maintained since we've had
patches sit for months-to-years without comments. We have discovered a
good number of soundness issues with the library itself, both when
parsing valid DWARF as well as invalid DWARF. This is enough of an issue
that the libs team has previously decided that we cannot feed untrusted
inputs to libbacktrace. This also doesn't take into account the
portability of libbacktrace which has been difficult to manage and
maintain over time. While possible there are lots of exceptions and it's
the main C dependency of the standard library right now.

For years it's been the desire to switch over to a Rust-based solution
for symbolicating backtraces. It's been assumed that we'll be using the
Gimli family of crates for this purpose, which are targeted at safely
and efficiently parsing DWARF debug information. I've been working
recently to shore up the Gimli support in the `backtrace` crate. As of a
few weeks ago the `backtrace` crate, by default, uses Gimli when loaded
from crates.io. This transition has gone well enough that I figured it
was time to start talking seriously about this change to the standard
library.

This commit is a preview of what's probably the best way to integrate
the `backtrace` crate into the standard library with the Gimli feature
turned on. While today it's used as a crates.io dependency, this commit
switches the `backtrace` crate to a submodule of this repository which
will need to be updated manually. This is not done lightly, but is
thought to be the best solution. The primary reason for this is that the
`backtrace` crate needs to do some pretty nontrivial filesystem
interactions to locate debug information. Working without `std::fs` is
not an option, and while it might be possible to do some sort of
trait-based solution when prototyped it was found to be too unergonomic.
Using a submodule allows the `backtrace` crate to build as a submodule
of the `std` crate itself, enabling it to use `std::fs` and such.

Otherwise this adds new dependencies to the standard library. This step
requires extra attention because this means that these crates are now
going to be included with all Rust programs by default. It's important
to note, however, that we're already shipping libbacktrace with all Rust
programs by default and it has a bunch of C code implementing all of
this internally anyway, so we're basically already switching
already-shipping functionality to Rust from C.

* `object` - this crate is used to parse object file headers and
  contents. Very low-level support is used from this crate and almost
  all of it is disabled. Largely we're just using struct definitions as
  well as convenience methods internally to read bytes and such.

* `addr2line` - this is the main meat of the implementation for
  symbolication. This crate depends on `gimli` for DWARF parsing and
  then provides interfaces needed by the `backtrace` crate to turn an
  address into a filename / line number. This crate is actually pretty
  small (fits in a single file almost!) and mirrors most of what
  `dwarf.c` does for libbacktrace.

* `miniz_oxide` - the libbacktrace crate transparently handles
  compressed debug information which is compressed with zlib. This crate
  is used to decompress compressed debug sections.

* `gimli` - not actually used directly, but a dependency of `addr2line`.

* `adler32`- not used directly either, but a dependency of
  `miniz_oxide`.

The goal of this change is to improve the safety of backtrace
symbolication in the standard library, especially in the face of
possibly malformed DWARF debug information. Even to this day we're still
seeing segfaults in libbacktrace which could possibly become security
vulnerabilities. This change should almost entirely eliminate this
possibility whilc also paving the way forward to adding more features
like split debug information.

Some references for those interested are:

* Original addition of libbacktrace - #12602
* OOM with libbacktrace - #24231
* Backtrace failure due to use of uninitialized value - #28447
* Possibility to feed untrusted data to libbacktrace - #21889
* Soundness fix for libbacktrace - #33729
* Crash in libbacktrace - #39468
* Support for macOS, never merged - ianlancetaylor/libbacktrace#2
* Performance issues with libbacktrace - #29293, #37477
* Update procedure is quite complicated due to how many patches we
  need to carry - #50955
* Libbacktrace doesn't work on MinGW with dynamic libs - #71060
* Segfault in libbacktrace on macOS - #71397

Switching to Rust will not make us immune to all of these issues. The
crashes are expected to go away, but correctness and performance may
still have bugs arise. The gimli and `backtrace` crates, however, are
actively maintained unlike libbacktrace, so this should enable us to at
least efficiently apply fixes as situations come up.
2020-07-28 16:34:01 -07:00
Tyler Mandry
e193cb1fde Update Cargo.lock 2020-07-25 14:26:31 -07:00
Manish Goregaokar
dfedb84462
Rollup merge of #72954 - hermitcore:rwlock, r=dtolnay
revise RwLock for HermitCore

- current version is derived from the wasm implementation
- increasing the readability of `Condvar`
- simplify the interface to the libos
2020-07-24 10:01:28 -07:00
Eric Huss
76103f1d15 Update cargo 2020-07-23 08:28:50 -07:00
bors
371917ab21 Auto merge of #74613 - Mark-Simulacrum:revert-gimli, r=nnethercote
Revert libbacktrace -> gimli

This reverts 4cbd265c11 028f8d7b85 13db3cc1e8 d7a36d8964 (and technically 79673d3009 but it's made empty by previous reverts).

The current plan is to land this PR as a temporary change, so that we can get a better handle on the regressions introduced by it. Trying to fix/examine them in master is difficult, and we want to be better able to evaluate them without impact to other PRs being landed in the mean time.

That said, it is currently *my* belief that gimli, in one form or another, will need to land sometime soon. I think it's quite likely that it may slip a week or two, but I would personally push for re-landing it then "regardless" of the regressions. We should try to focus efforts on understanding and removing as much of the performance impact as possible, as everyone pretty much agrees that it should be quite minimal (and entirely in the linker, basically).

r? @nnethercote
2020-07-23 11:14:48 +00:00
Mark Rousskov
cc4f547cf4 Revert "std: Switch from libbacktrace to gimli"
This reverts commit 13db3cc1e8.
2020-07-22 07:16:45 -04:00
Jake Goulding
804241ea06 Update dependencies that have knowledge about aarch64-apple-darwin 2020-07-20 20:45:52 -04:00
bors
47ea6d90b0 Auto merge of #74091 - richkadel:llvm-coverage-map-gen-4, r=tmandry
Generating the coverage map

@tmandry @wesleywiser

rustc now generates the coverage map and can support (limited)
coverage report generation, at the function level.

Example commands to generate a coverage report:
```shell
$ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu
$ $BUILD/stage1/bin/rustc -Zinstrument-coverage \
$HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs
$ LLVM_PROFILE_FILE="main.profraw" ./main
called
$ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata
$ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main
```
![rust coverage report only 20200706](https://user-images.githubusercontent.com/3827298/86697299-1cbe8f80-bfc3-11ea-8955-451b48626991.png)

r? @wesleywiser

Rust compiler MCP rust-lang/compiler-team#278
Relevant issue: #34701 - Implement support for LLVMs code coverage instrumentation
2020-07-19 07:25:18 +00:00
bors
1fa54ad968 Auto merge of #73441 - alexcrichton:backtrace-gimli, r=Mark-Simulacrum
std: Switch from libbacktrace to gimli

This commit is a proof-of-concept for switching the standard library's
backtrace symbolication mechanism on most platforms from libbacktrace to
gimli. The standard library's support for `RUST_BACKTRACE=1` requires
in-process parsing of object files and DWARF debug information to
interpret it and print the filename/line number of stack frames as part
of a backtrace.

Historically this support in the standard library has come from a
library called "libbacktrace". The libbacktrace library seems to have
been extracted from gcc at some point and is written in C. We've had a
lot of issues with libbacktrace over time, unfortunately, though. The
library does not appear to be actively maintained since we've had
patches sit for months-to-years without comments. We have discovered a
good number of soundness issues with the library itself, both when
parsing valid DWARF as well as invalid DWARF. This is enough of an issue
that the libs team has previously decided that we cannot feed untrusted
inputs to libbacktrace. This also doesn't take into account the
portability of libbacktrace which has been difficult to manage and
maintain over time. While possible there are lots of exceptions and it's
the main C dependency of the standard library right now.

For years it's been the desire to switch over to a Rust-based solution
for symbolicating backtraces. It's been assumed that we'll be using the
Gimli family of crates for this purpose, which are targeted at safely
and efficiently parsing DWARF debug information. I've been working
recently to shore up the Gimli support in the `backtrace` crate. As of a
few weeks ago the `backtrace` crate, by default, uses Gimli when loaded
from crates.io. This transition has gone well enough that I figured it
was time to start talking seriously about this change to the standard
library.

This commit is a preview of what's probably the best way to integrate
the `backtrace` crate into the standard library with the Gimli feature
turned on. While today it's used as a crates.io dependency, this commit
switches the `backtrace` crate to a submodule of this repository which
will need to be updated manually. This is not done lightly, but is
thought to be the best solution. The primary reason for this is that the
`backtrace` crate needs to do some pretty nontrivial filesystem
interactions to locate debug information. Working without `std::fs` is
not an option, and while it might be possible to do some sort of
trait-based solution when prototyped it was found to be too unergonomic.
Using a submodule allows the `backtrace` crate to build as a submodule
of the `std` crate itself, enabling it to use `std::fs` and such.

Otherwise this adds new dependencies to the standard library. This step
requires extra attention because this means that these crates are now
going to be included with all Rust programs by default. It's important
to note, however, that we're already shipping libbacktrace with all Rust
programs by default and it has a bunch of C code implementing all of
this internally anyway, so we're basically already switching
already-shipping functionality to Rust from C.

* `object` - this crate is used to parse object file headers and
  contents. Very low-level support is used from this crate and almost
  all of it is disabled. Largely we're just using struct definitions as
  well as convenience methods internally to read bytes and such.

* `addr2line` - this is the main meat of the implementation for
  symbolication. This crate depends on `gimli` for DWARF parsing and
  then provides interfaces needed by the `backtrace` crate to turn an
  address into a filename / line number. This crate is actually pretty
  small (fits in a single file almost!) and mirrors most of what
  `dwarf.c` does for libbacktrace.

* `miniz_oxide` - the libbacktrace crate transparently handles
  compressed debug information which is compressed with zlib. This crate
  is used to decompress compressed debug sections.

* `gimli` - not actually used directly, but a dependency of `addr2line`.

* `adler32`- not used directly either, but a dependency of
  `miniz_oxide`.

The goal of this change is to improve the safety of backtrace
symbolication in the standard library, especially in the face of
possibly malformed DWARF debug information. Even to this day we're still
seeing segfaults in libbacktrace which could possibly become security
vulnerabilities. This change should almost entirely eliminate this
possibility whilc also paving the way forward to adding more features
like split debug information.

Some references for those interested are:

* Original addition of libbacktrace - #12602
* OOM with libbacktrace - #24231
* Backtrace failure due to use of uninitialized value - #28447
* Possibility to feed untrusted data to libbacktrace - #21889
* Soundness fix for libbacktrace - #33729
* Crash in libbacktrace - #39468
* Support for macOS, never merged - ianlancetaylor/libbacktrace#2
* Performance issues with libbacktrace - #29293, #37477
* Update procedure is quite complicated due to how many patches we
  need to carry - #50955
* Libbacktrace doesn't work on MinGW with dynamic libs - #71060
* Segfault in libbacktrace on macOS - #71397

Switching to Rust will not make us immune to all of these issues. The
crashes are expected to go away, but correctness and performance may
still have bugs arise. The gimli and `backtrace` crates, however, are
actively maintained unlike libbacktrace, so this should enable us to at
least efficiently apply fixes as situations come up.

---

I want to note that my purpose for creating a PR here is to start a conversation about this. I think that all the various pieces are in place that this is compelling enough that I think this transition should be talked about seriously. There are a number of items which still need to be addressed before actually merging this PR, however:

* [ ] `gimli` needs to be published to crates.io
* [ ] `addr2line` needs a publish
* [ ] `miniz_oxide` needs a publish
* [ ] Tests probably shouldn't recommend the `gimli` crate's traits for implementing
* [ ] The `backtrace` crate's branch changes need to be merged to the master branch (https://github.com/rust-lang/backtrace-rs/pull/349)
* [ ] The support for `libbacktrace` on some platforms needs to be audited to see if we should support more strategies in the gimli implementation - https://github.com/rust-lang/backtrace-rs/issues/325, https://github.com/rust-lang/backtrace-rs/issues/326, https://github.com/rust-lang/backtrace-rs/issues/350, https://github.com/rust-lang/backtrace-rs/issues/351

Most of the merging/publishing I'm not actively pushing on right now. It's a bit wonky for crates to support libstd so I'm holding off on pulling the trigger everywhere until there's a bit more discussion about how to go through with this. Namely https://github.com/rust-lang/backtrace-rs/pull/349 I'm going to hold off merging until we decide to go through with the submodule strategy.

In any case this is a pretty major change, so I suspect that the compiler team is likely going to be interested in this. I don't mean to force changes by dumping a bunch of code by any means. Integration of external crates into the standard library is so difficult I wanted to have a proof-of-concept to review while talking about whether to do this at all (hence the PR), but I'm more than happy to follow any processes needed to merge this. I must admit though that I'm not entirely sure myself at this time what the process would be to decide to merge this, so I'm hoping others can help me figure that out!
2020-07-18 16:08:23 +00:00
Federico Ponzi
4b6a0278fe
fixes #67108 by using the external crate 2020-07-18 00:01:27 +02:00
Alex Crichton
13db3cc1e8 std: Switch from libbacktrace to gimli
This commit is a proof-of-concept for switching the standard library's
backtrace symbolication mechanism on most platforms from libbacktrace to
gimli. The standard library's support for `RUST_BACKTRACE=1` requires
in-process parsing of object files and DWARF debug information to
interpret it and print the filename/line number of stack frames as part
of a backtrace.

Historically this support in the standard library has come from a
library called "libbacktrace". The libbacktrace library seems to have
been extracted from gcc at some point and is written in C. We've had a
lot of issues with libbacktrace over time, unfortunately, though. The
library does not appear to be actively maintained since we've had
patches sit for months-to-years without comments. We have discovered a
good number of soundness issues with the library itself, both when
parsing valid DWARF as well as invalid DWARF. This is enough of an issue
that the libs team has previously decided that we cannot feed untrusted
inputs to libbacktrace. This also doesn't take into account the
portability of libbacktrace which has been difficult to manage and
maintain over time. While possible there are lots of exceptions and it's
the main C dependency of the standard library right now.

For years it's been the desire to switch over to a Rust-based solution
for symbolicating backtraces. It's been assumed that we'll be using the
Gimli family of crates for this purpose, which are targeted at safely
and efficiently parsing DWARF debug information. I've been working
recently to shore up the Gimli support in the `backtrace` crate. As of a
few weeks ago the `backtrace` crate, by default, uses Gimli when loaded
from crates.io. This transition has gone well enough that I figured it
was time to start talking seriously about this change to the standard
library.

This commit is a preview of what's probably the best way to integrate
the `backtrace` crate into the standard library with the Gimli feature
turned on. While today it's used as a crates.io dependency, this commit
switches the `backtrace` crate to a submodule of this repository which
will need to be updated manually. This is not done lightly, but is
thought to be the best solution. The primary reason for this is that the
`backtrace` crate needs to do some pretty nontrivial filesystem
interactions to locate debug information. Working without `std::fs` is
not an option, and while it might be possible to do some sort of
trait-based solution when prototyped it was found to be too unergonomic.
Using a submodule allows the `backtrace` crate to build as a submodule
of the `std` crate itself, enabling it to use `std::fs` and such.

Otherwise this adds new dependencies to the standard library. This step
requires extra attention because this means that these crates are now
going to be included with all Rust programs by default. It's important
to note, however, that we're already shipping libbacktrace with all Rust
programs by default and it has a bunch of C code implementing all of
this internally anyway, so we're basically already switching
already-shipping functionality to Rust from C.

* `object` - this crate is used to parse object file headers and
  contents. Very low-level support is used from this crate and almost
  all of it is disabled. Largely we're just using struct definitions as
  well as convenience methods internally to read bytes and such.

* `addr2line` - this is the main meat of the implementation for
  symbolication. This crate depends on `gimli` for DWARF parsing and
  then provides interfaces needed by the `backtrace` crate to turn an
  address into a filename / line number. This crate is actually pretty
  small (fits in a single file almost!) and mirrors most of what
  `dwarf.c` does for libbacktrace.

* `miniz_oxide` - the libbacktrace crate transparently handles
  compressed debug information which is compressed with zlib. This crate
  is used to decompress compressed debug sections.

* `gimli` - not actually used directly, but a dependency of `addr2line`.

* `adler32`- not used directly either, but a dependency of
  `miniz_oxide`.

The goal of this change is to improve the safety of backtrace
symbolication in the standard library, especially in the face of
possibly malformed DWARF debug information. Even to this day we're still
seeing segfaults in libbacktrace which could possibly become security
vulnerabilities. This change should almost entirely eliminate this
possibility whilc also paving the way forward to adding more features
like split debug information.

Some references for those interested are:

* Original addition of libbacktrace - #12602
* OOM with libbacktrace - #24231
* Backtrace failure due to use of uninitialized value - #28447
* Possibility to feed untrusted data to libbacktrace - #21889
* Soundness fix for libbacktrace - #33729
* Crash in libbacktrace - #39468
* Support for macOS, never merged - ianlancetaylor/libbacktrace#2
* Performance issues with libbacktrace - #29293, #37477
* Update procedure is quite complicated due to how many patches we
  need to carry - #50955
* Libbacktrace doesn't work on MinGW with dynamic libs - #71060
* Segfault in libbacktrace on macOS - #71397

Switching to Rust will not make us immune to all of these issues. The
crashes are expected to go away, but correctness and performance may
still have bugs arise. The gimli and `backtrace` crates, however, are
actively maintained unlike libbacktrace, so this should enable us to at
least efficiently apply fixes as situations come up.
2020-07-17 14:32:18 -07:00
Rich Kadel
a6f8b8a211 Generating the coverage map
rustc now generates the coverage map and can support (limited)
coverage report generation, at the function level.

Example:

$ BUILD=$HOME/rust/build/x86_64-unknown-linux-gnu
$ $BUILD/stage1/bin/rustc -Zinstrument-coverage \
$HOME/rust/src/test/run-make-fulldeps/instrument-coverage/main.rs
$ LLVM_PROFILE_FILE="main.profraw" ./main
called
$ $BUILD/llvm/bin/llvm-profdata merge -sparse main.profraw -o main.profdata
$ $BUILD/llvm/bin/llvm-cov show --instr-profile=main.profdata main
    1|      1|pub fn will_be_called() {
    2|      1|    println!("called");
    3|      1|}
    4|       |
    5|      0|pub fn will_not_be_called() {
    6|      0|    println!("should not have been called");
    7|      0|}
    8|       |
    9|      1|fn main() {
   10|      1|    let less = 1;
   11|      1|    let more = 100;
   12|      1|
   13|      1|    if less < more {
   14|      1|        will_be_called();
   15|      1|    } else {
   16|      1|        will_not_be_called();
   17|      1|    }
   18|      1|}
2020-07-17 11:49:35 -07:00
Eric Huss
9e58908e27 Use cfg_if in libpanic_abort.
This allows setting a default abort using the core intrinsic.
2020-07-15 08:38:11 -07:00
Eric Huss
432b4c14aa Use cfg_if in libtest.
Simplifies some of the expressions, and provides a default.
2020-07-15 08:38:11 -07:00
Manish Goregaokar
99c0b9764a
Rollup merge of #74310 - nnethercote:use-ArrayVec-in-SparseBitSet, r=eddyb
Use `ArrayVec` in `SparseBitSet`.

Instead of `SmallVec`, because the maximum size is known.

r? @eddyb
2020-07-14 07:39:15 -07:00
Manish Goregaokar
b9a0f5803e
Rollup merge of #74173 - estebank:struct-pat-as-enum, r=petrochenkov
Detect tuple struct incorrectly used as struct pat

Subpart of #74005.

r? @petrochenkov
2020-07-14 07:39:02 -07:00
Nicholas Nethercote
c492ca40a2 Use ArrayVec in SparseBitSet.
Instead of `SmallVec`, because the maximum size is known.
2020-07-14 10:31:54 +10:00
Esteban Küber
5daedea3db Detect tuple struct incorrectly used as struct pat 2020-07-12 10:34:48 -07:00
Manish Goregaokar
9614238314
Rollup merge of #74116 - arlosi:aarch64build, r=pietroalbini
Fix cross compilation of LLVM to aarch64 Windows targets

When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.

This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.

If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.

Related issue: #72881
Requires LLVM change: rust-lang/llvm-project#67
2020-07-11 08:53:18 -07:00
Arlo Siemsen
59f979fa06 Fix cross-compilation of LLVM to aarch64 Windows targets
When cross-compiling, the LLVM build system recurses to build tools
that need to run on the host system. However, since we pass cmake defines
to set the compiler and target, LLVM still compiles these tools for the
target system, rather than the host. The tools then fail to execute
during the LLVM build.

This change sets defines for the tools that need to run on the
host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build
does not attempt to build them, and instead relies on the tools already built.

If compiling with clang-cl, this change also adds the `--target` option
to specify the target triple. MSVC compilers do not require this, since there
is a separate compiler binary for cross-compilation.
2020-07-08 08:19:50 -07:00
Michael Forney
32025fd76a Update rust-installer to latest version
This pulls in a fix for the install script on some tr(1) implementations,
as well as an update to use `anyhow` instead of `failure` for error
handling.
2020-07-07 14:15:51 -07:00
Stefan Lankes
6925ebdd60 use latest version of hermit-abi 2020-07-06 20:43:51 +02:00