Rollup of 20 pull requests #40643
Closed
Rollup of 20 pull requests #40643
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
Point at the immutable local variable when trying to modify one of its
fields.
Given a file:
```rust
struct Foo {
pub v: Vec<String>
}
fn main() {
let f = Foo { v: Vec::new() };
f.v.push("cat".to_string());
}
```
present the following output:
```
error: cannot borrow immutable field `f.v` as mutable
--> file.rs:7:13
|
6 | let f = Foo { v: Vec::new() };
| - this should be `mut`
7 | f.v.push("cat".to_string());
| ^^^
error: aborting due to previous error
```
Change the wording of mutable borrow on immutable binding from "this should be `mut`" to "consider changing this to `mut f`".
…uct field reordering.
It does not seem valuable to always evaluate the right-hand side here.
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.
:05 :<05 :>05 :^05
before |-0001| |-1000| |-0001| |-0100|
after |-0001| |-0001| |-0001| |-0001|
:#05x :<#05x :>#05x :^#05x
before |0x001| |0x100| |000x1| |0x010|
after |0x001| |0x001| |0x001| |0x001|
Fixes rust-lang#39997 [breaking-change]
Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`.
:06 :<06 :>06 :^06
before |-001.2| |-1.200| |-001.2| |-01.20|
after |-001.2| |-001.2| |-001.2| |-001.2|
Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err". See rust-lang#33417 (comment). TryFrom<&str> and FromStr are equivalent, so have the latter provide the former to ensure that. Using TryFrom in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to suggest implementing `TryFrom<&str>` instead for new code. See rust-lang#33417 (comment) and rust-lang#33417 (comment). Refs rust-lang#33417.
This seems to match other uses of "be accessed" in the document.
…uron Rename TryFrom's associated type and implement str::parse using TryFrom. Per discussion on the tracking issue, naming `TryFrom`'s associated type `Error` is generally more consistent with similar traits in the Rust ecosystem, and what people seem to assume it should be called. It also helps disambiguate from `Result::Err`, the most common "Err". See rust-lang#33417 (comment). `TryFrom<&str>` and `FromStr` are equivalent, so have the latter provide the former to ensure that. Using `TryFrom` in the implementation of `str::parse` means types that implement either trait can use it. When we're ready to stabilize `TryFrom`, we should update `FromStr` to suggest implementing `TryFrom<&str>` instead for new code. See rust-lang#33417 (comment) and rust-lang#33417 (comment). Refs rust-lang#33417.
…, r=nrc `TokenStream`-based attributes, paths in attribute and derive macro invocations This PR - refactors `Attribute` to use `Path` and `TokenStream` instead of `MetaItem`. - supports macro invocation paths for attribute procedural macros. - e.g. `#[::foo::attr_macro] struct S;`, `#[cfg_attr(all(), foo::attr_macro)] struct S;` - supports macro invocation paths for derive procedural macros. - e.g. `#[derive(foo::Bar, super::Baz)] struct S;` - supports arbitrary tokens as arguments to attribute procedural macros. - e.g. `#[foo::attr_macro arbitrary + tokens] struct S;` - supports using arbitrary tokens in "inert attributes" with derive procedural macros. - e.g. `#[derive(Foo)] struct S(#[inert arbitrary + tokens] i32);` where `#[proc_macro_derive(Foo, attributes(inert))]` r? @nrc
Remove internal liblog
This commit deletes the internal liblog in favor of the implementation that
lives on crates.io. Similarly it's also setting a convention for adding crates
to the compiler. The main restriction right now is that we want compiler
implementation details to be unreachable from normal Rust code (e.g. requires a
feature), and by default everything in the sysroot is reachable via `extern
crate`.
The proposal here is to require that crates pulled in have these lines in their
`src/lib.rs`:
#![cfg_attr(rustbuild, feature(staged_api, rustc_private))]
#![cfg_attr(rustbuild, unstable(feature = "rustc_private", issue = "27812"))]
This'll mean that by default they're not using these attributes but when
compiled as part of the compiler they do a few things:
* Mark themselves as entirely unstable via the `staged_api` feature and the
`#![unstable]` attribute.
* Allow usage of other unstable crates via `feature(rustc_private)` which is
required if the crate relies on any other crates to compile (other than std).
Handle extern functions and statics in save-analysis r? @eddyb
Implement optimization fuel and re-enable struct field reordering See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background. This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate. It also turns field reordering back on. There is no way to test this feature without something consuming fuel. We can roll this back if we want, but then the optimization fuel bits will be dead code. The one notable absence from this PR is a test case. I'm not sure how to do one that's worth having. The only thing I can think of to test is `-Z fuel=foo=0`. The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed. If someone has a useful proposal for a good test, I certainly want to add one.
Propagate expected type hints through struct literals. Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to. The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`. *However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported. r? @nikomatsakis
Specialize Vec::from_elem to use calloc Fixes rust-lang#38723. This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired. I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux. (I have not tested or even built the Windows code.)
Add feature gate for rvalue-static-promotion Probably needs more tests (which ones?) and there may be other things that need to be done. Also not sure whether the version that introduces the flag is really `1.15.1`. See rust-lang/rfcs#1414. Updates rust-lang#38865.
…rner
Point to let when modifying field of immutable variable
Point at the immutable local variable when trying to modify one of its
fields.
Given a file:
```rust
struct Foo {
pub v: Vec<String>
}
fn main() {
let f = Foo { v: Vec::new() };
f.v.push("cat".to_string());
}
```
present the following output:
```
error: cannot borrow immutable field `f.v` as mutable
--> file.rs:7:13
|
6 | let f = Foo { v: Vec::new() };
| - this should be `mut`
7 | f.v.push("cat".to_string());
| ^^^
error: aborting due to previous error
```
Fix rust-lang#27593.
Library stabilizations for 1.17 Details of the stabilizations are available in the commits. Includes only library stabilizations; there are a couple of compiler stabilizations that should also be done for 1.17. Will need a beta backport, which I will create after approval. r? @alexcrichton
Remove unused param from bootstrap::clean::rm_rf None
…wsxcv Fix const not displayed in rustdoc Fixes rust-lang#40331. r? @rust-lang/docs
[LLVM 4.0] Add missing debuginfo metadata to globals Fixes rust-lang#40580. cc @rkruppe cc rust-lang#40123
…ion, r=nrc macros: fix regression with `include!()` Fixes rust-lang#40469, a regression when `include!()`ing a `macro_rules!` containing `$crate`. r? @nrc
documented order of conversion between u32 an ipv4addr This fixes rust-lang#40118
…uillaumeGomez
minor wording tweak to slice::{as_ptr, as_mut_ptr}
Per rust-lang#37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated.
r? @steveklabnik
Fix typo in mutex.rs docs This seems to match other uses of "be accessed" in the document.
…sfackler Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision Noticed while reading docs just now. It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess. But unless there's an API guarantee that this is the case, the wording seems over-precise. Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction? I don't think the quality of output in that case would depend on when the RNG was created. Yet it seems to me like it could well be a valid source of randomness when computing the initial seed. For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining. That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.
|
@bors r+ p=10 |
|
📌 Commit 6b92bd6 has been approved by |
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
⌛ Testing commit 6b92bd6 with merge d5f4f2f... |
|
💔 Test failed - status-appveyor |
|
Actual failure: |
|
#40347 has this error on travis. Please don't rollup PRs that are red on travis. |
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.
0flag works in format! #40241, Rename TryFrom's associated type and implement str::parse using TryFrom. #40281,TokenStream-based attributes, paths in attribute and derive macro invocations #40346, Remove internal liblog #40347, Handle extern functions and statics in save-analysis #40348, Implement optimization fuel and re-enable struct field reordering #40377, Propagate expected type hints through struct literals. #40398, Specialize Vec::from_elem to use calloc #40409, Add feature gate for rvalue-static-promotion #40441, Point to let when modifying field of immutable variable #40445, Library stabilizations for 1.17 #40538, Remove unused param from bootstrap::clean::rm_rf #40562, Fix const not displayed in rustdoc #40564, [LLVM 4.0] Add missing debuginfo metadata to globals #40581, macros: fix regression withinclude!()#40583, documented order of conversion between u32 an ipv4addr #40590, minor wording tweak to slice::{as_ptr, as_mut_ptr} #40603, Fix typo in mutex.rs docs #40611, Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision #40621