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

Tracking Issue: fetch_nand #13226

Closed
alexcrichton opened this issue Mar 31, 2014 · 10 comments · Fixed by #49963
Closed

Tracking Issue: fetch_nand #13226

alexcrichton opened this issue Mar 31, 2014 · 10 comments · Fixed by #49963
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

alexcrichton commented Mar 31, 2014

Tracking issue for fetch_nand on integer atomics (it's stable for bool).

On android, it appears that these functions give the wrong answer. See #12964 (comment) for some analysis, and the relevant logs are:

    #[test]
    fn uint_nand() {
        let x = AtomicUint::new(0xf731);
        assert_eq!(x.fetch_nand(0x137f, SeqCst), 0xf731);
        assert_eq!(x.load(SeqCst), !(0xf731 & 0x137f));
    }

    #[test]
    fn int_nand() {
        let x = AtomicInt::new(0xf731);
        assert_eq!(x.fetch_nand(0x137f, SeqCst), 0xf731);
        assert_eq!(x.load(SeqCst), !(0xf731 & 0x137f));
    }
---- sync::atomics::test::int_nand stdout ----
    task 'sync::atomics::test::int_nand' failed at 'assertion failed: `(left == right) && (right == left)` (left: `78`, right: `-4914`)', /home/rustbuild/src/rust-buildbot/slave/auto-linux-64-x-android-t/build/src/libstd/sync/atomics.rs:1005

---- sync::atomics::test::uint_nand stdout ----
    task 'sync::atomics::test::uint_nand' failed at 'assertion failed: `(left == right) && (right == left)` (left: `78`, right: `4294962382`)', /home/rustbuild/src/rust-buildbot/slave/auto-linux-64-x-android-t/build/src/libstd/sync/atomics.rs:977  
@steveklabnik
Copy link
Member

Triage: i don't have android to test.

@steveklabnik
Copy link
Member

Triage: same as in 2015.

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@Mark-Simulacrum
Copy link
Member

I unfortunately do not have an android either, and after spending multiple hours trying to get an emulator setup I have decided to not try any more... the code below I believe is the test for this problem today. If someone has a working android version, and can test it, that would be great.

#![feature(core_intrinsics)]

use std::sync::atomic::{AtomicUsize, AtomicIsize};
use std::sync::atomic::Ordering::*;
use std::intrinsics::atomic_nand;

#[test]
fn uint_nand() {
    let mut x = AtomicUsize::new(0xf731);
    unsafe {
        assert_eq!(atomic_nand(x.get_mut() as *mut usize, 0x137f), 0xf731);
    }
    assert_eq!(x.load(SeqCst), !(0xf731 & 0x137f));
}

#[test]
fn int_nand() {
    let mut x = AtomicIsize::new(0xf731);
    unsafe {
        assert_eq!(atomic_nand(x.get_mut() as *mut isize, 0x137f), 0xf731);
    }
    assert_eq!(x.load(SeqCst), !(0xf731 & 0x137f));
}

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 20, 2017
@Mark-Simulacrum Mark-Simulacrum added C-bug Category: This is a bug. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 29, 2017
@Dushistov
Copy link
Contributor

Dushistov commented Feb 8, 2018

@Mark-Simulacrum

I unfortunately do not have an android either, and after spending multiple hours trying to > get an emulator setup I have decided to not try any more... the code below I believe is
the test for this problem today. If someone has a working android version, and can test it, > that would be great.

I've run it on android phone (cargo test --target=arm-linux-androideabi/rustc 1.25.0-nightly (bd98fe0c0 2018-02-06)),
all looks ok:

$ cargo test --target=arm-linux-androideabi
   Compiling android-atomic-13226 v0.1.0 (file:///home/evgeniy/projects/rust-infra/bugs/android-atomic-13226)
    Finished dev [unoptimized + debuginfo] target(s) in 0.88 secs
     Running target/arm-linux-androideabi/debug/deps/android_atomic_13226-a6d2087ae9be837c
Current directory: /home/evgeniy/projects/rust-infra/bugs/android-atomic-13226
/home/evgeniy/projects/rust-infra/bugs/android-atomic-13226/target/arm...26-a6d2087ae9be837c: 1 file pushed. 2.4 MB/s (5396036 bytes in 2.134s

running 2 tests
test uint_nand ... ok
test int_nand ... ok

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

ADB_SUCCESS!!!!!!!!!!!!!!
ADB_SUCCESS!!!!!!!!!!!!!!
[evgeniy@15inch android-atomic-13226]$ adb shell
shell@hammerhead:/ $ uname -a
Linux localhost 3.4.0-gcf10b7e #1 SMP PREEMPT Mon Sep 19 22:14:08 UTC 2016 armv7l

@Mark-Simulacrum
Copy link
Member

@alexcrichton looks like we may be able to enable these on Android.

@alexcrichton
Copy link
Member Author

Hurray!

@Mark-Simulacrum Mark-Simulacrum added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed C-bug Category: This is a bug. O-android Operating system: Android labels Feb 9, 2018
@Mark-Simulacrum Mark-Simulacrum changed the title fetch_nand is not implemented for Atomic{Int,Uint} Tracking Issue: fetch_nand Feb 9, 2018
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Feb 9, 2018
cc rust-lang#13226 (the tracking issue)
kennytm added a commit to kennytm/rust that referenced this issue Feb 10, 2018
…richton

Add fetch_nand to atomics

I think this is all fine but I have little familiarity with the atomic code (or libcore in general) so I may have accidentally done something wrong here...

cc rust-lang#13226 (the tracking issue)
@SimonSapin
Copy link
Contributor

SimonSapin commented Mar 17, 2018

It looks like the only issue (incorrect behavior on Android) has been resolved.

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Mar 17, 2018

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Mar 17, 2018
@rfcbot
Copy link

rfcbot commented Mar 18, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Mar 18, 2018
@rfcbot
Copy link

rfcbot commented Mar 28, 2018

The final comment period is now complete.

bors added a commit that referenced this issue Apr 16, 2018
stabilize fetch_nand

This closes #13226 and makes `Atomic*.fetch_nand` stable.
lnicola pushed a commit to lnicola/rust that referenced this issue Jun 23, 2024
Currently, rust-analyzer highlights the entire region when a `cfg` is
inactive (e.g. `#[cfg(windows)]` on a Linux machine). However,
unlinked files only highlight the first three characters of the file.

This was introduced in rust-lang#8444, but users have repeatedly found
themselves with no rust-analyzer support for a file and unsure
why (see e.g. rust-lang#13226 and the intentionally prominent pop-up added in
PR rust-lang#14366).

(Anecdotally, we see this issue bite our users regularly, particularly
people new to Rust.)

Instead, highlight the entire inactive file, but mark it as all as
unused. This allows users to hover and run the quickfix from any line.

Whilst this is marginally more prominent, it's less invasive than a
pop-up, and users do want to know why they're getting no rust-analyzer
support in certain files.
lnicola pushed a commit to lnicola/rust that referenced this issue Jun 23, 2024
…eykril

fix: Highlight unlinked files consistently with inactive files

Currently, rust-analyzer highlights the entire region when a `cfg` is inactive (e.g. `#[cfg(windows)]` on a Linux machine). However, unlinked files only highlight the first three characters of the file.

This was introduced in rust-lang#8444, but users have repeatedly found themselves with no rust-analyzer support for a file and unsure why (see e.g. rust-lang#13226 and the intentionally prominent pop-up added in PR rust-lang#14366).

(Anecdotally, we see this issue bite our users regularly, particularly people new to Rust.)

Instead, highlight the entire inactive file, but mark it as all as unused. This allows users to hover and run the quickfix from any line.

Whilst this is marginally more prominent, it's less invasive than a pop-up, and users do want to know why they're getting no rust-analyzer support in certain files.

Before (note the subtle grey underline is only at the beginning of the first line):

![Screenshot 2024-06-05 at 5 41 17 PM](https://github.com/rust-lang/rust-analyzer/assets/70800/96f5d778-612e-4838-876d-35d9647fe2aa)

After (user can hover and fix from any line):

![Screenshot 2024-06-05 at 5 42 13 PM](https://github.com/rust-lang/rust-analyzer/assets/70800/6af90b79-018c-42b9-b3c5-f497de2ccbff)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants