Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 7 pull requests #65587

Closed
wants to merge 37 commits into from
Closed

Conversation

Centril
Copy link
Contributor

@Centril Centril commented Oct 19, 2019

Successful merges:

Failed merges:

r? @ghost

SimonSapin and others added 30 commits October 6, 2019 23:48
Requesting a zero-size allocation is not allowed,
return a dangling pointer instead.

CC rust-lang#63291 (comment)
The static libraries produced by rustc no longer contain sanitizer
runtime libraries, so the final linking step needs to be performed
with rustc and sanitizer flag.
Instead of `as_str()`, which unnecessarily involves `LocalInternedString`.
Currently, `Symbol::Debug` and `Symbol::Display` produce the same
output; neither wraps the symbol in double quotes.

This commit changes `Symbol::Debug` so it wraps the symbol in quotes.
This change brings `Symbol`'s behaviour in line with `String` and
`InternedString`. The change requires a couple of trivial test output
adjustments.
Fix zero-size uninitialized boxes

Requesting a zero-size allocation is not allowed, return a dangling pointer instead.

CC rust-lang#63291 (comment)
build-std compatible sanitizer support

### Motivation

When using `-Z sanitizer=*` feature it is essential that both user code and
standard library is instrumented. Otherwise the utility of sanitizer will be
limited, or its use will be impractical like in the case of memory sanitizer.

The recently introduced cargo feature build-std makes it possible to rebuild
standard library with arbitrary rustc flags. Unfortunately, those changes alone
do not make it easy to rebuild standard library with sanitizers, since runtimes
are dependencies of std that have to be build in specific environment,
generally not available outside rustbuild process. Additionally rebuilding them
requires presence of llvm-config and compiler-rt sources.

The goal of changes proposed here is to make it possible to avoid rebuilding
sanitizer runtimes when rebuilding the std, thus making it possible to
instrument standard library for use with sanitizer with simple, although
verbose command:

```
env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu
```

### Implementation

* Sanitizer runtimes are no long packed into crates. Instead, libraries build
  from compiler-rt are used as is, after renaming them into `librusc_rt.*`.
* rustc obtains runtimes from target libdir for default sysroot, so that
  they are not required in custom build sysroots created with build-std.
* The runtimes are only linked-in into executables to address issue rust-lang#64629.
  (in previous design it was hard to avoid linking runtimes into static
  libraries produced by rustc as demonstrated by sanitizer-staticlib-link
  test, which still passes despite changes made in rust-lang#64780).
* When custom llvm-config is specified during build process, the sanitizer
  runtimes will be obtained from there instead of begin rebuilding from sources
  in src/llvm-project/compiler-rt. This should be preferable since runtimes
  used should match instrumentation passes. For example there have been nine
  version of address sanitizer ABI.

Note this marked as a draft PR, because it is currently untested on OS X (I
would appreciate any help there).

cc @kennytm, @japaric, @Firstyear, @choller
…excrichton

Upgrade GCC to 8.3.0, glibc to 1.17.0 and crosstool-ng to 1.24.0 for dist-armv7-linux

rust-lang#62896 was caused by the usage of the GCC 5.2.0 toolchain, which was released back in 2015 and may have bugs affecting LLVM 9.
This PR upgrade GCC to 8.3.0 from 5.2.0, glibc from 1.16.0 to 1.17.0 and crosstool-ng to 1.24.0 only for dist-armv7-linux.
Fixes rust-lang#62896

r? @alexcrichton
Update libc to 0.2.64

Passed local tests.

cc potentially interested people: @gnzlbg @tlively
…match-ugliness, r=eddyb

Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut`

Resolves rust-lang#65394.

This hack disables the validator mismatch ICE in cases where a `MutBorrow` error has been emitted by both validators, but they don't agree on the number of `LiveDrop` errors.

The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a `LiveDrop` error on the following code.

```rust
const _: Vec<i32> = {
    let mut x = Vec::new();
    let px = &mut x as *mut _;
    let y = x;
    unsafe { ptr::write(px, Vec::new()); }
    y
};
```

This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a `LiveDrop` error for `x` upon exit from the initializer. `x` is not actually dropped, so I think this is correct? A proper fix for this would require a new `MaybeInitializedLocals` dataflow analysis or maybe a relaxation of the existing `IndirectlyMutableLocals` one.

r? @RalfJung
…tril

Refer to "associated functions" instead of "static methods"

Fix rust-lang#59782.
…=petrochenkov

More symbol cleanups

Some minor improvements, mostly aimed at reducing unimportant differences between `Symbol` and `InternedString`. Helps a little with rust-lang#60869.

r? @petrochenkov
@Centril
Copy link
Contributor Author

Centril commented Oct 19, 2019

@bors r+ p=7 rollup=never

@bors
Copy link
Contributor

bors commented Oct 19, 2019

📌 Commit c21c919 has been approved by Centril

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 19, 2019
@Centril Centril added the rollup A PR which is a rollup label Oct 19, 2019
@bors
Copy link
Contributor

bors commented Oct 19, 2019

⌛ Testing commit c21c919 with merge e3874222fbade336d43833611a8a5f66c49eacca...

@rust-highfive
Copy link
Collaborator

The job x86_64-apple of your PR failed (pretty log, 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.

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)

@bors
Copy link
Contributor

bors commented Oct 19, 2019

💔 Test failed - checks-azure

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 19, 2019
@Centril Centril closed this Oct 19, 2019
@Centril Centril deleted the rollup-fjhzg09 branch October 19, 2019 05:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants