Rollup of 10 pull requests #73115
Merged
Rollup of 10 pull requests #73115
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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<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.
Add comments to `Resolve::get_module` r? @Manishearth
…an-DPC Clean up E0646 r? @Dylan-DPC
|
📌 Commit 7983e56 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 7983e56 with merge 6e18df9d01e21805b9922ecbac6c6e52d9fa3634... |
|
💥 Test timed out |
bors
added
S-waiting-on-review
|
@bors retry |
bors
added
S-waiting-on-bors
|
Cc @rust-lang/infra second timeout I am seeing in 24h... (the other one is #72904 (comment)) |
|
⌛ Testing commit 7983e56 with merge bf2f79e6554e9a4b8e05e572b2f821a5dc48e71d... |
|
FYI, it was making progress, albeit rather slowly: https://dev.azure.com/rust-lang/rust/_build/results?buildId=31399&view=logs&j=fd0bd97c-dca3-5d16-5976-7c3893e4446f&t=3fc0f2c0-6393-5fc1-7bce-c70c707d4d26 |
|
looks like one of the normal failures we receive once in a while |
|
All builds have finished except https://dev.azure.com/rust-lang/rust/_build/results?buildId=31422&view=logs&j=77fe58e7-c26b-56af-861c-0e6795721952&t=28b6fc66-4f34-5b10-ad6a-df15d8bbc116 which seems blocked on completion. |
|
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) |
|
💥 Test timed out |
bors
added
S-waiting-on-review
|
There we go. |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-azure |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
-Z span-debugto allow for easier debugging of proc macros #72799 (Add-Z span-debugto allow for easier debugging of proc macros)from_rawandinto_rawsafety precisions #72963 (Cstringfrom_rawandinto_rawsafety precisions)default()forwarding toDefault::default()#73001 (Freedefault()forwarding toDefault::default())Resolve::get_module#73075 (Add comments toResolve::get_module)Failed merges:
r? @ghost