-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Rollup of 10 pull requests #73115
Conversation
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.
Add comments to `Resolve::get_module` r? @Manishearth
…an-DPC Clean up E0646 r? @Dylan-DPC
📌 Commit 7983e56 has been approved by |
⌛ Testing commit 7983e56 with merge 6e18df9d01e21805b9922ecbac6c6e52d9fa3634... |
💥 Test timed out |
@bors retry |
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 |
There we go. |
☀️ Test successful - checks-azure |
Successful merges:
-Z span-debug
to allow for easier debugging of proc macros #72799 (Add-Z span-debug
to allow for easier debugging of proc macros)from_raw
andinto_raw
safety precisions #72963 (Cstringfrom_raw
andinto_raw
safety precisions)default()
forwarding toDefault::default()
#73001 (Freedefault()
forwarding toDefault::default()
)Resolve::get_module
#73075 (Add comments toResolve::get_module
)Failed merges:
r? @ghost