-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Rollup of 12 pull requests #77381
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
…plett Rename AllocErr to AllocError Implements rust-lang/wg-allocators#57
…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
@bors r+ rollup=never p=5 |
📌 Commit 85e77ed has been approved by |
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
☀️ Test successful - checks-actions, checks-azure |
This was referenced Oct 1, 2020
This rollup caused a very large regression in instruction counts on full builds of Investigating in #77601 |
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.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
TooGeneric
handling #77303 (const evaluatable: improveTooGeneric
handling)const_item_mutation
lint on writes through a pointer #77324 (Don't fireconst_item_mutation
lint on writes through a pointer)rustc_args_required_const
#77343 (Validaterustc_args_required_const
)Failed merges:
r? @ghost