Fix in weak_count in Arc in the case the weak count is locked.

[jhjourdan]

In the case the weak count was locked, the weak_count function could
return usize::MAX. We need to test this condition manually.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

Thanks! Could a test like this also be added?

[RalfJung]

Shouldn't the fix rather be to retry until the lock is released?

[jhjourdan]

@RalfJung We know that if the weak count is locked, then it is necessary 1, because we use a CAS with 1 to acquire the lock.

[RalfJung]

I see. So whoever holds the lock did so just to make sure it doesn't get modified (as opposed to acquiring the lock in order to do modification themselves). Makes sense; it's about uniqueness checking, after all.

[jhjourdan]

@alexcrichton I added the test by mimicking the others in arc.rs. However, it does not seem to be ran when typing x.py test. What do I do wrong?

[alexcrichton]

Ah no worries, we do run the tests for the alloc crate so it'll get thrown in there.

@bors: r+

[bors]

📌 Commit 8416713 has been approved by alexcrichton

[bors]

⌛ Testing commit 8416713 with merge d361efa...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing d361efa to master...