Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 7 pull requests #111953

Closed
wants to merge 19 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

lowr and others added 19 commits May 19, 2023 19:04
Additionally add analogous test for early lints.
Issue rust-lang#106021
Apple LD requires build versions in object files for Catalyst
Also merge the two almost identical strikethrough tests together and document what the test tests.
…rd, r=GuillaumeGomez

update `pulldown-cmark` to `0.9.3`

This PR updates `pulldown-cmark` to version `0.9.3`, which does two main things:
* Pulls in pulldown-cmark/pulldown-cmark#643 to fix rust-lang#111117
* Allows parsing strikethrough with single tildes, e.g. `~foo~` -> ~foo~. This matches the [GFM spec](https://github.github.com/gfm/#strikethrough-extension-).

Full changelog: pulldown-cmark/pulldown-cmark#646
…henkov

Fix linking Mac Catalyst by including LC_BUILD_VERSION in object files

Hello. My first rustc PR!

Issue rust-lang#106021 prevents Rust code from being linked into Mac Catalyst applications. Apple's LD has started requiring object files to contain version information about the platform they were built for, such as:
* the "deployment target" (minimum supported OS version),
* the SDK version
* the type of the platform (macOS/iOS/catalyst/tvOS/watchOS all have a different number).

This is currently only enforced when building for Mac Catalyst.

Rust uses the `object` crate which added support for including this information starting with `0.31.0`. ~~I upgraded it along with `thorin-dwp` so that everything depends on 0.31.
Apparently 0.31 [pulls in](gimli-rs/object#463) `ruzstd` due to a [new ELF standard](https://maskray.me/blog/2022-09-09-zstd-compressed-debug-sections) because its `compression` feature is enabled by thorin. If you find this objectionable, let me know what the best way to avoid pulling in those dependencies might be.~~

**(`object` upgraded in rust-lang#111413

I then added two commits:
* The first one adds very basic, hard-coded support for calling `set_macho_build_version` for `-macabi` (Catalyst) targets, where it claims deployment target of Catalyst 14.0 and SDK of 16.2.
* The second weaves the versioning through `rust_target::spec::TargetOptions`, so that we can stick to specifying all target-related info in one place.

Kudos to `@ara4n` for writing [this gist](https://gist.github.com/ara4n/320a53ea768aba51afad4c9ed2168536).
…=eholk

Consider lint check attributes on match arms

Currently, lint check attributes on match arms have no effect for some lints. This PR makes some lint passes to take those attributes into account.

- `LateContextAndPass` for late lint doesn't update `last_node_with_lint_attrs` when it visits match arms. This leads to lint check attributes on match arms taking no effects on late lints that operate on the arms' pattern:

  ```rust
  match value {
      #[deny(non_snake_case)]
      PAT => {} // `non_snake_case` only warned due to default lint level
  }
  ```

  To be honest, I'm not sure whether this is intentional or just an oversight. I've dug the implementation history and searched up issues/PRs but couldn't find any discussion on this.

- `MatchVisitor` doesn't update its lint level when it visits match arms. This leads to check lint attributes on match arms taking no effect on some lints handled by this visitor, namely: `bindings_with_variant_name` and `irrefutable_let_patterns`.

  This seems to be a fallout from rust-lang#108504. Before 05082f5, when the visitor operated on HIR rather than THIR, check lint attributes for the said lints were effective. [This playground][play] compiles successfully on current stable (1.69) but fails on current beta and nightly.

  I wasn't sure where best to place the test for this. Let me know if there's a better place.

[play]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=38432b79e535cb175f8f7d6d236d29c3
[play-match]: https://play.rust-lang.org/?version=beta&mode=debug&edition=2021&gist=629aa71b7c84b269beadeba664e2221d
…illot

Always capture slice when pattern requires checking the length

Fixes rust-lang#111751

cc `@zirconium-n,` I see you were assigned to this but I've fixed some similar issues in the past and had an idea on how to investigate this.
…=wesleywiser

Don't print newlines in APITs

This is kind of a hack, but it gets the job done because the only "special" formatting that (afaict) `rustc_ast_pretty` does is break with newlines sometimes.

Fixes rust-lang/measureme#207
…lor-7, r=notriddle

Migrate GUI colors test to original CSS color format

Follow-up of rust-lang#111459.

r? `@notriddle`
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels May 25, 2023
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=7

@bors
Copy link
Contributor

bors commented May 25, 2023

📌 Commit 0390af0 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 25, 2023
@bors
Copy link
Contributor

bors commented May 25, 2023

⌛ Testing commit 0390af0 with merge 6b7e1055ca47c89230f70d12eb5c742872479bb6...

@klensy
Copy link
Contributor

klensy commented May 25, 2023

#111384 pushed after adding to rollup.

@compiler-errors
Copy link
Member

@bors r- retry
(I think that's the right incantation to stop the auto merge)

Kicking out of the queue because #111384 needs re-approval. Thanks for catching this @klensy, cc @bmisiak

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 25, 2023
@compiler-errors
Copy link
Member

I'll open a new rollup without this one, sorry @matthiaskrgr haha

@rust-log-analyzer
Copy link
Collaborator

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@matthiaskrgr matthiaskrgr deleted the rollup-w5v61cs branch March 16, 2024 18:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.