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.

Sign up for GitHub

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

Jump to bottom

Stability attributes and kinds #12202

Closed
emberian opened this issue Feb 12, 2014 · 12 comments
Closed

Stability attributes and kinds #12202

emberian opened this issue Feb 12, 2014 · 12 comments
Labels
E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

Comments

@emberian
Copy link
Member

When a type is marked #[stable], no changes to it should break safe code. This also means that the set of kinds it fulfills, ignoring any potential type parameters, should never get smaller. For example, a type that is marked #[stable] that is Send should always continue to be so. If it isn't Freeze, but becomes Freeze, that is ok, because it's a completely transparent change to previous users.

(Note: if we extend the type system to include inverse bounds ("NonFreeze" etc), then adding kinds to the set of fulfilled kinds should also be disallowed)
@emberian
Copy link
Member Author

Nominating for 1.0, this is required to specify the stability of an API.

@nikomatsakis
Copy link
Contributor

cc me

@wycats
Copy link
Contributor

wycats commented Feb 12, 2014

Could this also be allowed as a crate attribute, and automatically apply to all public exports of that crate?

@emberian
Copy link
Member Author

@wycats that's #8962

@brson
Copy link
Contributor

brson commented Feb 13, 2014

This only matter if or when we have some tool for actually enforcing that stable APIs don't change.

@nikomatsakis
Copy link
Contributor

Note: if one labels a type with the expected builtin bounds, it wouldn't
make sense to permit anything other than those builtin bounds --- not
more nor less. i.e., even if you say that something is not sendable,
people may still send it unless it is truly not sendable.

@pnkfelix
Copy link
Member

We are not currently planning on having tooling to check/enforce stability attributes. It is currently "just" documentation. Thus this issue is not a 1.0 blocker.

@pnkfelix
Copy link
Member

(also, this bug may be more of an RFC than a bug ... its really hard to tell from the description what is actionable here, or the suggested course of action, if anything...)

@pnkfelix
Copy link
Member

(removing P-backcompat-libs since it is not a 1.0 blocker.)

Also, to whom it may concern: please do not tag issues with the P-tags; nominated them for consideration via I-nominated.

@emberian
Copy link
Member Author

Such a tool is the subject of #9060

On Thu, Feb 13, 2014 at 1:25 PM, Felix S Klock II
notifications@git.luolix.topwrote:

(removing P-backcompat-libs since it is not a 1.0 blocker.)

Also, to whom it may concern: please do not tag issues with the P-tags;
nominated them for consideration via I-nominated.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12202#issuecomment-35008989
.

@aturon
Copy link
Member

aturon commented Jun 10, 2014

Closing: there doesn't seem to be anything actionable here, especially given the issue #12203

@aturon aturon closed this as completed Jun 10, 2014
@emberian
Copy link
Member Author

I agree.

On Tue, Jun 10, 2014 at 10:51 AM, Aaron Turon notifications@github.com
wrote:

Closed #12202 #12202.

—
Reply to this email directly or view it on GitHub
#12202 (comment).

http://octayn.net/

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
@bors
Auto merge of rust-lang#12202 - iDawer:ide.sig_help-fix, r=lnicola
cc69536 
fix: don't panic at fully qualified call syntax in signature help

Closes  rust-lang#12200
Regressed from rust-lang#12082
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 8, 2024
@bors
Auto merge of rust-lang#12202 - y21:issue12199, r=Jarcho
ed74c22 
Avoid linting redundant closure when callee is marked `#[track_caller]`

Fixes rust-lang#12199

Not sure if there's a nicer way to detect functions marked `#[track_caller]` other than by just looking at its attributes 🤔

changelog: [`redundant_closure`]: [`redundant_closure_for_method_calls`]: avoid linting closures where the function being called is marked `#[track_caller]`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@wycats @brson @nikomatsakis @pnkfelix @emberian @aturon