Rollup of 11 pull requests #32496
Merged
Rollup of 11 pull requests #32496
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
Manishearth
commented
Mar 26, 2016
Manishearth
commented
- Successful merges: resolve: Minimize hacks in name resolution of primitive types #32131, Restrict constants in patterns #32199, std: Fix inheriting stdin on status() #32257, std: Rewrite Once with poisoning #32325, Some fixes for error recovery in the compiler #32435, Remove ungrammatical dots from the error index. #32447, Add augmented assignment operator impls for time types #32448, Hardcode accepting 0 as a valid str char boundary #32456, make available monomorphizations shared by CGU #32469, Fix unsound behaviour with null characters in thread names (issue #32475) #32476, use new visitor to erase regions #32482
- Failed merges: Cleanup resolve #32240
This regression was accidentally introduced in rust-lang#31618, and it's just flipping a boolean! Closes rust-lang#32254
They were probably meant as a shorthand for omitted code. Part of rust-lang#32446 but there should be a separate fix for the issue. Signed-off-by: NODA, Kai <nodakai@gmail.com>
Index 0 must be a valid char boundary (invariant of str that it contains
valid UTF-8 data).
If we check explicitly for index == 0, that removes the need to read the
byte at index 0, so it avoids a trip to the string's memory, and it
optimizes out the slicing index' bounds check whenever it is zero.
With this change, the following examples all change from having a read of
the byte at 0 and a branch to possibly panicing, to having the bounds
checking optimized away.
```rust
pub fn split(s: &str) -> (&str, &str) {
s.split_at(0)
}
pub fn both(s: &str) -> &str {
&s[0..s.len()]
}
pub fn first(s: &str) -> &str {
&s[..0]
}
pub fn last(s: &str) -> &str {
&s[0..]
}
```
The current setup means that all generics are local to a codegen-unit, which means massive duplication.
…t-lang#32475) Previously, the thread name (&str) was converted to a CString in the new thread, but outside unwind::try, causing a panic to continue into FFI. This patch changes that behaviour, so that the panic instead happens in the parent thread (where panic infrastructure is properly set up), not the new thread. This could potentially be a breaking change for architectures who don't support thread names. Signed-off-by: David Henningsson <diwic@ubuntu.com>
to careful use of the span from deriving, we can permit it in stable code if it derives from deriving (not-even-a-pun intended)
this was required to preserve the span from the #[structural_match] attribute -- but honestly I am not 100% sure if it makes sense.
This is a [breaking-change]: according to RFC rust-lang#1445, constants used as patterns must be of a type that *derives* `Eq`. If you encounter a problem, you are most likely using a constant in an expression where the type of the constant is some struct that does not currently implement `Eq`. Something like the following: ```rust struct SomeType { ... } const SOME_CONST: SomeType = ...; match foo { SOME_CONST => ... } ``` The easiest and most future compatible fix is to annotate the type in question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is not enough, it must be *derived*): ```rust struct SomeType { ... } const SOME_CONST: SomeType = ...; match foo { SOME_CONST => ... } ``` Another good option is to rewrite the match arm to use an `if` condition (this is also particularly good for floating point types, which implement `PartialEq` but not `Eq`): ```rust match foo { c if c == SOME_CONST => ... } ``` Finally, a third alternative is to tag the type with `#[structural_match]`; but this is not recommended, as the attribute is never expected to be stabilized. Please see RFC rust-lang#1445 for more details.
resolve: Minimize hacks in name resolution of primitive types When resolving the first unqualified segment in a path with `n` segments and `n - 1` associated item segments, e.g. (`a` or `a::assoc` or `a::assoc::assoc` etc) try to resolve `a` without considering primitive types first. If the "normal" lookup fails or results in a module, then try to resolve `a` as a primitive type as a fallback. This way backward compatibility is respected, but the restriction from E0317 can be lifted, i.e. primitive names mostly can be shadowed like any other names. Furthermore, if names of primitive types are [put into prelude](https://github.com/petrochenkov/rust/tree/prim2) (now it's possible to do), then most of names will be resolved in conventional way and amount of code relying on this fallback will be greatly reduced. Although, it's not entirely convenient to put them into prelude right now due to temporary conflicts like `use prelude::v1::*; use usize;` in libcore/libstd, I'd better wait for proper glob shadowing before doing it. I wish the `no_prelude` attribute were unstable as intended :( cc @jseyfried @arielb1 r? @eddyb
…patterns-2, r=pnkfelix Restrict constants in patterns This implements [RFC 1445](https://github.com/rust-lang/rfcs/blob/master/text/1445-restrict-constants-in-patterns.md). The primary change is to limit the types of constants used in patterns to those that *derive* `Eq` (note that implementing `Eq` is not sufficient). This has two main effects: 1. Floating point constants are linted, and will eventually be disallowed. This is because floating point constants do not implement `Eq` but only `PartialEq`. This check replaces the existing special case code that aimed to detect the use of `NaN`. 2. Structs and enums must derive `Eq` to be usable within a match. This is a [breaking-change]: if you encounter a problem, you are most likely using a constant in an expression where the type of the constant is some struct that does not currently implement `Eq`. Something like the following: ```rust struct SomeType { ... } const SOME_CONST: SomeType = ...; match foo { SOME_CONST => ... } ``` The easiest and most future compatible fix is to annotate the type in question with `#[derive(Eq)]` (note that merely *implementing* `Eq` is not enough, it must be *derived*): ```rust struct SomeType { ... } const SOME_CONST: SomeType = ...; match foo { SOME_CONST => ... } ``` Another good option is to rewrite the match arm to use an `if` condition (this is also particularly good for floating point types, which implement `PartialEq` but not `Eq`): ```rust match foo { c if c == SOME_CONST => ... } ``` Finally, a third alternative is to tag the type with `#[structural_match]`; but this is not recommended, as the attribute is never expected to be stabilized. Please see RFC rust-lang#1445 for more details. cc rust-lang#31434 r? @pnkfelix
…uron std: Fix inheriting stdin on status() This regression was accidentally introduced in rust-lang#31618, and it's just flipping a boolean! Closes rust-lang#32254
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=100 force |
|
@bors r+ force |
|
📌 Commit 2908ffd has been approved by |
|
⌛ Testing commit 2908ffd with merge 4dbf493... |
|
💔 Test failed - auto-win-msvc-64-opt |
|
@bors retry force |
|
⌛ Testing commit 2908ffd with merge 9c46072... |
|
💔 Test failed - auto-linux-64-nopt-t |
Some fixes for error recovery in the compiler
Remove ungrammatical dots from the error index. They were probably meant as a shorthand for omitted code. Part of rust-lang#32446 but there should be a separate fix for the issue.
… r=alexcrichton Add augmented assignment operator impls for time types r? @alexcrichton
Hardcode accepting 0 as a valid str char boundary If we check explicitly for index == 0, that removes the need to read the byte at index 0, so it avoids a trip to the string's memory, and it optimizes out the slicing index' bounds check whenever it is (a constant) zero.
make available monomorphizations shared by CGU The current setup means that all generics are local to a codegen-unit, which means massive duplication.
…ichton Fix unsound behaviour with null characters in thread names (issue rust-lang#32475) Previously, the thread name (&str) was converted to a CString in the new thread, but outside unwind::try, causing a panic to continue into FFI. This patch changes that behaviour, so that the panic instead happens in the parent thread (where panic infrastructure is properly set up), not the new thread. This could potentially be a breaking change for architectures who don't support thread names.
…agisa use new visitor to erase regions r? @nagisa
|
@bors r+ force |
|
📌 Commit 6c10866 has been approved by |
|
⌛ Testing commit 6c10866 with merge d322f99... |
This was referenced Mar 26, 2016
Merged
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.