Rollup of 12 pull requests #52001
Closed
Rollup of 12 pull requests #52001
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
…le with a portability lint" This reverts commit 837d6c7. Fixes rust-lang#49415
Note this isn't useful, yet. More changes will be necessary to be able to actually codegen for this machine. As such, it is not enabled by default. This patch is on its own for the benefit of the reviewers.
Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-`?` match are different (that is, specifically: in `x?`
where x is a `Result<A, B>`, the `Ok` arm body is an `A`, whereas the
`Err` arm diverges to return a `Result<A, B>`), because they're being
assigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no `match` in the sweetly sugared
source.
It is not without some misgivings that we pollute the clarity-of-purpose
of `note_error_origin` with the suggestion to wrap with `Ok` (the other
branches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the `Ok` suggestion is serving
a different purpose), but it's the natural place to do it given that
we're already matching on `ObligationCauseCode::MatchExpressionArm {
arm_span, source }` there.
Resolves rust-lang#51632.
Shipping this tool gives people reliable way to reduce the generated executable size. I'm not sure if this strip tool is available from the llvm version current rust is built on. But let's take a look. @japaric
Refactored code accordingly.
nll requires these annotations, I believe because of rust-lang#29149
Tests should always use "rustc" and "cargo" from config.toml instead of assuming that stage0 binaries was downloaded to build directory.
…ification, r=oli-obk Removed `uninitialized_statics` field from `Memory` struct in miri **IMPORTANT: Do not merge until rust-lang#51110 is merged** r? @oli-obk CC @eddyb
…ne, r=alexcrichton Initialize LLVM's AMDGPU target machine, if available. Note this isn't useful, yet. More changes will be necessary to be able to actually codegen for this machine. As such, it is not enabled by default. This patch is on its own for the benefit of the reviewers.
Implement always-fallible TryFrom for usize/isize conversions that are infallible on some platforms This reverts commit 837d6c7 "Remove TryFrom impls that might become conditionally-infallible with a portability lint". This fixes rust-lang#49415 by adding (restoring) missing `TryFrom` impls for integer conversions to or from `usize` or `isize`, by making them always fallible at the type system level (that is, with `Error=TryFromIntError`) even though they happen to be infallible on some platforms (for some values of `size_of::<usize>()`). They had been removed to allow the possibility to conditionally having some of them be infallible `From` impls instead, depending on the platforms, and have the [portability lint](rust-lang/rfcs#1868) warn when they are used in code that is not already opting into non-portability. For example `#[allow(some_lint)] usize::from(x: u64)` would be valid on code that only targets 64-bit platforms. This PR gives up on this possiblity for two reasons: * Based on discussion with @aturon, it seems that the portability lint is not happening any time soon. It’s better to have the conversions be available *at all* than keep blocking them for so long. Portability-lint-gated platform-specific APIs can always be added separately later. * For code that is fine with fallibility, the alternative would force it to opt into "non-portability" even though there would be no real portability issue.
Add read_exact_at and write_all_at methods to FileExt on unix This PR adds `FileExt::read_exact_at()` and `FileExt::write_all_at()`, which are to `read_at()` and `write_at()` as `read_exact()` and `write_all()` are to `read()` and `write()`. This allows the user to not have to deal with `ErrorKind::Interrupted` and calling the functions in a loop. I was unsure as to how to mark these new methods so I marked them `unstable`, please let me know if I should have done it differently. I asked in Discord and was told that as this change is small it does not require an RFC.
…reemap-annotations, r=gankro add outlives annotations to `BTreeMap` NLL requires these annotations, I believe because of <rust-lang#29149>. Fixes rust-lang#48224 r? @gankro cc @lqd
…r=nikomatsakis [NLL] Use better span for initializing a variable twice Closes rust-lang#51217 When assigning to a (projection from a) local immutable local which starts initialised (everything except `let PATTERN;`): * Point to the declaration of that local * Make the error message refer to the local, rather than the projection. r? @nikomatsakis
…ing_desugar, r=estebank
in which we plug the crack where `?`-desugaring leaked into errors
Most of the time, it's not a problem that the types of the arm bodies in
a desugared-from-`?` match are different (that is, specifically: in `x?`
where x is a `Result<A, B>`, the `Ok` arm body is an `A`, whereas the
`Err` arm diverges to return a `Result<A, B>`), because they're being
assigned to different places. But in tail position, the types do need to
match, and our error message was explicitly referring to "match arms",
which is confusing when there's no `match` in the sweetly sugared
source.
It is not without some misgivings that we pollute the clarity-of-purpose
of `note_error_origin` with the suggestion to wrap with `Ok` (the other
branches are pointing out the odd-arm-out in the HIR that is the origin
of the error; the new branch that issues the `Ok` suggestion is serving
a different purpose), but it's the natural place to do it given that
we're already matching on `ObligationCauseCode::MatchExpressionArm {
arm_span, source }` there.
Resolves rust-lang#51632.
Provide llvm-strip in llvm-tools component Shipping this tool gives people reliable way to reduce the generated executable size. I'm not sure if this strip tool is available from the llvm version current rust is built on. But let's take a look. @japaric
…=estebank Fix various issues with control-flow statements inside anonymous constants Fixes rust-lang#51761. Fixes rust-lang#51963 (and the host of other reported issues there). (Might be easiest to review per commit, as they should be standalone.) r? @estebank
…tage0, r=simulacrum bootstrap: tests should use rustc from config.toml Tests should always use "rustc" and "cargo" from config.toml instead of assuming that stage0 binaries was downloaded to build directory. Without this change `./x.py test src/bootstrap` will always try to use `build/ARCH/stage0/bin/rustc` file as compiler, but when we use local compiler to bootstrap this file does not exist.
Do not suggest changes to str literal if it isn't one Fix rust-lang#48364.
…atsakis Get rid of `TyImplTraitExistential` cc @eddyb r? @nikomatsakis
|
@bors r+ p=1 |
|
📌 Commit 4dcaf90 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 4dcaf90 with merge 1a112bda5d5642961ca8f5209ff4efa418a63473... |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The job 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 |
1 similar comment
|
The job 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 |
|
☔ The latest upstream changes (presumably #51428) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
Successful merges:
uninitialized_staticsfield fromMemorystruct in miri #51428 (Removeduninitialized_staticsfield fromMemorystruct in miri)BTreeMap#51914 (add outlives annotations toBTreeMap)?-desugaring leaked into errors #51938 (in which we plug the crack where?-desugaring leaked into errors)TyImplTraitExistential#51979 (Get rid ofTyImplTraitExistential)Failed merges:
r? @ghost