Rollup of 10 pull requests #47195
Closed
Rollup of 10 pull requests #47195
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
Member
kennytm
commented
Jan 4, 2018
kennytm
commented
- Successful merges: Allow non-alphabetic underscores in camel case #46907, Correct a few stability attributes #47030, Disable printing of error message on file descriptor 2 on CloudABI. #47033, Use the right TLS model for CloudABI. #47110, Implement TrustedRandomAccess for slice::{Chunks, ChunksMut, Windows} #47142, Span::resolved_at and Span::located_at to combine behavior of two spans #47149, Return None from Span::join if in different files #47150, This isn't in Rust 1.23 #47160, Remove some outdated LLVM-related code #47173, Equivalent example for ? operator #47182
- Failed merges:
As CloudABI is a capability-based runtime environment, file descriptors are the mechanism that grants rights to a process. These file descriptors may be passed into processes on startup using a utility called cloudabi-run. Unlike the POSIX shell, cloudabi-run does not follow the UNIX model where file descriptors 0, 1 and 2 represent stdin, stdout and stderr. There can be arbitrary many (or few) file descriptors that can be provided. For this reason, CloudABI's C library also doesn't define STD*_FILENO. liblibc should also not declare these. Disable the code in liballoc_system that tries to print error messages over file descriptor 2. For now, let's keep this function quiet. We'll see if we can think of some other way to log this in the future.
After rust-lang#47089 lands, CloudABI will no longer be considered UNIX. We need to pick the right allocator flavour now.
CloudABI doesn't do dynamic linking. For this reason, there is no need to handle any other TLS model than local-exec. CloudABI's C library doesn't provide a __tls_get_addr() function to do Dynamic TLS. By forcing local-exec to be used here, we ensure that we don't generate function calls to __tls_get_addr().
Proc macro spans serve two mostly unrelated purposes: controlling name resolution and controlling error messages. It can be useful to mix the name resolution behavior of one span with the line/column error message locations of a different span. In particular, consider the case of a trait brought into scope within the def_site of a custom derive. I want to invoke trait methods on the fields of the user's struct. If the field type does not implement the right trait, I want the error message to underline the corresponding struct field. Generating the method call with the def_site span is not ideal -- it compiles and runs but error messages sadly always point to the derive attribute like we saw with Macros 1.1. ``` | 4 | #[derive(HeapSize)] | ^^^^^^^^ ``` Generating the method call with the same span as the struct field's ident or type is not correct -- it shows the right underlines but fails to resolve to the trait in scope at the def_site. ``` | 7 | bad: std::thread::Thread, | ^^^^^^^^^^^^^^^^^^^^^^^^ ``` The correct span for the method call is one that combines the def_site's name resolution with the struct field's line/column. ``` field.span.resolved_at(Span::def_site()) // equivalently Span::def_site().located_at(field.span) ``` Adding both because which one is more natural will depend on context.
For testing if the TrustedRandomAccess implementation works.
rust-lang#47113 renamed the private size field to chunk_size for consistency.
The function was added as a wrapper to handle compatibility with older LLVM versions that we no longer support, so it can be removed. Refs rust-lang#46437
The example with the ? operator was missing file.write_all
Allow non-alphabetic underscores in camel case Certain identifiers, such as `X86_64`, cannot currently be unambiguously represented in camel case (`X8664`, `X86_64`, `X8_664`, etc. are all transformed to the same identifier). This change relaxes the rules so that underscores are permitted between two non-alphabetic characters under `#[forbid(non_camel_case_types)]`. Fixes rust-lang#34633 and fixes rust-lang#41621.
Correct a few stability attributes * The extra impls for `ManuallyDrop` were added in rust-lang#44310 which was only stabilised in 1.22.0. * The impls for `SliceIndex` were stabilised in rust-lang#43373 but as `RangeInclusive` and `RangeToInclusive` are still unstable the impls should remain unstable. * The `From` impls for atomic integers were added in rust-lang#45610 but most atomic integers are still unstable. * The `shared_from_slice2` impls were added in rust-lang#45990 but they won't be stable until 1.24.0. * The `Mutex` and `RwLock` impls were added in rust-lang#46082 but won't be stable until 1.24.0.
Disable printing of error message on file descriptor 2 on CloudABI. As CloudABI is a capability-based runtime environment, file descriptors are the mechanism that grants rights to a process. These file descriptors may be passed into processes on startup using a utility called cloudabi-run. Unlike the POSIX shell, cloudabi-run does not follow the UNIX model where file descriptors 0, 1 and 2 represent stdin, stdout and stderr. There can be arbitrary many (or few) file descriptors that can be provided. For this reason, CloudABI's C library also doesn't define STD*_FILENO. liblibc should also not declare these. Disable the code in liballoc_system that tries to print error messages over file descriptor 2. For now, let's keep this function quiet. We'll see if we can think of some other way to log this in the future.
Use the right TLS model for CloudABI. CloudABI doesn't do dynamic linking. For this reason, there is no need to handle any other TLS model than local-exec. CloudABI's C library doesn't provide a __tls_get_addr() function to do Dynamic TLS. By forcing local-exec to be used here, we ensure that we don't generate function calls to __tls_get_addr().
…s, r=kennytm
Implement TrustedRandomAccess for slice::{Chunks, ChunksMut, Windows}
As suggested by @bluss in rust-lang#47115 (comment)
Span::resolved_at and Span::located_at to combine behavior of two spans Proc macro spans serve two mostly unrelated purposes: controlling name resolution and controlling error messages. It can be useful to mix the name resolution behavior of one span with the line/column error message locations of a different span. In particular, consider the case of a trait brought into scope within the def_site of a custom derive. I want to invoke trait methods on the fields of the user's struct. If the field type does not implement the right trait, I want the error message to underline the corresponding struct field. Generating the method call with the def_site span is not ideal -- it compiles and runs but error messages sadly always point to the derive attribute like we saw with Macros 1.1. ``` | 4 | #[derive(HeapSize)] | ^^^^^^^^ ``` Generating the method call with the same span as the struct field's ident or type is not correct -- it shows the right underlines but fails to resolve to the trait in scope at the def_site. ``` | 7 | bad: std::thread::Thread, | ^^^^^^^^^^^^^^^^^^^^^^^^ ``` The correct span for the method call is one that combines the def_site's name resolution with the struct field's line/column. ```rust field.span.resolved_at(Span::def_site()) // equivalently Span::def_site().located_at(field.span) ``` Adding both because which one is more natural will depend on context. Addresses rust-lang#38356 (comment). r? @jseyfried
Return None from Span::join if in different files Fixes rust-lang#47148. r? @abonander
…lexcrichton This isn't in Rust 1.23 r? @alexcrichton
Remove some outdated LLVM-related code Ticks two boxes on rust-lang#46437
Equivalent example for ? operator The example with the ? operator in the documentation for try! macro was missing file.write_all. Now all three examples are consistent.
|
r? @dtolnay (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=10 |
|
📌 Commit 1791414 has been approved by |
kennytm
added
the
S-waiting-on-bors
|
⌛ Testing commit 1791414 with merge 0869c5bde977f48d470ead746106030fb40eb98e... |
|
💔 Test failed - status-appveyor |
|
AppVeyor failure: |
|
This one should be spurious (similar to #45348 (comment)). I thought we have updated xsv to fix this already? 😕 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.