add 'fn write_u16s' to Memory
Added new function `Memory::write_u16s`. Needed in `MIRI` for implementing helper function to write wide_str to memory (for Windows).
Rollup of 5 pull requests
Successful merges:
- #68004 (permit negative impls for non-auto traits)
- #70385 (Miri nits: comment and var name improvement)
- #70411 (Fix for #62691: use the largest niche across all fields)
- #70417 (parser: recover on `...` as a pattern, suggesting `..`)
- #70424 (simplify match stmt)
Failed merges:
r? @ghost
simplify match stmt
We actually have a surprising amount of
```rust
match expr {
$($p:pat)|+ => true,
_ => false,
}
```
While I would prefer this to be replaced with `matches!`, most cases are
fairly readable anyway so we can just let them be for now.
Fix for #62691: use the largest niche across all fields
fixes#62691
(The second commit is a small optimization but it makes the code less pretty and i don't know if it is worth it.)
permit negative impls for non-auto traits
This is a prototype impl that extends `impl !Trait` beyond auto traits. It is not integrated with coherence or anything else, and hence only serves to prevent downstream impls (but not to allow downstream crates to rely on the absence of such impls for coherence purposes).
Fixes https://github.com/rust-lang/rust/issues/66544
TODO:
- [x] need a test that you can't rely on negative impls for coherence purposes
- [x] test that negative impls cannot specialize positive ones
- [x] test that positive impls cannot specialize negative ones
- [x] extend negative impl to `Clone` in order to fully fix#66544
- [x] and maybe make `CoerceUnsized` unsafe? -- that problem is now split out into https://github.com/rust-lang/rust/issues/68015
- [x] introduce feature flag and prepare a write-up
- [x] improve diagnostics?
They used to be covered by `optin_builtin_traits` but negative impls
are now applicable to all traits, not just auto traits.
This also adds docs in the unstable book for the current state of auto traits.
Currently, there are three fields in `ModuleConfig` that dictate
how object files are emitted: `emit_obj`, `obj_is_bitcode`, and
`embed_bitcode`.
Some of the combinations of these fields are nonsensical, in particular
having both `obj_is_bitcode` and `embed_bitcode` true at the same time.
Also, currently:
- we needlessly emit and then delete a bytecode file if `obj_is_bitcode`
is true but `emit_obj` is false;
- we needlessly embed bitcode in the LLVM module if `embed_bitcode` is
true and `emit_obj` is false.
This commit combines the three fields into one, with a new type
`EmitObj` (and the auxiliary `BitcodeSection`) which can encode five
different possibilities.
In the old code, `set_flags` would set `obj_is_bitcode` and
`embed_bitcode` on all three of the configs (`modules`, `allocator`,
`metadata`) if the relevant other conditions were met, even if no object
code needed to be emitted for one or more of them. Whereas
`start_async_codegen` would set `emit_obj`, but only for those configs
that need it.
In the new code, `start_async_codegen` does all the work of setting
`emit_obj`, and it only does that for the configs that need it.
`set_flags` no longer sets anything related to object file emission.
Tweak chained operators diagnostic
Use more selective spans
Improve suggestion output
Be more selective when displaying suggestions
Silence some knock-down type errors
r? @Centril
