Uh oh!
There was an error while loading. Please reload this page.
Rollup of 12 pull requests - #76186
Merged
Merged
Conversation
vars() rather than vars function Co-authored-by: Joshua Nelson <joshua@yottadb.com> Use [xxx()] rather than the [xxx] function Co-authored-by: Joshua Nelson <joshua@yottadb.com> Env text representation of function intra-doc link Suggested by @jyn514 Link join_paths in env doc for parity Change xxx to env::xxx for lib env doc Add link requsted by @jyn514 Fix doc build with same link Co-authored-by: Joshua Nelson <joshua@yottadb.com> Fix missing intra-doc link Fix added whitespace in doc Co-authored-by: Joshua Nelson <joshua@yottadb.com> Add brackets for `join_paths` Co-authored-by: Joshua Nelson <joshua@yottadb.com> Use unused link join_paths Removed same link for join_paths Co-authored-by: Joshua Nelson <joshua@yottadb.com> Remove unsed link join_paths
Constify the following methods of `alloc::borrow::Cow`: - `is_borrowed` - `is_owned` These methods are still unstable under `cow_is_borrowed`. Possible because of rust-lang#49146 (Allow if and match in constants). Tracking issue: rust-lang#65143
Fixrust-lang#19599 This confuse people, no trust or not rust? Or not rust no trust? Only trust rust ^^
`parse_stream_from_source_str` is a more stable API to convert a string into a bunch of tokens, and it also catches errors about mismatched parenthesis.
After the recent refactorings, we can actually completely hide this type. It should help with rust-lang#63689.
This was approved by me prematurely. It needs T-libs approval.
The only change is that `expect_file` now uses path relative to the current file (same as `include!`). Before, it used paths relative to the workspace root, which makes no sense.
Similar to the tests for Option and Result.
Found that -C link-dead-code (which was enabled automatically under -Z instrument-coverage) was causing the linking error that resulted in segmentation faults in coverage instrumented binaries. Link dead code is now disabled under MSVC, allowing `-Z instrument-coverage` to be enabled under MSVC for the first time. More details are included in Issue rust-lang#76038. (This PR was broken out from PR rust-lang#75828)
`span.is_empty()` - returns true if `lo()` and `hi()` are equal. This is not only a convenience, but makes it clear that a `Span` can be empty (that is, retrieving the source for an empty `Span` will return an empty string), and codifies the (otherwise undocumented--in the rustc_span package, at least) fact that `Span` is a half-open interval (where `hi()` is the open end). `source_map.lookup_file_span()` - returns an enclosing `Span` representing the start and end positions of the file enclosing the given `BytePos`. This gives developers a clear way to quickly determine if any any other `BytePos` or `Span` is also from the same file (for example, by simply calling `file_span.contains(span)`). This results in much simpler code and is much more runtime efficient compared with the obvious alternative: calling `source_map.lookup_line()` for any two `Span`'s byte positions, handle both arms of the `Result` (both contain the file), and then compare files. It is also more efficient than the non-public method `lookup_source_file_idx()` for each `BytePos`, because, while comparing the internal source file indexes would be efficient, looking up the source file index for every `BytePos` or `Span` to be compared requires a binary search (worst case performance being O(log n) for every lookup). `source_map.lookup_file_span()` performs the binary search only once, to get the `file_span` result that can be used to compare to any number of other `BytePos` or `Span` values and those comparisons are always O(1).
Use `env::func()`, not 'the function env::func' in docs for std::env Follow up of rust-lang#75629 r? @jyn514
…3, r=tmandry Fix `-Z instrument-coverage` on MSVC Found that `-C link-dead-code` (which was enabled automatically under `-Z instrument-coverage`) was causing the linking error that resulted in segmentation faults in coverage instrumented binaries. Link dead code is now disabled under MSVC, allowing `-Z instrument-coverage` to be enabled under MSVC for the first time. More details are included in Issue rust-lang#76038 . Note this PR makes it possible to support `Z instrument-coverage` but does not enable instrument coverage for MSVC in existing tests. It will be enabled in another PR to follow this one (both PRs coming from original PR rust-lang#75828). r? @tmandry FYI: @wesleywiser
…4, r=wesleywiser Adds two source span utility functions used in source-based coverage `span.is_empty()` - returns true if `lo()` and `hi()` are equal. This is not only a convenience, but makes it clear that a `Span` can be empty (that is, retrieving the source for an empty `Span` will return an empty string), and codifies the (otherwise undocumented--in the rustc_span package, at least) fact that `Span` is a half-open interval (where `hi()` is the open end). `source_map.lookup_file_span()` - returns an enclosing `Span` representing the start and end positions of the file enclosing the given `BytePos`. This gives developers a clear way to quickly determine if any any other `BytePos` or `Span` is also from the same file (for example, by simply calling `file_span.contains(span)`). This results in much simpler code and is much more runtime efficient compared with the obvious alternative: calling `source_map.lookup_line()` for any two `Span`'s byte positions, handle both arms of the `Result` (both contain the file), and then compare files. It is also more efficient than the non-public method `lookup_source_file_idx()` for each `BytePos`, because, while comparing the internal source file indexes would be efficient, looking up the source file index for every `BytePos` or `Span` to be compared requires a binary search (worst case performance being O(log n) for every lookup). `source_map.lookup_file_span()` performs the binary search only once, to get the `file_span` result that can be used to compare to any number of other `BytePos` or `Span` values and those comparisons are always O(1). This PR was split out from PR rust-lang#75828 . r? @tmandry FYI: @wesleywiser
…an-DPC,pickfire Clean up E0764 r? @Dylan-DPC
…an-DPC Clean up E0769 r? @pickfire cc @Dylan-DPC
…morse Make `cow_is_borrowed` methods const Constify the following methods of `alloc::borrow::Cow`: - `is_borrowed` - `is_owned` Analogous to the const methods `is_some` and `is_none` for Option, and `is_ok` and `is_err` for Result. These methods are still unstable under `cow_is_borrowed`. Possible because of rust-lang#49146 (Allow if and match in constants). Tracking issue: rust-lang#65143
…n514 Fix rustdoc strings indentation I took the opportunity to clean up our strings indentation a bit because it was a bit messy. r? @jyn514
Remove notrust in rustc_middle Fixrust-lang#19599 This confuse people, no trust or not rust? Or not rust no trust? Only trust rust ^^ Superseeds rust-lang#76063 r? @matklad
README: Adjust Linux and macOS support platform and architecture cc rust-lang#74163
Make `StringReader` private r? @ghostclosesrust-lang#75619
…Jung Revert rust-lang#75463 This was approved by me prematurely. It needs T-libs approval. Sorry @CDirkx. r? @RalfJung
Update expect-test to 1.0 The only change is that `expect_file` now uses path relative to the current file (same as `include!`). Before, it used paths relative to the workspace root, which makes no sense.
tmandry
commented
Sep 1, 2020
MemberAuthor
bors
commented
Sep 1, 2020
Collaborator
📌 Commit 8d328d7 has been approved by |
bors
commented
Sep 1, 2020
Collaborator
⌛ Testing commit 8d328d7 with merge 6f6a972a5dffea7f4612cddc32108e7d96c0e7e3... |
bors
commented
Sep 1, 2020
Collaborator
💔 Test failed - checks-actions |
MemberAuthor
Looks spurious: @bors retry |
bors
commented
Sep 1, 2020
Collaborator
⌛ Testing commit 8d328d7 with merge 795cefaa9965b00cdf326fd8a816ae367425d555... |
bors
commented
Sep 1, 2020
Collaborator
rust-log-analyzer
commented
Sep 1, 2020
Collaborator
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
bors
commented
Sep 1, 2020
Collaborator
☀️ Test successful - checks-actions, checks-azure |
This was referenced Sep 1, 2020
This file contains hidden or 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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
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:
env::func(), not 'the function env::func' in docs for std::env #75945 (Useenv::func(), not 'the function env::func' in docs for std::env)-Z instrument-coverageon MSVC #76002 (Fix-Z instrument-coverageon MSVC)cow_is_borrowedmethods const #76139 (Makecow_is_borrowedmethods const)StringReaderprivate #76166 (MakeStringReaderprivate)Failed merges:
r? @ghost