The example had a potential race condition that would still pass the test.
If the thread which was supposed to modify it's own thread local was slower than the instruction to
modify in the main thread, then the test would pass even in case of a failure.
This is would be minor if the child thread was waited for since it check using an `assert_eq` for
the same thing, but vice versa.
However, if the `assert_eq` failed this would trigger a panic, which is not at all caught by the
example since the thread is not waited on.
Signed-off-by: benaryorg <binary@benary.org>
[NLL] Type check operations with pointer types
It seems these were forgotten about. Moving to `Rvalue::AddressOf` simplifies the coercions from references, but I want this to be fixed as soon as possible.
r? @pnkfelix
Fix C-variadic function printing
There is no longer a need to append the string `", ..."` to a functions
args as `...` is parsed as an argument and will appear in the functions
arguments.
Fixes: #58853
Use the correct stderr when testing libstd
When compiling the unit tests for libstd, there are two copies of `std` in existence, see [lib.rs](https://github.com/rust-lang/rust/blob/919cf42/src/libstd/lib.rs#L335-L341). This means there are two copies of everything, including thread local variable definitions. Before this PR, it's possible that libtest would configure a stderr sink in one of those copies, whereas the panic logic would inspect the sink in the other copy, resulting in libtest missing the relevant panic message. This PR makes sure that when testing, the panic logic always accesses the stderr sink from “realstd”, using the same logic that libtest uses.
```
error[E0004]: non-exhaustive patterns: type `X` is non-empty
--> file.rs:9:11
|
1 | / enum X {
2 | | A,
| | - variant not covered
3 | | B,
| | - variant not covered
4 | | C,
| | - variant not covered
5 | | }
| |_- `X` defined here
...
9 | match x {
| ^
|
= help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
error[E0004]: non-exhaustive patterns: `B` and `C` not covered
--> file.rs:11:11
|
1 | / enum X {
2 | | A,
3 | | B,
4 | | C,
| | - not covered
5 | | }
| |_- `X` defined here
...
11 | match x {
| ^ patterns `C` not covered
```
When a match expression doesn't have patterns covering every variant,
point at the enum's definition span. On a best effort basis, point at the
variant(s) that are missing. This does not handle the case when the missing
pattern is due to a field's enum variants:
```
enum E1 {
A,
B,
C,
}
enum E2 {
A(E1),
B,
}
fn foo() {
match E2::A(E1::A) {
E2::A(E1::B) => {}
E2::B => {}
}
//~^ ERROR `E2::A(E1::A)` and `E2::A(E1::C)` not handled
}
```
Unify look between match with no arms and match with some missing patterns.
Fix#37518.
Remove NodeId from even more HIR nodes
The next iteration of HirIdification (#57578).
Removes `NodeId` from:
- [x] `StructField`
- [x] `ForeignItem`
- [x] `Item`
- [x] `Pat`
- [x] `FieldPat`
- [x] `VariantData`
- [x] `ImplItemId` (replaces it with `HirId`)
- [x] `TraitItemId` (replaces it with `HirId`)
There is no longer a need to append the string `", ..."` to a functions
args as `...` is parsed as an argument and will appear in the functions
arguments.
Update toolchain to build NetBSD release
This allows us to remove the "allow old toolchains" flag we pass to
LLVM, ensuring that we'll be up to date when LLVM needs us to be!
This is a follow-up from https://github.com/rust-lang/rust/pull/58408 where NetBSD was explicitly whitelisted to allow older toolchains.
allow specifying attributes for tool lints
Needed for clippy to fix `unused_doc_comments` warnings that will be exposed by #57882 (and thus unblock it).
Have all methods of Filter and FilterMap use internal iteration
This PR changes `Filter::{next, next_back, count}` and `FilterMap::{next, next_back}` to all use internal iteration. The `next` and `next_back` methods are changed to directly forward to `try_for_each` and `try_rfold` respectively, using `Result` as the `Try` type. I think that's okay? Alternatively, I could change their implementations to use `LoopState` instead if there's any benefit in doing so.
r? @scottmcm
Set secure flags when opening a named pipe on Windows
Fixes https://github.com/rust-lang/rust/issues/42036, see also the previous attempt in https://github.com/rust-lang/rust/pull/44556.
Whether this is correct depends on if it is somehow possible to create a symlink to a named pipe, outside the named pipe filesystem (NPFS). But as far as I can tell that should be impossible.
Also fixes that `security_qos_flags(SECURITY_ANONYMOUS)` does not set the `SECURITY_SQOS_PRESENT` flag, and the incorrect documentation about the default value of `security_qos_flags`.
