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

Bump object and thorin-dwp #111413

Merged
merged 1 commit into from
May 20, 2023
Merged

Conversation

workingjubilee
Copy link
Member

Required to fix watchOS breakage.

@rustbot
Copy link
Collaborator

rustbot commented May 10, 2023

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels May 10, 2023
@rustbot
Copy link
Collaborator

rustbot commented May 10, 2023

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@workingjubilee
Copy link
Member Author

cc @vladimir-ea

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rustbot rustbot added the A-testsuite Area: The testsuite used to check the correctness of rustc label May 10, 2023
Cargo.lock Outdated
@@ -4621,7 +4648,7 @@ dependencies = [
"hermit-abi 0.3.0",
"libc",
"miniz_oxide",
"object",
"object 0.30.3",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is depending on old version of object for std intentional?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it's pointless to bump this unless backtrace is updated first.

@klensy
Copy link
Contributor

klensy commented May 10, 2023

There also exist #111384(or maybe one more?) with same bump, so need to coordinate.

Cargo.lock Outdated Show resolved Hide resolved
@petrochenkov
Copy link
Contributor

Does this PR contain all the version updates that #111384 needs?
If yes, then I'll block that PR on this one.

@workingjubilee
Copy link
Member Author

@petrochenkov Yes, that PR is now effectively a superset of this one on all points that matter.

@workingjubilee workingjubilee changed the title Bump object to 0.31.1 Bump object and thorin-dwp May 11, 2023
object -> 0.31.1
thorin-dwp -> 0.6.0

Required to fix watchOS breakage.
@Mark-Simulacrum
Copy link
Member

r=me when ready

@imWildCat
Copy link
Contributor

@Mark-Simulacrum sorry to jump into this thread.

No sure but #111384 seems to already contain changes in this PR.

@workingjubilee
Copy link
Member Author

Is ready, yes.

@bors r=MarkSimulacrum

@bors
Copy link
Contributor

bors commented May 20, 2023

📌 Commit 7156ff6 has been approved by MarkSimulacrum

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 20, 2023
@workingjubilee
Copy link
Member Author

@imWildCat It is the reviewer's intention to delay approving that PR until after this one is merged so we might as well get on with this one.

@bors
Copy link
Contributor

bors commented May 20, 2023

⌛ Testing commit 7156ff6 with merge 4eb5225...

@bors
Copy link
Contributor

bors commented May 20, 2023

☀️ Test successful - checks-actions
Approved by: MarkSimulacrum
Pushing 4eb5225 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 20, 2023
@bors bors merged commit 4eb5225 into rust-lang:master May 20, 2023
@rustbot rustbot added this to the 1.71.0 milestone May 20, 2023
@imWildCat
Copy link
Contributor

@workingjubilee understand. Thank you!

@bmisiak
Copy link
Contributor

bmisiak commented May 20, 2023

Excellent! I’ll rebase #111384 on top of this.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (4eb5225): comparison URL.

Overall result: ❌ regressions - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.5% [0.5%, 0.5%] 2
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.5% [0.5%, 0.5%] 2

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.2% [3.1%, 3.4%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 642.109s -> 645.683s (0.56%)

@workingjubilee
Copy link
Member Author

I know no action was called for, but regarding the perf and 3.5 second bootstrap regression:

0.7 of these seconds is the object crate.

Some of this is inevitable complication. However, with the enabling of compression features in object, it is possible that either object or thorin-dwp are including (thus, compiling) more code than Rust actually uses now, due to the use of compression by default. This could be fixed if thorin-dwp allowed forwarding features so we could disable the compression. However, it is likely we want to instead make more deliberate use of that compression somehow.

@workingjubilee
Copy link
Member Author

also: Is await-call-tree normally a bouncy benchmark? The wall-time massively improved on that.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request May 25, 2023
…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).
compiler-errors added a commit to compiler-errors/rust that referenced this pull request May 26, 2023
…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).
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request May 26, 2023
…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).
@workingjubilee workingjubilee deleted the bump-object-0-31-1 branch July 12, 2023 03:40
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Jul 12, 2023
Use constants from object crate

Replace hard-coded values with  `GNU_PROPERTY_{X86|AARCH64}_FEATURE_1_AND` from the object crate.

When working on  [issue](rust-lang#103001) it was suggested that we moved these constants to the object crate .  [PR](gimli-rs/object#537). Now that that the object crate has been updated  [PR](rust-lang#111413) we can make this change.
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Jul 12, 2023
Use constants from object crate

Replace hard-coded values with  `GNU_PROPERTY_{X86|AARCH64}_FEATURE_1_AND` from the object crate.

When working on  [issue](rust-lang#103001) it was suggested that we moved these constants to the object crate .  [PR](gimli-rs/object#537). Now that that the object crate has been updated  [PR](rust-lang#111413) we can make this change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.