Skip to content

Rollup of 21 pull requests - #40645

Closed
arielb1 wants to merge 66 commits into
rust-lang:masterfrom
arielb1:rollup
Closed

Rollup of 21 pull requests#40645
arielb1 wants to merge 66 commits into
rust-lang:masterfrom
arielb1:rollup

Conversation

estebankand others added 30 commits March 11, 2017 14:28
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`".
It does not seem valuable to always evaluate the right-hand side here.
Adds a test for issue rust-lang#31946 which was fixed a while ago.
Also update some 128 bit builtins to be panic-free without relying
on the const evaluator.
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|
Fixesrust-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|
…[macro_reexport]`)
and macros 2.0 exports (`pub use` macro re-exports and `pub macro` (once implemented)
at the crate root.
This seems to match other uses of "be accessed" in the document.
Ariel Ben-Yehuda added 6 commits March 19, 2017 02:16
…orts, r=nrc
Forbid conflicts between macros 1.0 exports and macros 2.0 exports
This PR forbids for conflicts between `#[macro_export]`/`#[macro_reexport]` macro exports and `pub use` macro exports. For example,
```rust
// crate A:
pub use macros::foo;
//^ This is allowed today, will be forbidden by this PR.
// crate B:
extern crate A; // This triggers a confusing error today.
use A::foo; // This could refer to refer to either macro export in crate A.
```
r? @nrc
Implemente overflowing_sh* with new unchecked_sh* intrinsics
Also update some 128 bit builtins to not rely on the constant evaluator to avoid checked operations.
Fixesrust-lang#40508.
cc @nagisa, @alexcrichton
Note: I still have a build running to see if the 128 bit changes worked (unoptimized builds take *forever* to compile), however at least the overflowing builtins no longer reference `core::panicking::panic`.
add test for nested macro def (rust-lang#31946)
Adds a test for issue rust-lang#31946 which was fixed in 1.12.0.
Closesrust-lang#31946.
…r, r=nrc
macros: improve the `TokenStream` quoter
This PR
- renames the `TokenStream` quoter from `qquote!` to `quote!`,
- uses `$` instead of `unquote` (e.g. `let toks: TokenStream = ...; quote!([$toks])`),
- allows unquoting `Token`s as well as `TokenTree`s and `TokenStream`s (fixesrust-lang#39746), and
- to preserve syntactic space, requires that `$` be followed by
- a single identifier to unquote, or
- another `$` to produce a literal `$`.
r? @nrc
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
…wsxcv
Fix const not displayed in rustdoc
Fixesrust-lang#40331.
r? @rust-lang/docs
@arielb1arielb1 reopened this Mar 19, 2017
Ariel Ben-Yehuda added 5 commits March 19, 2017 02:16
…ion, r=nrc
macros: fix regression with `include!()`
Fixesrust-lang#40469, a regression when `include!()`ing a `macro_rules!` containing `$crate`.
r? @nrc
… r=nagisa
Parse 0e+10 as a valid floating-point literal
Fixes issue rust-lang#40408.
documented order of conversion between u32 an ipv4addr
This fixesrust-lang#40118
@arielb1

Copy link
Copy Markdown
ContributorAuthor

@bors r+ p=1000

Represent function pointers in mir-constants as a Value instead of Item
r? @eddyb
@bors

bors commented Mar 19, 2017

Copy link
Copy Markdown
Collaborator

📌 Commit d3e5a45 has been approved by arielb1

Ariel Ben-Yehuda added 3 commits March 19, 2017 02:17
…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.
@arielb1

Copy link
Copy Markdown
ContributorAuthor

@bors r+

@bors

bors commented Mar 19, 2017

Copy link
Copy Markdown
Collaborator

📌 Commit f2d0a1d has been approved by arielb1

@bors

bors commented Mar 19, 2017

Copy link
Copy Markdown
Collaborator

⌛ Testing commit f2d0a1d with merge 079cdd8...

@arielb1

Copy link
Copy Markdown
ContributorAuthor

@bors retry

@bors

bors commented Mar 19, 2017

Copy link
Copy Markdown
Collaborator

💔 Test failed - status-travis

@bors

bors commented Mar 19, 2017

Copy link
Copy Markdown
Collaborator

⌛ Testing commit f2d0a1d with merge c76f7c6...

@bors

bors commented Mar 19, 2017

Copy link
Copy Markdown
Collaborator

💔 Test failed - status-appveyor

@arielb1

Copy link
Copy Markdown
ContributorAuthor
{"message":"linking with `link.exe` failed: exit code: 1120","code":null,"level":"error","spans":[],"children":[{"message":"\"C:\\\\Program Files (x86)\\\\Microsoft Visual Studio 14.0\\\\VC\\\\bin\\\\amd64\\\\link.exe\" \"/LIBPATH:C:\\\\Program Files (x86)\\\\Microsoft Visual Studio 14.0\\\\VC\\\\lib\\\\amd64\" \"/LIBPATH:C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\lib\\\\10.0.14393.0\\\\ucrt\\\\x64\" \"/LIBPATH:C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\lib\\\\10.0.14393.0\\\\um\\\\x64\" \"/NOLOGO\" \"/NXCOMPAT\" \"/LIBPATH:C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\test\\\\run-pass\\\\allocator-override.0.o\" \"/OUT:C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\test\\\\run-pass\\\\allocator-override.stage2-x86_64-pc-windows-msvc.exe\" \"/OPT:REF,ICF\" \"/DEBUG\" \"/LIBPATH:C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\test\\\\run-pass\" \"/LIBPATH:C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\test\\\\run-pass\\\\allocator-override.stage2-x86_64-pc-windows-msvc.run-pass.libaux\" \"/LIBPATH:C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\native\\\\rust-test-helpers\" \"/LIBPATH:C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libtest-4395313c6149eab1.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libterm-94eca2ffe2bbb128.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libgetopts-43e5e3367717c4c8.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libstd-0a78323911070f99.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libpanic_unwind-2d4bf02140c11dcb.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libunwind-add7a84d7e82d084.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\librand-c279a51d66700350.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libcollections-d7bf31a4ca1ea637.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\liballoc-fe2e68b21f0bdd7a.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\test\\\\run-pass\\\\allocator-override.stage2-x86_64-pc-windows-msvc.run-pass.libaux\\\\liballocator_dummy.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\liblibc-84688accbc86d6b7.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libstd_unicode-d367c3ba0db49600.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libcore-ea9d77e7c23fe65c.rlib\" \"C:\\\\projects\\\\rust\\\\build\\\\x86_64-pc-windows-msvc\\\\stage2\\\\lib\\\\rustlib\\\\x86_64-pc-windows-msvc\\\\lib\\\\libcompiler_builtins-91b619d34dd1f5aa.rlib\" \"kernel32.lib\" \"advapi32.lib\" \"ws2_32.lib\" \"userenv.lib\" \"shell32.lib\" \"msvcrt.lib\"","code":null,"level":"note","spans":[],"children":[],"rendered":null},{"message":"libstd-0a78323911070f99.rlib(std-0a78323911070f99.0.o) : error LNK2019: unresolved external symbol __rust_allocate_zeroed referenced in function _ZN3std2io5stdio5stdin10stdin_init17h2e36844a715f1136E\r\nC:\\projects\\rust\\build\\x86_64-pc-windows-msvc\\test\\run-pass\\allocator-override.stage2-x86_64-pc-windows-msvc.exe : fatal error LNK1120: 1 unresolved externals\r\n","code":null,"level":"note","spans":[],"children":[],"rendered":null}],"rendered":null}
{"message":"aborting due to previous error","code":null,"level":"error","spans":[],"children":[],"rendered":null}
------------------------------------------

@arielb1arielb1 closed this Mar 19, 2017
@CentrilCentril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rollupA PR which is a rollup

Projects

None yet

Development

Successfully merging this pull request may close these issues.

20 participants

@arielb1@rust-highfive@bors@nikomatsakis@Centril@estebank@ahicks92@jseyfried@tbg@durka@TimNN@Sawyer47@GuillaumeGomez@topecongiro@oli-obk@QuietMisdreavus@ScottAbbey@aturon@alexcrichton@mbrubeck