Skip to content
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 21 pull requests #40645

Closed
wants to merge 66 commits into from
Closed

Rollup of 21 pull requests #40645

wants to merge 66 commits into from

Conversation

estebank and 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|

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|
…[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.

Fixes rust-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.

Closes rust-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 (fixes rust-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

Fixes rust-lang#40331.

r? @rust-lang/docs
@arielb1 arielb1 reopened this Mar 19, 2017
Ariel Ben-Yehuda added 5 commits March 19, 2017 02:16
[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
… 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 fixes rust-lang#40118
@arielb1
Copy link
Contributor Author

arielb1 commented Mar 19, 2017

@bors r+ p=1000

Represent function pointers in mir-constants as a Value instead of Item

r? @eddyb
@bors
Copy link
Contributor

bors commented Mar 19, 2017

📌 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
Contributor Author

arielb1 commented Mar 19, 2017

@bors r+

@bors
Copy link
Contributor

bors commented Mar 19, 2017

📌 Commit f2d0a1d has been approved by arielb1

@bors
Copy link
Contributor

bors commented Mar 19, 2017

⌛ Testing commit f2d0a1d with merge 079cdd8...

@arielb1
Copy link
Contributor Author

arielb1 commented Mar 19, 2017

@bors retry

@bors
Copy link
Contributor

bors commented Mar 19, 2017

💔 Test failed - status-travis

@bors
Copy link
Contributor

bors commented Mar 19, 2017

⌛ Testing commit f2d0a1d with merge c76f7c6...

@bors
Copy link
Contributor

bors commented Mar 19, 2017

💔 Test failed - status-appveyor

@arielb1
Copy link
Contributor Author

arielb1 commented Mar 19, 2017

{"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}
------------------------------------------

@arielb1 arielb1 closed this Mar 19, 2017
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup
Projects
None yet
Development

Successfully merging this pull request may close these issues.