-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Closed
Rollup of 7 pull requests #111953
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
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`
Remove ExpnKind::Inlined. Suggested in rust-lang#111815 (comment) r? `@oli-obk`
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
@bors r+ rollup=never p=7 |
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
⌛ Testing commit 0390af0 with merge 6b7e1055ca47c89230f70d12eb5c742872479bb6... |
#111384 pushed after adding to rollup. |
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
I'll open a new rollup without this one, sorry @matthiaskrgr haha |
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.
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:
pulldown-cmark
to0.9.3
#111152 (updatepulldown-cmark
to0.9.3
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup