Rollup of 10 pull requests by RalfJung · Pull Request #73115 · rust-lang/rust (original) (raw)

Successful merges:

Update annotate-snippets-rs to 0.8.0 #72026 (Update annotate-snippets-rs to 0.8.0)
impl AsRef<[T]> for vec::IntoIter #72583 (impl AsRef<[T]> for vec::IntoIter)
Fix documentation example for gcov profiling #72615 (Fix documentation example for gcov profiling)
Added the documentation for the 'use' keyword #72761 (Added the documentation for the 'use' keyword)
Add -Z span-debug to allow for easier debugging of proc macros #72799 (Add -Z span-debug to allow for easier debugging of proc macros)
Liballoc impl #72811 (Liballoc impl)
Cstring from_raw and into_raw safety precisions #72963 (Cstring from_raw and into_raw safety precisions)
Free default() forwarding to Default::default() #73001 (Free default() forwarding to Default::default())
Add comments to Resolve::get_module #73075 (Add comments to Resolve::get_module)
Clean up E0646 #73092 (Clean up E0646)

Failed merges:

r? @ghost

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 bastian_kauschke@hotmail.de

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

Adds impl<T> AsRef<[T]> for vec::IntoIter<T>. This mirrors the same trait impl for slice::Iter. 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.)

…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

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:

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.

📌 Commit 7983e56 has been approved by RalfJung

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

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

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

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

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

⌛ Testing commit 7983e56 with merge bf2f79e6554e9a4b8e05e572b2f821a5dc48e71d...

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

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

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

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

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 mentioned this pull request

Jun 8, 2020