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 12 pull requests #77381

Merged
merged 27 commits into from
Oct 1, 2020
Merged

Rollup of 12 pull requests #77381

merged 27 commits into from
Oct 1, 2020

Conversation

Dylan-DPC-zz
Copy link

Successful merges:

Failed merges:

r? @ghost

timvermeulen and others added 27 commits September 20, 2020 16:14
I misunderstood how this works, and I have fixed the linux builds
to support ios/tvos.
Makes progress towards rust-lang#43081

In PR rust-lang#73084, we started recursively expanded nonterminals during the
pretty-print/reparse check, allowing them to be properly compared
against the reparsed tokenstream.

Unfortunately, the recursive logic in that PR only handles the case
where a nonterminal appears inside a `TokenTree::Delimited`. If a
nonterminal appears directly in the expanded tokens of another
nonterminal, the inner nonterminal will not be expanded.

This PR fixes the recursive expansion of nonterminals, ensuring that
they are expanded wherever they occur.
SipHasher128 implements short_write in an endian-independent way, yet
its write_xxx Hasher trait methods undo this endian-independence by byte
swapping the integer inputs on big-endian hardware. StableHasher then
adds endian-independence back by also byte-swapping on big-endian
hardware prior to invoking SipHasher128.

This double swap may have the appearance of being a no-op, but is in
fact by design. In particular, we really do want SipHasher128 to be
platform-dependent, in order to be consistent with the libstd SipHasher.
Try to clarify this intent. Also, add and update a couple of unit tests.
Add Iterator::advance_by and DoubleEndedIterator::advance_back_by

This PR adds the iterator method

```rust
fn advance_by(&mut self, n: usize) -> Result<(), usize>
```

that advances the iterator by `n` elements, returning `Ok(())` if this succeeds or `Err(len)` if the length of the iterator was less than `n`.

Currently `Iterator::nth` is the method to override for efficiently advancing an iterator by multiple elements at once. `advance_by` is superior for this purpose because
- it's simpler to implement: instead of advancing the iterator and producing the next element you only need to advance the iterator
- it composes better: iterators like `Chain` and `FlatMap` can implement `advance_by` in terms of `advance_by` on their inner iterators, but they cannot implement `nth` in terms of `nth` on their inner iterators (see rust-lang#60395)
- the default implementation of `nth` can trivially be implemented in terms of `advance_by` and `next`, which this PR also does

This PR also adds `DoubleEndedIterator::advance_back_by` for all the same reasons.

I'll make a tracking issue if it's decided this is worth merging. Also let me know if anything can be improved, this went through several iterations so there might very well still be room for improvement (especially in the doc comments). I've written overrides of these methods for most iterators that already override `nth`/`nth_back`, but those still need tests so I'll add them in a later PR.

cc @cuviper @scottmcm @Amanieu
…nd, r=petrochenkov

Fix recursive nonterminal expansion during pretty-print/reparse check

Makes progress towards rust-lang#43081

In PR rust-lang#73084, we started recursively expanded nonterminals during the
pretty-print/reparse check, allowing them to be properly compared
against the reparsed tokenstream.

Unfortunately, the recursive logic in that PR only handles the case
where a nonterminal appears inside a `TokenTree::Delimited`. If a
nonterminal appears directly in the expanded tokens of another
nonterminal, the inner nonterminal will not be expanded.

This PR fixes the recursive expansion of nonterminals, ensuring that
they are expanded wherever they occur.
…henkov

Defer Apple SDKROOT detection to link time.

This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time, instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster.

This also removes the note in the platform support documentation about these targets being missing. When I wrote it, I misunderstood how the SDKROOT stuff worked.

Notes:
* This means that JSON spec targets can't explicitly override these flags. I think that is probably fine, as I believe the value is generally required, and can be set with the SDKROOT environment variable.
* This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also, `x86_64-apple-tvos` seems broken in general, and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps, but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements).
* I'm tempted to remove the use of `Result` for built-in target definitions, since I don't think they should be fallible. This was added in rust-lang#34980, but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now, or not.

Fixes rust-lang#36156
Fixes rust-lang#76584
…r=oli-obk,varkor

const evaluatable: improve `TooGeneric` handling

