bors [Thu, 24 Mar 2022 10:24:54 +0000 (10:24 +0000)]
Auto merge of #91030 - estebank:trait-bounds-are-tricky-2, r=oli-obk
Properly track `ImplObligations`
Instead of probing for all possible `impl`s that could have caused an
`ImplObligation`, keep track of its `DefId` and obligation spans for
accurate error reporting.
Esteban Kuber [Wed, 13 Oct 2021 13:58:41 +0000 (13:58 +0000)]
Properly track `ImplObligation`s
Instead of probing for all possible impls that could have caused an
`ImplObligation`, keep track of its `DefId` and obligation spans for
accurate error reporting.
bors [Wed, 23 Mar 2022 23:02:17 +0000 (23:02 +0000)]
Auto merge of #95250 - matthiaskrgr:rollup-ma4zl69, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #94249 (Better errors when a Copy impl on a Struct is not self-consistent)
- #95069 (Fix auto traits in rustdoc)
- #95221 (interpret/memory: simplify check_and_deref_ptr)
- #95225 (remove `[async output]` from `impl Future` pretty-printing)
- #95238 (Stop emitting E0026 for struct enums with underscores)
Matthias Krüger [Wed, 23 Mar 2022 21:13:25 +0000 (22:13 +0100)]
Rollup merge of #95225 - compiler-errors:impl-future-generator-ty, r=oli-obk
remove `[async output]` from `impl Future` pretty-printing
self-explanatory, guess it's not as helpful as I thought when I added it 4 months ago
re https://github.com/rust-lang/rust/issues/95089#issuecomment-1075482851
Matthias Krüger [Wed, 23 Mar 2022 21:13:24 +0000 (22:13 +0100)]
Rollup merge of #95221 - RalfJung:check_and_deref_ptr, r=oli-obk
interpret/memory: simplify check_and_deref_ptr
*Finally* I saw a way to make this code simpler. The odd preprocessing in `let ptr_or_addr =` has bothered me since forever, but it actually became unnecessary in the last provenance refactoring. :)
This also leads to slightly more explicit error messages as a nice side-effect. :tada:
Matthias Krüger [Wed, 23 Mar 2022 21:13:22 +0000 (22:13 +0100)]
Rollup merge of #94249 - compiler-errors:better-copy-errors, r=davidtwco
Better errors when a Copy impl on a Struct is not self-consistent
As discovered in a Zulip thread with `@nnethercote` and `@Mark-Simulacrum,` it's not immediately obvious why a field on an ADT doesn't implement `Copy`. This PR attempts to give slightly more detailed information by spinning up a fulfillment context to try to dig down and discover transitive fulfillment errors that cause `is_copy_modulo_regions` to fail on a ADT field.
The error message still kinda sucks, but should only show up in the case that an existing error message was totally missing... so I think it's a good compromise for now?
bors [Wed, 23 Mar 2022 16:53:47 +0000 (16:53 +0000)]
Auto merge of #95220 - rust-lang:notriddle/ast-validation-semicolon, r=Dylan-DPC
diagnostics: do not suggest `fn foo({ <body> }`
Instead of suggesting that the body always replace the last character on the line, presuming it must be a semicolon, the parser should instead check what the last character is, and append the body if it is anything else.
bors [Wed, 23 Mar 2022 14:04:38 +0000 (14:04 +0000)]
Auto merge of #94901 - fee1-dead:destructable, r=oli-obk
Rename `~const Drop` to `~const Destruct`
r? `@oli-obk`
Completely switching to `~const Destructible` would be rather complicated, so it seems best to add it for now and wait for it to be backported to beta in the next release.
The rationale is to prevent complications such as #92149 and #94803 by introducing an entirely new trait. And `~const Destructible` reads a bit better than `~const Drop`. Name Bikesheddable.
bors [Wed, 23 Mar 2022 06:01:48 +0000 (06:01 +0000)]
Auto merge of #95173 - m-ou-se:sys-locks-module, r=dtolnay
Move std::sys::{mutex, condvar, rwlock} to std::sys::locks.
This cleans up the the std::sys modules a bit by putting the locks in a single module called `locks` rather than spread over the three modules `mutex`, `condvar`, and `rwlock`. This makes it easier to organise lock implementations, which helps with https://github.com/rust-lang/rust/issues/93740.
Dylan DPC [Wed, 23 Mar 2022 02:05:34 +0000 (03:05 +0100)]
Rollup merge of #95222 - RalfJung:validity, r=Dylan-DPC
interpret/validity: improve clarity
I was confused by my own (ancient) comment in `validity.rs` so I figured I'd clarify. (And I don't think ZST-ness is relevant at all inside that branch, no idea where that comment comes from.)
Dylan DPC [Wed, 23 Mar 2022 02:05:33 +0000 (03:05 +0100)]
Rollup merge of #95219 - ojeda:update-alloc-no-oom-handling-test, r=Dylan-DPC
Modernize `alloc-no-oom-handling` test
- The edition should be 2021 to avoid warnings.
- The `external_crate` feature was removed in commit 45bf1ed1a112 ("rustc: Allow changing the default allocator").
Note that commit d620ae10709c ("Auto merge of #84266") removed the old test, but the new one introduced passed the `--cfg` like in the old one.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
This is intended to align this test to the new `no_rc` and `no_sync` ones being added in https://github.com/rust-lang/rust/pull/89891, but it makes sense on its own too.
Dylan DPC [Wed, 23 Mar 2022 02:05:32 +0000 (03:05 +0100)]
Rollup merge of #95212 - TaKO8Ki:replace-this-clone-with-this-create-snapshot-for-diagnostic, r=Dylan-DPC
Replace `this.clone()` with `this.create_snapshot_for_diagnostic()`
Use [`create_snapshot_for_diagnostic`](https://github.com/rust-lang/rust/blob/cd119057160cedea245aa2679add56723f3dc784/compiler/rustc_parse/src/parser/diagnostics.rs#L214-L223) I implemented in https://github.com/rust-lang/rust/pull/94731 instead of `this.clone()` to avoid duplicate errors about unclosed delims being emitted when the `Parser` is dropped.
Dylan DPC [Wed, 23 Mar 2022 02:05:31 +0000 (03:05 +0100)]
Rollup merge of #94713 - clarfonthey:is_char_surrogate, r=scottmcm
Add u16::is_utf16_surrogate
Right now, there are methods in the standard library for encoding and decoding UTF-16, but at least for the moment, there aren't any methods specifically for `u16` to help work with UTF-16 data. Since the full logic already exists, this wouldn't really add any code, just expose what's already there.
This method in particular is useful for working with the data returned by Windows `OsStrExt::encode_wide`. Initially, I was planning to also offer a `TryFrom<u16> for char`, but decided against it for now. There is plenty of code in rustc that could be rewritten to use this method, but I only checked within the standard library to replace them.
I think that offering more UTF-16-related methods to u16 would be useful, but I think this one is a good start. For example, one useful method might be `u16::is_pattern_whitespace`, which would check if something is the Unicode `Pattern_Whitespace` category. We can get away with this because all of the `Pattern_Whitespace` characters are in the basic multilingual plane, and hence we don't need to check for surrogates.
Dylan DPC [Wed, 23 Mar 2022 02:05:28 +0000 (03:05 +0100)]
Rollup merge of #92955 - llogiq:cloned-side-effect-doc, r=yaahc
add perf side effect docs to `Iterator::cloned()`
Now that #90209 has been closed, as the current state of affairs is neither here nor there, this at least adds a paragraph + example on what to expect performance-wise and how to deal with it to the .cloned() docs.
Dylan DPC [Wed, 23 Mar 2022 02:05:28 +0000 (03:05 +0100)]
Rollup merge of #91608 - workingjubilee:fold-neon-fp, r=nagisa,Amanieu
Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
I am... pretty sure no one is relying on this.
An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.
Michael Howell [Tue, 22 Mar 2022 22:29:07 +0000 (15:29 -0700)]
diagnostics: do not suggest `fn foo({ <body> }`
Instead of suggesting that the body always replace the last character on the
line, presuming it must be a semicolon, the parser should instead check what
the last character is, and append the body if it is anything else.
Jubilee Young [Sat, 4 Dec 2021 01:56:59 +0000 (17:56 -0800)]
Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
As its name suggests, `TokenTreeOrTokenTreeSlice` is either a single
`TokenTree` or a slice of them. It has methods `len` and `get_tt` that
let it be treated much like an ordinary slice. The reason it isn't an
ordinary slice is that for `TokenTree::Delimited` the open and close
delimiters are represented implicitly, and when they are needed they are
constructed on the fly with `Delimited::{open,close}_tt`, rather than
being present in memory.
This commit changes `Delimited` so the open and close delimiters are
represented explicitly. As a result, `TokenTreeOrTokenTreeSlice` is no
longer needed and `MatcherPos` and `MatcherTtFrame` can just use an
ordinary slice. `TokenTree::{len,get_tt}` are also removed, because they
were only needed to support `TokenTreeOrTokenTreeSlice`.
The change makes the code shorter and a little bit faster on benchmarks
that use macro expansion heavily, partly because `MatcherPos` is a lot
smaller (less data to `memcpy`) and partly because ordinary slice
operations are faster than `TokenTreeOrTokenTreeSlice::{len,get_tt}`.
bors [Tue, 22 Mar 2022 16:24:50 +0000 (16:24 +0000)]
Auto merge of #94693 - nnethercote:parser-inlining, r=petrochenkov
Inline some parser functions
Some crates that do a lot of complex declarative macro expansion spend a lot of time parsing (and reparsing) tokens. These commits inline some functions for some minor speed wins.
bors [Tue, 22 Mar 2022 05:48:49 +0000 (05:48 +0000)]
Auto merge of #95158 - sunfishcode:sunfishcode/windows-8, r=joshtriplett
Preserve the Windows `GetLastError` error in `HandleOrInvalid`.
In the `TryFrom<HandleOrInvalid> for OwnedHandle` and
`TryFrom<HandleOrNull> for OwnedHandle` implemenations, `forget` the
owned handle on the error path, to avoid calling `CloseHandle` on an
invalid handle. It's harmless, except that it may overwrite the
thread's `GetLastError` error.
bors [Mon, 21 Mar 2022 19:23:00 +0000 (19:23 +0000)]
Auto merge of #95180 - matthiaskrgr:rollup-ai1ch2s, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #95074 (Refactor: use `format-args-capture` and remove unnecessary nested if blocks in some parts of `rust_passes`)
- #95085 (Return err instead of ICE)
- #95116 (Add needs-* directives to many tests)
- #95129 (Remove animation on source sidebar)
- #95166 (Update the unstable book with the new `values()` form of check-cfg)
- #95175 (move `adt_const_params` to its own tracking issue)
Matthias Krüger [Mon, 21 Mar 2022 18:48:31 +0000 (19:48 +0100)]
Rollup merge of #95085 - ouz-a:master5, r=jackh726
Return err instead of ICE
Having `escaping_bound_vars` results in ICE when trying to create `ty::Binder::dummy`, to avoid it we return err like the line above. I think this requires a more sophisticated fix, I would love to investigate if mentorship is available 🤓
bors [Mon, 21 Mar 2022 15:17:08 +0000 (15:17 +0000)]
Auto merge of #95169 - Smittyvb:union-test-ub, r=bjorn3
Don't run UB in test suite
This splits `ui/unsafe/union.rs` to make it so only the non-UB parts are run. It also means we can do more testing of the location of error messages (which are a bit different with the THIR unsafety checker). `union-modification.rs` has no UB (according to Miri), and `union.rs` has errors (but would have UB if not for those errors).
By putting them in `TtParser`, we can reuse them for every rule in a
macro. With that done, they can be `SmallVec` instead of `Vec`, and this
is a performance win because these vectors are hot and `SmallVec`
operations are a bit slower due to always needing an "inline or heap?"
check.
This type was a small performance win for `html5ever`, which uses a
macro with hundreds of very simple rules that don't contain any
metavariables. But this type is complicated (extra lifetimes) and
perf-neutral for macros that do have metavariables.
This commit removes `MatcherPosHandle`, simplifying things a lot. This
increases the allocation rate for `html5ever` and similar cases a bit,
but makes things easier for follow-up changes that will improve
performance more than what we lost here.
Dan Gohman [Sun, 20 Mar 2022 22:37:31 +0000 (15:37 -0700)]
Preserve the Windows `GetLastError` error in `HandleOrInvalid`.
In the `TryFrom<HandleOrInvalid> for OwnedHandle` and
`TryFrom<HandleOrNull> for OwnedHandle` implemenations, `forget` the
owned handle on the error path, to avoid calling `CloseHandle` on an
invalid handle. It's harmless, except that it may overwrite the
thread's `GetLastError` error.
projects / rust.git / log