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 10 pull requests #73115

Merged
merged 28 commits into from
Jun 8, 2020
Merged

Rollup of 10 pull requests #73115

merged 28 commits into from
Jun 8, 2020

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Jun 8, 2020

Successful merges:

Failed merges:

r? @ghost

zzau13 and others added 28 commits May 8, 2020 22:48
Incremental compilation needs to be turned off. Also added the other RUSTFLAGS that should/need to be turned on.
Fix suggestions from review.

Co-authored-by: Bastian Kauschke <[email protected]>
The other blocks depends on Deref to make it easier for readers when
reimplementing or reading the implementations.
There are two separate `impl<T, Global>` which no special reason, it would be
better to merge both of them.
- mention `--target` flag excludes RUSTFLAGS passing to build scripts and proc macros
Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.

This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying
actual line numbers.

While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
When creating default values a trait method needs to be called with an
explicit trait name.  `Default::default()` seems redundant.  A free
function on the other hand, when imported directly, seems to be a better
API, as it is just `default()`.  When implementing the trait, a method
is still required.
Update annotate-snippets-rs to 0.8.0

rust-lang#59346
I made major changes to this library. In the previous version we worked with owned while in the current one with borrowed.

I have adapted it without changing the behavior.
I have modified the coverage since the previous one did not return correctly the index of the character in the line.
impl AsRef<[T]> for vec::IntoIter<T>

Adds `impl<T> AsRef<[T]> for vec::IntoIter<T>`. This mirrors the same trait impl for [`slice::Iter`](https://doc.rust-lang.org/nightly/std/slice/struct.Iter.html). Both types already offer `fn as_slice(&self) -> &[T]`, this just adds the trait impl for `vec::IntoIter`.

If/when `fn as_slice(&self) -> &[T]` stabilizes for `vec::Drain` and `slice::IterMut`, they should get `AsRef<[T]>` impls as well. As thus, tangentially related to rust-lang#58957.

My ultimate goal here: being able to use `for<T, I: Iterator<Item=T> + AsRef<[T]>> I` to refer to `vec::IntoIter`, `vec::Drain`, and eventually `array::IntoIter`, as an approximation of the set of by-value iterators that can be "previewed" as by-ref iterators. (Actually expressing that as a trait requires GAT.)
…r=steveklabnik

Fix documentation example for gcov profiling

closes rust-lang#72546
Improves the documentation for the unstable Rustflag `-Zprofile` by:
- stating that Incremental compilation must be turned off.
- Adding the other `RUSTFLAGS` that should/need to be turned on (taken from [grcov documentation](https://github.com/mozilla/grcov#example-how-to-generate-gcda-files-for-a-rust-project))
- Mentioning `RUSTC_WRAPPER` to prevent everything getting instrumented.

r? @steveklabnik
…an-DPC

Added the documentation for the 'use' keyword

This is a partial fix of rust-lang#34601.

I heavily inspired myself from the Reference on the `use` keyword.

I checked the links when compiling the documentation, they should be ok.

I also added an example for the wildcard `*` in the case of types, because it's behaviour is not *import everything* like one might think at first.
…rochenkov

Add `-Z span-debug` to allow for easier debugging of proc macros

Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.

This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once rust-lang#72618 is merged, this will start displaying
actual line numbers.

While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
Liballoc impl

Mainly code rearrangements
…olnay

Cstring `from_raw` and `into_raw` safety precisions

Fixes rust-lang#48525.
Fixes rust-lang#68456.

This issue had two points:

- The one about `from_raw` has been addressed (I hope).
- The other one, about `into_raw`, has only been partially fixed.

About `into_raw`: the idea was to:

> steer users away from using the pattern of CString::{into_raw,from_raw} when interfacing with C APIs that may change the effective length of the string by writing interior NULs or erasing the final NUL

I tried making a `Vec<c_char>` like suggested but my current solution feels very unsafe and *hacky* to me (most notably the type cast), I included it here to make it available for discussion:

```rust
fn main() {
    use std::os::raw::c_char;

    let v = String::from("abc")
        .bytes()
        // From u8 to i8,
        // I feel like it will be a problem for values of u8 > 255
        .map(|c| c as c_char)
        .collect::<Vec<_>>();

    dbg!(v);
}
```
Free `default()` forwarding to `Default::default()`

It feels a bit redundant to have to say `Default::default()` every time I need a new value of a type that has a `Default` instance.
Especially so, compared to Haskell, where the same functionality is called `def`.
Providing a free `default()` function that forwards to `Default::default()` seems to improve the situation.
The trait is still there, so if someone wants to be explicit and to say `Default::default()` - it still works, but if imported as `std::default::default;`, then the free function reduces typing and visual noise.
@RalfJung
Copy link
Member Author

RalfJung commented Jun 8, 2020

@rustbot modify labels: +rollup
@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Jun 8, 2020

📌 Commit 7983e56 has been approved by RalfJung

@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 Jun 8, 2020
@bors
Copy link
Contributor

bors commented Jun 8, 2020

⌛ Testing commit 7983e56 with merge 6e18df9d01e21805b9922ecbac6c6e52d9fa3634...

@bors
Copy link
Contributor

bors commented Jun 8, 2020

💥 Test timed out

@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 Jun 8, 2020
@Dylan-DPC-zz
Copy link

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 8, 2020
@RalfJung
Copy link
Member Author

RalfJung commented Jun 8, 2020

Cc @rust-lang/infra second timeout I am seeing in 24h... (the other one is #72904 (comment))

@bors
Copy link
Contributor

bors commented Jun 8, 2020

⌛ Testing commit 7983e56 with merge bf2f79e6554e9a4b8e05e572b2f821a5dc48e71d...

@marmeladema
Copy link
Contributor

@Dylan-DPC-zz
Copy link

looks like one of the normal failures we receive once in a while

@marmeladema
Copy link
Contributor

@RalfJung
Copy link
Member Author

RalfJung commented Jun 8, 2020

Strange, it said "Build completed successfully in 2:13:42" already more than 1h ago, and then stopped.

@Dylan-DPC-zz
Copy link

Dylan-DPC-zz commented Jun 8, 2020

looks like another timeout.. (normal merge takes 3h 15 mins approx)

@bors
Copy link
Contributor

bors commented Jun 8, 2020

💥 Test timed out

@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 Jun 8, 2020
@RalfJung
Copy link
Member Author

RalfJung commented Jun 8, 2020

There we go.
@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 8, 2020
@bors
Copy link
Contributor

bors commented Jun 8, 2020

⌛ Testing commit 7983e56 with merge bc10b68...

@bors
Copy link
Contributor

bors commented Jun 8, 2020

☀️ Test successful - checks-azure
Approved by: RalfJung
Pushing bc10b68 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 8, 2020
@bors bors merged commit bc10b68 into rust-lang:master Jun 8, 2020
@RalfJung RalfJung deleted the rollup-jecowhz branch June 10, 2020 07:40
@cuviper cuviper added this to the 1.46 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.