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 8 pull requests #40647

Closed
wants to merge 29 commits into from
Closed

Rollup of 8 pull requests #40647

wants to merge 29 commits into from

Conversation

jseyfried and others added 29 commits March 14, 2017 03:35
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.
This removes the duplication between collector, callee, and (eventually)
MIRI.
…R shim

These changes are in the same commit to avoid needing to adapt
meth::trans_object_shim to the new scheme.

One codegen-units test is broken because we instantiate the shims even
when they are not needed. This will be fixed in the next PR.
This avoids the creation of unneeded vtable shims.
Drop of arrays is now translated in trans::block in an ugly way that I
should clean up in a later PR, and does not handle panics in the middle
of an array drop, but this commit & PR are growing too big.
Translate shims using MIR

Still a work in progress.
Change how the `0` flag works in format!

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.

Here's a short summary of how similar format strings work in Python and Rust:

```
              :05     :<05    :>05    :^05
Python 3.6  |-0001| |-1000| |000-1| |0-100|
Rust before |-0001| |-1000| |-0001| |-0100|
Rust after  |-0001| |-0001| |-0001| |-0001|

             :#05x   :<#05x  :>#05x  :^#05x
Python 3.6  |0x001| |0x100| |000x1| |00x10|
Rust before |0x001| |0x100| |000x1| |0x010|
Rust after  |0x001| |0x001| |0x001| |0x001|
```

Fixes rust-lang#39997 [breaking-change]
…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
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.
@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (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.

@frewsxcv
Copy link
Member Author

@bors r+ p=10

@bors
Copy link
Contributor

bors commented Mar 19, 2017

📌 Commit 6c95ac0 has been approved by frewsxcv

@bors
Copy link
Contributor

bors commented Mar 19, 2017

⌛ Testing commit 6c95ac0 with merge 6c891d5...

@bors
Copy link
Contributor

bors commented Mar 19, 2017

💔 Test failed - status-appveyor

@arielb1
Copy link
Contributor

arielb1 commented Mar 19, 2017

odd stage1 error:

   Compiling rustc v0.0.0 (file:///C:/projects/rust/src/librustc)
error: Could not compile `rustc`.

@arielb1
Copy link
Contributor

arielb1 commented Mar 19, 2017

@bors retry

Let's see if this repeats

@arielb1
Copy link
Contributor

arielb1 commented Mar 19, 2017

Confirming LLVM assertion.

@arielb1 arielb1 closed this Mar 19, 2017
@frewsxcv frewsxcv deleted the rollup branch March 19, 2017 13:19
@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.