Instead of emitting an error in `fulfill`, we now correctly stall on inference variables.

As `const_eval_resolve` returns `ErrorHandled::TooGeneric` when encountering generic parameters on which
we actually do want to error, we check for inference variables and eagerly emit an error if they don't exist, returning `ErrorHandled::Reported` instead.

Also contains a small bugfix for `ConstEquate` where we previously only stalled on type variables. This is probably a leftover from
when we did not yet support stalling on const inference variables.

r? @oli-obk cc @varkor @eddyb
…avidtwco

move candidate_from_obligation_no_cache

It's only called from `candidate_from_obligation` which is already in this file.
…r=nnethercote

Stable hashing: add comments and tests concerning platform-independence

SipHasher128 implements short_write in an endian-independent way, yet
its write_xxx Hasher trait methods undo this endian-independence by byte
swapping the integer inputs on big-endian hardware. StableHasher then
adds endian-independence back by also byte-swapping on big-endian
hardware prior to invoking SipHasher128.

This double swap may have the appearance of being a no-op, but is in
fact by design. In particular, we really do want SipHasher128 to be
platform-dependent, in order to be consistent with the libstd SipHasher.
Try to clarify this intent. Also, add and update a couple of unit tests.

---

Previous commit text:

~SipHasher128: fix platform-independence confusion~

~StableHasher is supposed to ensure platform independence by converting
integers to little-endian and extending isize and usize to 64 bits as
necessary, but in fact, much of that work is already handled by
SipHasher128.~

~In particular, SipHasher128 implements short_write in an
endian-independent way, yet both StableHasher and SipHasher128
additionally attempt to achieve endian-independence by byte swapping on
BE hardware before invoking short writes. This double swap has no
effect, so let's remove it.~

~Because short_write is endian-independent, SipHasher128 is already
handling part of the platform-independence, and it would be somewhat
difficult to make it *not* handle that part with the current
implementation. As splitting platform-independence responsibilities
between StableHasher and SipHasher128 would be confusing, let's make
SipHasher128 handle all of it.~

~Finally, update some incorrect comments and increase test coverage.
Unit tests pass on both LE and BE systems.~
…tr, r=petrochenkov

Don't fire `const_item_mutation` lint on writes through a pointer

Fixes rust-lang#77321
…lidation, r=lcnr

Validate `rustc_args_required_const`

Fixes rust-lang#74608.
Update cargo

8 commits in 05c611ae3c4255b7a2bcf4fcfa65b20286a07839..75615f8e69f748d7ef0df7bc0b064a9b1f5c78b2
2020-09-23 23:10:38 +0000 to 2020-09-29 18:42:19 +0000
- Correct mistake about supporting sub-makes and document CARGO_MAKEFLAGS (rust-lang/cargo#8741)
- Properly set for_host for proc-macro tests. (rust-lang/cargo#8742)
- Add Zsh completion for target triples (rust-lang/cargo#8740)
- Reinitialize index on "Object not found" error. (rust-lang/cargo#8735)
- Normalize raw string indentation. (rust-lang/cargo#8739)
- Update links to rustup docs. (rust-lang/cargo#8738)
- Add contributor guide. (rust-lang/cargo#8715)
- Fix minor error in `cargo update` docs. (rust-lang/cargo#8737)
…=RalfJung

References to ZSTs may be at arbitrary aligned addresses

fixes rust-lang#77320

r? @RalfJung
…ostic, r=varkor

Remove trailing space in error message

- Add test for error message
- Remove trailing space in error message
@Dylan-DPC-zz
Copy link
Author

@bors r+ rollup=never p=5

@bors
Copy link
Contributor

bors commented Oct 1, 2020

📌 Commit 85e77ed has been approved by Dylan-DPC

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 1, 2020
@bors
Copy link
Contributor

bors commented Oct 1, 2020

⌛ Testing commit 85e77ed with merge b218b95...

@bors
Copy link
Contributor

bors commented Oct 1, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: Dylan-DPC
Pushing b218b95 to master...

@ecstatic-morse
Copy link
Contributor

This rollup caused a very large regression in instruction counts on full builds of deeply-nested, a stress test of iterator chaining.

Investigating in #77601

@ecstatic-morse
Copy link
Contributor

Confirmed caused by #76909.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet