bors [Tue, 28 May 2019 17:38:01 +0000 (17:38 +0000)]
Auto merge of #61274 - Centril:rollup-23dekk4, r=Centril
Rollup of 4 pull requests
Successful merges:
- #61123 (Allow to specify profiling data output directory as -Zself-profile argument.)
- #61159 (split core::ptr module into multiple files)
- #61164 (rename Scalar::Bits to Scalar::Raw and bits field to data)
- #61250 (Remove special case for *ios* builds in run-make-fulldeps/print-target-list Makefile)
Rollup merge of #61250 - rye:print-target-list--rm-ios-case, r=alexcrichton
Remove special case for *ios* builds in run-make-fulldeps/print-target-list Makefile
Previous `TODO` comment in this file mentions [an issue that was closed](https://github.com/rust-lang/rust/issues/29812), and I was able to confirm locally that provided code in that issue no longer produces an ICE. Discussion on that issue seems to indicate this code was no longer needed as of 1.12.0.
I removed the `*ios*` branch from this `case` statement as it may cause confusion, then removed the case statement entirely as it only had a wildcard branch.
bors [Tue, 28 May 2019 01:56:44 +0000 (01:56 +0000)]
Auto merge of #61036 - michaelwoerister:pgo-xlto-test, r=alexcrichton
PGO - Add a smoketest for combining PGO with cross-language LTO.
This PR
- Adds a test making sure that PGO can be combined with cross-language LTO.
- Does a little cleanup on how the `pgo-use` flag is handled internally.
- Makes the compiler error if the `pgo-use` file given to `rustc` doesn't actually exist. LLVM only gives a warning and then just doesn't do PGO. Clang, on the other hand, does give an error in this case.
- Makes the build system also build `compiler-rt` when building LLDB. This way the Clang compiler that we get from building LLDB can perform PGO, which is something that the new test case wants to do. CI compile times shouldn't be affected too much.
Kristofer Rye [Tue, 28 May 2019 00:40:11 +0000 (19:40 -0500)]
Fix an sh error
Didn't think it was this particular about things, but I also should
have tested locally.
It makes sense, though---`\` followed by LF would eat it, so we'd have
`sysroot done` instead of `sysroot; done` as it is parsed. This should
pass now.
Kristofer Rye [Mon, 27 May 2019 21:44:16 +0000 (16:44 -0500)]
Remove *ios* case from print-target-list Makefile
Based on the TODO, this case was added to short-circuit for ios builds,
which is no longer necessary.
The comment in this Makefile mentions rust-lang/rust#29812 as a
dependency, but that issue has been since closed, with a statement that
the ICE of concern was resolved circa 1.12.
Here we remove this case, and just run the same branch for all targets.
bors [Mon, 27 May 2019 15:36:32 +0000 (15:36 +0000)]
Auto merge of #60827 - oli-obk:late_symbol, r=nnethercote
Use `Symbol` more in lint APIs
r? @nnethercote
This will cause clippy breakage, but super trivial to fix since we can then remove the hacky `match_def_path` function that I added and go back to calling rustc's `match_def_path` method.
bors [Sun, 26 May 2019 18:48:12 +0000 (18:48 +0000)]
Auto merge of #61213 - pietroalbini:fix-azure-multiple-checkouts, r=alexcrichton
azure: fix multiple checkouts on azure
We were checking out the rustc repo multiple times on auto macOS, and
that was causing an error on the Azure side since multiple checkouts are
apparently not supported. This removes the extra checkout.
Pietro Albini [Sun, 26 May 2019 15:12:13 +0000 (17:12 +0200)]
ci: fix multiple checkouts on azure
We were checking out the rustc repo multiple times on auto macOS, and
that was causing an error on the Azure side since multiple checkouts are
apparently not supported. This removes the extra checkout.
Andrew Xu [Sun, 19 May 2019 08:26:08 +0000 (16:26 +0800)]
Rename "Associated*" to "Assoc*"
We are going to uniform the terminology of all associated items.
Methods that may or may not have `self` are called "associated
functions". Because `AssociatedFn` is a bit long, we rename `Associated`
to `Assoc`.
bors [Sun, 26 May 2019 06:09:08 +0000 (06:09 +0000)]
Auto merge of #61201 - Centril:rollup-975knrk, r=Centril
Rollup of 9 pull requests
Successful merges:
- #61087 (Tweak `self` arg not as first argument of a method diagnostic)
- #61114 (Vec: avoid creating slices to the elements)
- #61144 (Suggest borrowing for loop head on move error)
- #61149 (Fix spelling in release notes)
- #61161 (MaybeUninit doctest: remove unnecessary type ascription)
- #61173 (Auto-derive Encode and Decode implementations of DefPathTable)
- #61184 (Add additional trace statements to the const propagator)
- #61189 (Turn turbo 🐟 🍨 into an error)
- #61193 (Add comment to explain why we change the layout for Projection)
bors [Sun, 26 May 2019 03:26:10 +0000 (03:26 +0000)]
Auto merge of #60852 - alexcrichton:std-backtrace, r=sfackler
std: Depend on `backtrace` crate from crates.io
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
Instead of `self.deref_mut().as_mut_ptr()` to get a raw pointer to the buffer, use `self.buf.ptr_mut()`. This (a) avoids creating a unique reference to all existing elements without any need, and (b) creates a pointer that can actually be used for the *entire* buffer, and not just for the part of it covered by `self.deref_mut()`.
I also got worried about `RawVec::ptr` returning a `*mut T` from an `&self`, so I added both a mutable and an immutable version.
Cc @Gankro in particular for the `assume` changes -- I don't know why that is not in `Unique`, but I moved it up from `Vec::deref` to `RawVec::ptr` to avoid having to repeat it everywhere.
Rollup merge of #61087 - estebank:parsepalooza, r=Centril
Tweak `self` arg not as first argument of a method diagnostic
Mention that `self` is only valid on "associated functions"
```
error: unexpected `self` argument in function
--> $DIR/self-in-function-arg.rs:1:15
|
LL | fn foo(x:i32, self: i32) -> i32 { self }
| ^^^^ not valid as function argument
|
= note: `self` is only valid as the first argument of an associated function
```
When it is a method, mention it must be first
```
error: unexpected `self` argument in function
--> $DIR/trait-fn.rs:4:20
|
LL | fn c(foo: u32, self) {}
| ^^^^ must be the first associated function argument
```
Move a bunch of error recovery methods to `diagnostics.rs` away from `parser.rs`.
Alex Crichton [Wed, 15 May 2019 14:30:15 +0000 (07:30 -0700)]
std: Depend on `backtrace` crate from crates.io
This commit removes all in-tree support for generating backtraces in
favor of depending on the `backtrace` crate on crates.io. This resolves
a very longstanding piece of duplication where the standard library has
long contained the ability to generate a backtrace on panics, but the
code was later extracted and duplicated on crates.io with the
`backtrace` crate. Since that fork each implementation has seen various
improvements one way or another, but typically `backtrace`-the-crate has
lagged behind libstd in one way or another.
The goal here is to remove this duplication of a fairly critical piece
of code and ensure that there's only one source of truth for generating
backtraces between the standard library and the crate on crates.io.
Recently I've been working to bring the `backtrace` crate on crates.io
up to speed with the support in the standard library which includes:
* Support for `StackWalkEx` on MSVC to recover inline frames with
debuginfo.
* Using `libbacktrace` by default on MinGW targets.
* Supporting `libbacktrace` on OSX as an option.
* Ensuring all the requisite support in `backtrace`-the-crate compiles
with `#![no_std]`.
* Updating the `libbacktrace` implementation in `backtrace`-the-crate to
initialize the global state with the correct filename where necessary.
After reviewing the code in libstd the `backtrace` crate should be at
exact feature parity with libstd today. The backtraces generated should
have the same symbols and same number of frames in general, and there's
not known divergence from libstd currently.
Note that one major difference between libstd's backtrace support and
the `backtrace` crate is that on OSX the crates.io crate enables the
`coresymbolication` feature by default. This feature, however, uses
private internal APIs that aren't published for OSX. While they provide
more accurate backtraces this isn't appropriate for libstd distributed
as a binary, so libstd's dependency on the `backtrace` crate explicitly
disables this feature and forces OSX to use `libbacktrace` as a
symbolication strategy.
The long-term goal of this refactoring is to eventually move us towards
a world where we can drop `libbacktrace` entirely and simply use Gimli
and the surrounding crates for backtrace support. That's still aways off
but hopefully will much more easily enabled by having the source of
truth for backtraces live in crates.io!
Procedurally if we go forward with this I'd like to transfer the
`backtrace-rs` crate to the rust-lang GitHub organization as well, but I
figured I'd hold off on that until we get closer to merging.
projects / rust.git / log