Querify whether a type has structural equality (Take 2)
Alternative to #72177.
Unlike in #72177, this helper method works for all types, falling back to a query for `TyKind::Adt`s that determines whether the `{Partial,}StructuralEq` traits are implemented.
This is my preferred interface for this method. I think this is better than just documenting that the helper only works for ADTs. If others disagree, we can just merge #72177 with the fixes applied. This has already taken far too long.
Clarify the behaviour of Pattern when used with methods like str::contains
Fixes#45507.
I used the previous work by @Emerentius (thanks !), added a paragraph and checked the links (they work for me but I'm not against someone else checking them too).
Add needs-sanitizer-{address,leak,memory,thread} directive indicating
that test requires target with support for specific sanitizer.
This is an addition to the existing needs-sanitizer-support directive
indicating that test requires a sanitizer runtime library.
These lead to inference regressions (mostly in tests) in code that looks
like:
let socket = std::net::SocketAddrV4::new(std::net::Ipv4Addr::new(127, 0, 0, 1), 8080);
assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
That compiles as of stable 1.44.0 but fails in beta with:
error[E0284]: type annotations needed
--> src/main.rs:3:41
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
| ^^^^^ cannot infer type for type parameter `F` declared on the associated function `parse`
|
= note: cannot satisfy `<_ as std::str::FromStr>::Err == _`
help: consider specifying the type argument in the method call
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse::<F>().unwrap());
|
Previously, some doctests were spawning new threads and joining them to
indicate that a particular call should panic; this hurt readability, so
the tests have been adjusted to simply call the method and use the
`should_panic` marker.
This helper method works for all types, falling back to a query for
`TyKind::Adt`s to determine whether the implement the
`{Partial,}StructuralEq` traits.
Allow inference regions when relating consts
As first noticed by @eddyb, `super_relate_consts` doesn't need to check for inference vars since `eval` does it already (and handles lifetimes correctly by erasing them).
Fixes#73050
r? @oli-obk
expand: More precise locations for expansion-time lints
First commit: a macro expansion doesn't have a `NodeId` associated with it, but it has a parent `DefId` which we can use for linting.
The observable effect is that lints associated with macro expansions can now be `allow`ed at finer-grained level than whole crate.
Second commit: each macro definition has a `NodeId` which we can use for linting, unless that macro definition was decoded from other crate.
Enable AVR as a Tier 3 target upstream
Tracking issue: #44052.
Things intentionally left out of the initial upstream:
* The `target_cpu` flag
I have made the cleanup suggestions by @jplatte and @jplatte in 043550d9db.
Anybody feel free to give the branch a test and see how it fares, or make suggestions on the code patch itself.
Add comment about LocalDefId -> DefId
Now there are instructions on how to convert back and forth on both
structs, not just one.
See also https://github.com/rust-lang/rust/pull/73076
r? @lcnr
Add various Zulip notifications for prioritization
Adapts `triagebot.toml` for rust-lang/triagebot#616 and adds various Zulip notifications for the Prioritization WG workflow.
We should also add indications about the procedure for handling those events, cc @rust-lang/wg-prioritization.
r? @spastorino
This should be merged as soon as possible after rust-lang/triagebot#616 is merged, cc @Mark-Simulacrum
Provide suggestion to convert numeric op LHS rather than unwrapping RHS
Given a code
```rust
fn foo(x: u8, y: u32) -> bool {
x > y
}
fn main() {}
```
it could be more helpful to provide a suggestion to do "u32::from(x)"
rather than "y.try_into().unwrap()", since the latter may panic.
We do this by passing the LHS of a binary expression up the stack into
the coercion checker.
Closes#73145
std: Enable atomic.fence emission on wasm32
This commit removes the `#[cfg]` guards in `atomic::fence` on wasm
targets. Since these guards were originally added the upstream wasm
specification for threads gained an `atomic.fence` instruction, so LLVM
no longer panics on these intrinsics.
Although there aren't a ton of tests in-repo for this right now I've
tested locally and all of these fences generate `atomic.fence`
instructions in wasm.
Closes#65687Closes#72997
Fix #[thread_local] statics as asm! sym operands
The `asm!` RFC specifies that `#[thread_local]` statics may be used as `sym` operands for inline assembly.
This also fixes a regression in the handling of `#[thread_local]` during monomorphization which caused link-time errors with multiple codegen units, most likely introduced by #71192.
r? @oli-obk
