Refactor uses of objc_msgSend to no longer have clashing definitions
#117910
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
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
O-unix
madsmtm
force-pushed
the
msg-send-no-clashing
branch
from
a65ce59
to
6df9bf3
Compare
|
r? @alexcrichton original implementer of this functionality wayyy back in #21787. EDIT: Apologies, you're not part of relevant teams any more. |
|
Failed to set assignee to
|
|
Alas I fear I'm also not who you're looking for. You'd need to go even further back but tagging those on nearly 10-year-old PRs probably won't yield the best results. |
|
☔ The latest upstream changes (presumably #118566) made this pull request unmergeable. Please resolve the merge conflicts. |
madsmtm
force-pushed
the
msg-send-no-clashing
branch
from
6df9bf3
to
6adccff
Compare
|
r? rust-lang/macos Closest team I could find to whom may be able to review this change. |
|
☔ The latest upstream changes (presumably #117285) made this pull request unmergeable. Please resolve the merge conflicts. |
This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations). Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool).
madsmtm
force-pushed
the
msg-send-no-clashing
branch
from
6adccff
to
3b325bc
Compare
|
Really we should just be using @bors r+ rollup. |
bors
added
S-waiting-on-bors
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jan 22, 2024
…omcc Refactor uses of `objc_msgSend` to no longer have clashing definitions This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations). Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool). Motivation is to avoid issues with clashing definitions, like described in rust-lang#12707 (comment) and rust-lang#46188 (comment), CC `@bjorn3.`
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 22, 2024
…iaskrgr Rollup of 11 pull requests Successful merges: - rust-lang#117910 (Refactor uses of `objc_msgSend` to no longer have clashing definitions) - rust-lang#118639 (Undeprecate lint `unstable_features` and make use of it in the compiler) - rust-lang#119801 (Fix deallocation with wrong allocator in (A)Rc::from_box_in) - rust-lang#120058 (bootstrap: improvements for compiler builds) - rust-lang#120059 (Make generic const type mismatches not hide trait impls from the trait solver) - rust-lang#120097 (Report unreachable subpatterns consistently) - rust-lang#120137 (Validate AggregateKind types in MIR) - rust-lang#120164 (`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`) - rust-lang#120181 (Allow any `const` expression blocks in `thread_local!`) - rust-lang#120204 (Builtin macros effectively have implicit #[collapse_debuginfo(yes)]) - rust-lang#120218 (rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 22, 2024
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#117910 (Refactor uses of `objc_msgSend` to no longer have clashing definitions) - rust-lang#118639 (Undeprecate lint `unstable_features` and make use of it in the compiler) - rust-lang#119801 (Fix deallocation with wrong allocator in (A)Rc::from_box_in) - rust-lang#120058 (bootstrap: improvements for compiler builds) - rust-lang#120059 (Make generic const type mismatches not hide trait impls from the trait solver) - rust-lang#120097 (Report unreachable subpatterns consistently) - rust-lang#120137 (Validate AggregateKind types in MIR) - rust-lang#120164 (`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`) - rust-lang#120181 (Allow any `const` expression blocks in `thread_local!`) - rust-lang#120218 (rustfmt: Check that a token can begin a nonterminal kind before parsing it as a macro arg) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 22, 2024
Rollup merge of rust-lang#117910 - madsmtm:msg-send-no-clashing, r=thomcc Refactor uses of `objc_msgSend` to no longer have clashing definitions This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations). Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the `args` function doesn't leak memory (if you wrap it in an autorelease pool). Motivation is to avoid issues with clashing definitions, like described in rust-lang#12707 (comment) and rust-lang#46188 (comment), CC ``@bjorn3.``
6 tasks
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
May 21, 2024
…ngjubilee Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance). The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute). That we've been overly cautious here has also been noted by `@thomcc` in rust-lang#117910 (comment). r? `@workingjubilee` `@rustbot` label O-apple
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 21, 2024
Rollup merge of rust-lang#125225 - madsmtm:ios-crt_externs.h, r=workingjubilee Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance). The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute). That we've been overly cautious here has also been noted by `@thomcc` in rust-lang#117910 (comment). r? `@workingjubilee` `@rustbot` label O-apple
RalfJung
pushed a commit
to RalfJung/miri
that referenced
this pull request
May 22, 2024
Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance). The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute). That we've been overly cautious here has also been noted by `@thomcc` in rust-lang/rust#117910 (comment). r? `@workingjubilee` `@rustbot` label O-apple
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
May 24, 2024
Use functions from `crt_externs.h` on iOS/tvOS/watchOS/visionOS Use `_NSGetEnviron`, `_NSGetArgc` and `_NSGetArgv` on iOS/tvOS/watchOS/visionOS, see each commit and the code comments for details. This allows us to unify more code with the macOS implementation, as well as avoiding linking to the `Foundation` framework (which is good for startup performance). The biggest problem with doing this would be if it lead to App Store rejections. After doing a bunch of research on this, while [it did happen once in 2009](https://blog.unity.com/engine-platform/unity-app-store-submissions-problem-solved), I find it fairly unlikely to happen nowadays, especially considering that Apple has later _added_ `crt_externs.h` to the iOS/tvOS/watchOS/visionOS SDKs, strongly signifying the functions therein is indeed supported on those platforms (even though they lack an availability attribute). That we've been overly cautious here has also been noted by `@thomcc` in rust-lang/rust#117910 (comment). r? `@workingjubilee` `@rustbot` label O-apple
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.
This is very similar to what Apple's own headers encourage you to do (cast the function pointer before use instead of making new declarations).
Additionally, I'm documenting a few of the memory management rules we're following, ensuring that the
argsfunction doesn't leak memory (if you wrap it in an autorelease pool).Motivation is to avoid issues with clashing definitions, like described in #12707 (comment) and #46188 (comment), CC @bjorn3.