Stabilize core::ffi:c_* and re-export in std::ffi by joshtriplett · Pull Request #98315 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation10 Commits1 Checks0 Files changed
Conversation
This file contains hidden or 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
[ Show hidden characters]({{ revealButtonHref }})
This only stabilizes the base types, not the non-zero variants, since
those have their own separate tracking issue and have not gone through
FCP to stabilize.
Relevant to the library API team, which will review and decide on the PR/issue.
Marks issues that should be documented in the release notes of the next release.
labels
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
r? @m-ou-se
(rust-highfive has picked a reviewer for you, use r? to override)
Relevant to the library team, which will review and decide on the PR/issue.
label
Relevant to the library team, which will review and decide on the PR/issue.
label
FCP to stabilize has finished.
📌 Commit 85d4bcbf5ab5bbb343c23ec3a3fcaf0982b4a4c0 has been approved by Mark-Simulacrum
It is now in the queue for this repository.
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
Er, actually, nightly is now 1.64.
@bors r-
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
This only stabilizes the base types, not the non-zero variants, since those have their own separate tracking issue and have not gone through FCP to stabilize.
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
📌 Commit d431338 has been approved by Mark-Simulacrum
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request
…r=Mark-Simulacrum
Stabilize core::ffi:c_* and rexport in std::ffi
This only stabilizes the base types, not the non-zero variants, since those have their own separate tracking issue and have not gone through FCP to stabilize.
bors added a commit to rust-lang-ci/rust that referenced this pull request
Rollup of 5 pull requests
Successful merges:
- rust-lang#97720 (Always create elided lifetime parameters for functions)
- rust-lang#98315 (Stabilize
core::ffi:c_*and rexport instd::ffi) - rust-lang#98705 (Implement
for<>lifetime binder for closures) - rust-lang#99126 (remove allow(rustc::potential_query_instability) in rustc_span)
- rust-lang#99139 (Give a better error when
x distfails for an optional tool)
Failed merges:
r? @ghost
@rustbot modify labels: rollup
95 tasks
flip1995 pushed a commit to flip1995/rust that referenced this pull request
Rollup of 5 pull requests
Successful merges:
- rust-lang#97720 (Always create elided lifetime parameters for functions)
- rust-lang#98315 (Stabilize
core::ffi:c_*and rexport instd::ffi) - rust-lang#98705 (Implement
for<>lifetime binder for closures) - rust-lang#99126 (remove allow(rustc::potential_query_instability) in rustc_span)
- rust-lang#99139 (Give a better error when
x distfails for an optional tool)
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Stabilize Stabilize core::ffi:c_* and rexport in std::fficore::ffi:c_* and re-export in std::ffi
Labels
Marks issues that should be documented in the release notes of the next release.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the library API team, which will review and decide on the PR/issue.