Skip to content

Rollup of 7 pull requests - #88240

Merged
bors merged 15 commits into
rust-lang:masterfrom
GuillaumeGomez:rollup-wdom91m
Aug 22, 2021
Merged

Rollup of 7 pull requests#88240
bors merged 15 commits into
rust-lang:masterfrom
GuillaumeGomez:rollup-wdom91m

Conversation

@GuillaumeGomez

Copy link
Copy Markdown
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

FabianWolffand others added 15 commits June 30, 2021 16:43
Without the specific version, the mach-o header will be missing the
minimum supported operating system version. This is mandatory for
running Rust binaries on iOS devices.
These API changes appear to have all taken place in
https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and
AddressSanitizerPass to only accept their options type as a ctor
argument instead of the sequence of bools etc. This required a couple of
parameter additions, which I made match the default prior to the
mentioned upstream LLVM change.
This patch restores rustc to building (though not quite passing all
tests, I've mailed other patches for those issues) against LLVM HEAD.
The information was tracked, but unused.
…eGomez
Improve wording of the `drop_bounds` lint
This PR addresses rust-lang#86653. The issue is sort of a false positive of the `drop_bounds` lint, but I would argue that the best solution for rust-lang#86653 is simply a rewording of the warning message and lint description, because even if the lint is _technically_ wrong, it still forces the programmer to think about what they are doing, and they can always use `#[allow(drop_bounds)]` if they think that they really need the `Drop` bound.
There are two issues with the current warning message and lint description:
- First, it says that `Drop` bounds are "useless", which is technically incorrect because they actually do have the effect of allowing you e.g. to call methods that also have a `Drop` bound on their generic arguments for some reason. I have changed the wording to emphasize not that the bound is "useless", but that it is most likely not what was intended.
- Second, it claims that `std::mem::needs_drop` detects whether a type has a destructor. But I think this is also technically wrong: The `Drop` bound says whether the type has a destructor or not, whereas `std::mem::needs_drop` also takes nested types with destructors into account, even if the top-level type does not itself have one (although I'm not 100% sure about the exact terminology here, i.e. whether the "drop glue" of the top-level type counts as a destructor or not).
cc `@jonhoo,` does this solve the issue for you?
r? `@GuillaumeGomez`
…overflow, r=jackh726
Show discriminant before overflow in diagnostic for duplicate values.
This PR adds the value before overflow for explicit discriminant values in the error for duplicate discriminant values.
I found it rather confusing to see only the overflowed value.
It only does this for literals, since overflows in const evaluated arithmetic are already a hard error.
This is my first PR to the compiler, so please let me know if the implementation can be improved :)
Before:
![image](https://user-images.githubusercontent.com/786213/125850097-bf5fb7e0-d800-4386-a738-c30f41822964.png)
After:
![image](https://user-images.githubusercontent.com/786213/125850120-e2bb765d-ad86-4888-a6cb-dec34fba3fea.png)
…ion-in-header, r=petrochenkov
Generate an iOS LLVM target with a specific version
This commit adds the `LC_VERSION_MIN_IPHONEOS` load command to the Mach-O header generated for `aarch64-apple-ios` binaries. The operating system will look for this load command to determine the minimum supported operating system version and will not allow the binary to run if it's absent. This logic already exists for the simulator toolchain.
I've been using `otool` from a [cctools](https://github.com/tpoechtrager/cctools-port) toolchain to parse the header and validate that this change adds the required load command.
This change appears to be enough to build Rust binaries that can run on a jailbroken iPhone.
PassWrapper: adapt for LLVM 14 changes
These API changes appear to have all taken place in
https://reviews.llvm.org/D105007, which moved HWAddressSanitizerPass and
AddressSanitizerPass to only accept their options type as a ctor
argument instead of the sequence of bools etc. This required a couple of
parameter additions, which I made match the default prior to the
mentioned upstream LLVM change.
This patch restores rustc to building (though not quite passing all
tests, I've mailed other patches for those issues) against LLVM HEAD.
cleanup: `Span::new` -> `Span::with_lo`
Extracted from rust-lang#84373 as suggested in rust-lang#84373 (comment).
It turned out less useful then I expected, but anyway.
r? `@cjgillot`
`@bors` rollup
…=estebank
Suggest importing the right kind of macro.
Fixesrust-lang#88228.
r? `@estebank`
…pace, r=estebank
Stop tracking namespace in used_imports.
This changes `used_imports` from a `FxHashSet<(NodeId, Namespace)>` to a `FxHashSet<NodeId>`, as the Namespace information isn't used.
The only point that uses it did three lookups, `|=`'ing them together.
r? `@estebank`
@rustbotrustbot added the rollup A PR which is a rollup label Aug 22, 2021
@GuillaumeGomez

Copy link
Copy Markdown
MemberAuthor

@bors: r+ p=7 rollup=never

@bors

bors commented Aug 22, 2021

Copy link
Copy Markdown
Collaborator

📌 Commit 3e8e8d2 has been approved by GuillaumeGomez

@borsbors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 22, 2021
@bors

bors commented Aug 22, 2021

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 3e8e8d2 with merge af14075...

@bors

bors commented Aug 22, 2021

Copy link
Copy Markdown
Collaborator

☀️ Test successful - checks-actions
Approved by: GuillaumeGomez
Pushing af14075 to master...

@borsbors added the merged-by-bors This PR was explicitly merged by bors. label Aug 22, 2021
@bors
bors merged commit af14075 into rust-lang:masterAug 22, 2021
@rustbotrustbot added this to the 1.56.0 milestone Aug 22, 2021
@GuillaumeGomez
GuillaumeGomez deleted the rollup-wdom91m branch August 23, 2021 08:15
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-borsThis PR was explicitly merged by bors.rollupA PR which is a rollupS-waiting-on-borsStatus: Waiting on bors to run and complete tests. Bors will change the label on completion.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

9 participants

@GuillaumeGomez@bors@rustbot@FabianWolff@de-vri-es@kit-981@durin42@petrochenkov@m-ou-se