Skip to content

stabilize atomics (now atomic) #16258

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

Merged
merged 1 commit into from
Aug 6, 2014
Merged

Conversation

aturon
Copy link
Member

@aturon aturon commented Aug 4, 2014

This commit stabilizes the std::sync::atomics module, renaming it to
std::sync::atomic to match library precedent elsewhere, and tightening
up behavior around incorrect memory ordering annotations.

The vast majority of the module is now stable. However, the
AtomicOption type has been deprecated, since it is essentially unused
and is not truly a primitive atomic type. It will eventually be replaced
by a higher-level abstraction like MVars.

Due to deprecations, this is a:

[breaking-change]

This commit stabilizes the `std::sync::atomics` module, renaming it to
`std::sync::atomic` to match library precedent elsewhere, and tightening
up behavior around incorrect memory ordering annotations.

The vast majority of the module is now `stable`. However, the
`AtomicOption` type has been deprecated, since it is essentially unused
and is not truly a primitive atomic type. It will eventually be replaced
by a higher-level abstraction like MVars.

Due to deprecations, this is a:

[breaking-change]
bors added a commit that referenced this pull request Aug 6, 2014
This commit stabilizes the `std::sync::atomics` module, renaming it to
`std::sync::atomic` to match library precedent elsewhere, and tightening
up behavior around incorrect memory ordering annotations.

The vast majority of the module is now `stable`. However, the
`AtomicOption` type has been deprecated, since it is essentially unused
and is not truly a primitive atomic type. It will eventually be replaced
by a higher-level abstraction like MVars.

Due to deprecations, this is a:

[breaking-change]
@bors bors closed this Aug 6, 2014
@bors bors merged commit 68bde0a into rust-lang:master Aug 6, 2014
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Jan 31, 2015
These methods were intended to be stable as of rust-lang#16258 but the tags have since
been lost in various refactorings. This commit re-adds the `#[stable]`
attributes to each of these functions.
Manishearth added a commit to Manishearth/rust that referenced this pull request Feb 2, 2015
…, r=huonw

 These methods were intended to be stable as of rust-lang#16258 but the tags have since
been lost in various refactorings. This commit re-adds the `#[stable]`
attributes to each of these functions.
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Feb 2, 2015
These methods were intended to be stable as of rust-lang#16258 but the tags have since
been lost in various refactorings. This commit re-adds the `#[stable]`
attributes to each of these functions.
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 8, 2024
internal: Rewrite `ImportMap::search_dependencies`

Second attempt, this time with a lot of perf improvements

Fixes rust-lang/rust-analyzer#16080
Fixes rust-lang/rust-analyzer#16074
Fixes rust-lang/rust-analyzer#15845

The main bottleneck for flyimport completions are now import path calculation and completion item rendering.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants