Skip to content

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
Collaborator

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
Collaborator

bors commented Mar 19, 2017

📌 Commit f2d0a1d has been approved by arielb1

@bors
Copy link
Collaborator

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
Collaborator

bors commented Mar 19, 2017

💔 Test failed - status-travis

@bors
Copy link
Collaborator

bors commented Mar 19, 2017

⌛ Testing commit f2d0a1d with merge c76f7c6...

@bors
Copy link
Collaborator

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.