SeqCst is unnecessary here.

SeqCst is unnecessary here.

Relaxed is enough here.

SeqCst is unnecessary.

Relaxed is enough to make sure this `swap` results in `true` only once.

No need for SeqCst. Release+Acquire is the right memory ordering for a
mutex.

SeqCst is unnecessary here.

SeqCst is unnecessary here.

SeqCst is unnecessary. Release+Acquire is the right ordering for a
mutex.

Relaxed is enough to ensure fetch_add(1) returns each integer exactly
once.

SeqCst is unnecessary. Release+Acquire is the right ordering for a
mutex.

The SeqCst wasn't synchronizing with anything. Relaxed is enough.

rustc is just one tool/executable, even if at the center of the toolchain

These assertions detect situations where a BCB node would have both a physical
counter and one or more in-edge counters/expressions.

For most BCBs that situation would indicate an implementation bug. However,
it's perfectly fine in the case of a BCB having an edge that loops back to
itself.

Given the complexity and risk involved in fixing the assertions, and the fact
that nothing relies on them actually being true, this patch just removes them
instead.

SeqCst isn't necessary in any of these cases.

Relaxed is enough to have fetch_add(1) return each value only once
(until it wraps around).

Relaxed memory ordering is fine because spawn()/join() already provides
all the synchronization we need.

Relaxed is enough here. Synchronization is done by the mutex.

The code

    let _ = fs::remove_dir_all(&dir);
    create_dir_all(&dir).unwrap();

is duplicated in 7 places. Let's introduce a helper.

…=petrochenkov

Ignore paths from expansion in `unused_qualifications`

If any of the path segments are from an expansion the lint is skipped currently, but a path from an expansion where all of the segments are passed in would not be. Doesn't seem that likely to occur but it could happen

Relax SeqCst ordering in standard library.

Every single SeqCst in the standard library is unnecessary. In all cases, Relaxed or Release+Acquire was sufficient.

As I [wrote](https://marabos.nl/atomics/memory-ordering.html#common-misconceptions) in my book on atomics:

> [..] when reading code, SeqCst basically tells the reader: "this operation depends on the total order of every single SeqCst operation in the program," which is an incredibly far-reaching claim. The same code would likely be easier to review and verify if it used weaker memory ordering instead, if possible. For example, Release effectively tells the reader: "this relates to an acquire operation on the same variable," which involves far fewer considerations when forming an understanding of the code.
>
> It is advisable to see SeqCst as a warning sign. Seeing it in the wild often means that either something complicated is going on, or simply that the author did not take the time to analyze their memory ordering related assumptions, both of which are reasons for extra scrutiny.

r? ````@Amanieu```` ````@joboet````

use more accurate terminology

rustc is just one tool/executable, even if at the center of the toolchain

…rors

make `type_flags(ReError) & HAS_ERROR`

Self-explanatory. `TypeVisitableExt::references_error(ReError)` incorrectly returned `false`.

coverage: Remove incorrect assertions from counter allocation

These assertions detect situations where a BCB node (in the coverage graph) would have both a physical counter and one or more in-edge counters/expressions.

For most BCBs that situation would indicate an implementation bug. However, it's perfectly fine in the case of a BCB having an edge that loops back to itself.

Given the complexity and risk involved in fixing the assertions, and the fact that nothing relies on them actually being true, this patch just removes them instead.

Fixes rust-lang#122738.

`````@rustbot````` label +A-code-coverage

…ng-usize-max, r=Nilstrieb

Add `usize::MAX` arg tests for Vec

Tests to prevent recurrence of the UB from the rust-lang#122760 issue.

I skipped the `with_capacity`, `drain`, `reserve`, etc. APIs because they actually had a good assortment of tests earlier in the same file.

r? Nilstrieb

…li-obk

Rename `hir::Let` into `hir::LetExpr`

As discussed on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Improve.20naming.20of.20.60ExprKind.3A.3ALet.60.3F).

r? `````@Zalathar`````

… r=onur-ozkan

compiletest: Introduce `remove_and_create_dir_all()` helper

The code

    let _ = fs::remove_dir_all(&dir);
    create_dir_all(&dir).unwrap();

is duplicated in 7 places. Let's introduce a helper.