Auto merge of #71556 - Dylan-DPC:rollup-9ll4shr, r=Dylan-DPC
Rollup of 7 pull requests
Successful merges:
- #69041 (proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`)
- #69813 (Implement BitOr and BitOrAssign for the NonZero integer types)
- #70712 (stabilize BTreeMap::remove_entry)
- #71168 (Deprecate `{Box,Rc,Arc}::into_raw_non_null`)
- #71544 (Replace filter_map().next() calls with find_map())
- #71545 (Fix comment in docstring example for Error::kind)
- #71548 (Add missing Send and Sync impls for linked list Cursor and CursorMut.)
Rollup merge of #71168 - SimonSapin:into_raw_non_null, r=Amanieu
Deprecate `{Box,Rc,Arc}::into_raw_non_null`
Per ongoing FCP at https://github.com/rust-lang/rust/issues/47336#issuecomment-586589016
See also https://github.com/rust-lang/rust/issues/47336#issuecomment-614054164
Rollup merge of #69813 - thomcc:nonzero-bitor, r=Amanieu
Implement BitOr and BitOrAssign for the NonZero integer types
This provides overloaded operators for `NonZero$Int | NonZero$Int`, `NonZero$Int | $Int`, and `$Int | NonZero$Int`. It also provides `BitOrAssign` where `self` is `NonZero$Int`, for symmetry.
It's a pretty small conceptual addition, but is good becasue but avoids a case where the operation is obviously sound, but you'd otherwise need unsafe to do it.
In crates trying to minimize `unsafe` usage, this is unfortunate and makes working with `NonZero` types often not worth it, even if the operations you're doing are clearly sound.
I've marked these as stable as I've been told in the past that trait impls are automatically stable. I'm happy to change it to unstable if this wasn't correct information.
I'm not entirely confident what version I should have put down, so I followed https://www.whatrustisit.com. Hopefully it's correct for this.
Apologies in advance if this has come up before, but I couldn't find it.
Rollup merge of #69041 - petrochenkov:stabmodispan, r=Amanieu
proc_macro: Stabilize `Span::resolved_at` and `Span::located_at`
Introduced in https://github.com/rust-lang/rust/pull/47149.
Part of https://github.com/rust-lang/rust/issues/54725.
Motivation: https://github.com/rust-lang/rust/pull/68716#issuecomment-583918919.
Identifiers in proc macros may want to inherit span locations for diagnostics from one tokens (e.g. some tokens from the macro input), but resolve those identifiers from some different location (e.g. from the macro's definition site).
This becomes especially important when multiple resolution locations become available with stabilization of [`Span::mixed_site`](https://github.com/rust-lang/rust/pull/68716).
Why I think this is the right API for setting span's location and hygiene - https://github.com/rust-lang/rust/pull/69041#issuecomment-586644778.
Auto merge of #71549 - Dylan-DPC:rollup-j6jlp9l, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #71364 (Ignore -Zprofile when building compiler_builtins)
- #71494 (Fix span of while (let) expressions after lowering)
- #71517 ( Quick and dirty fix of the unused_braces lint)
- #71523 (Take a single root node in range_search)
- #71533 (Revert PR 70566 for const validation fix)
Rollup merge of #71533 - pnkfelix:revert-70566-for-const-validation-fix, r=Dylan-DPC
Revert PR 70566 for const validation fix
This is a port of PR #71441 but ported to the master branch, as discussed in [yesterday's T-compiler meeting](https://zulip-archive.rust-lang.org/131828tcompiler/88751weeklymeeting2020042354818.html#195065903)
Rollup merge of #71523 - Mark-Simulacrum:alloc-inline-dup, r=Amanieu
Take a single root node in range_search
The unsafe code can be justified within range_search, as it makes sure to not
overlap the returned references, but from the callers perspective it's an
entirely safe algorithm and there's no need for the caller to know about the
duplication.
Rollup merge of #71517 - flip1995:unused_braces_hack, r=oli-obk
Quick and dirty fix of the unused_braces lint
cc @lcnr
Adresses #70814
This at least prevents lint output, if no span is available. Even though this also prevents the `unused_parens` lint from emitting, when the `DUMMY_SP` is used there, but I think that should be ok, since error messages without a span are quite useless anyway.
Clippy CI is currently blocked on this bug. If this quick and dirty fix should be rejected, I could try to work around this in Clippy.
Rollup merge of #71494 - flip1995:while_let_span, r=petrochenkov
Fix span of while (let) expressions after lowering
Credit goes to @alex-700 who found this while trying to fix a suggestion in Clippy.
While `if`, `try`, `for` and `await` expressions get the span of the original expression when desugared, `while` loops got the span of the scrutinee, which lead to weird code, when building the suggestion, that randomly worked: https://github.com/rust-lang/rust-clippy/pull/5511/files#diff-df4e9d2bf840a5f2e3b580bef73da3bcR106-R108
I'm wondering, if `DesugaringKind` should get a variant `WhileLoop` and instead of using the span of the `ast::ExprKind::While` expr directly, a new span with `self.mark_span_with_reason` should be used, like it is done with `for` loops.
There was some fallout, but I think that is acceptable. If not, I need some help to find out where this can be fixed.
Rollup merge of #71364 - Amanieu:zprofile_compiler_builtins, r=cramertj
Ignore -Zprofile when building compiler_builtins
#70846 made the `compiler_builtins` crate ignore the default codegen-units setting and instead always split each function into a different codegen unit.
This unfortunately breaks `-Zprofile` which requires a single codegen unit per crate (see #71283). You can notice this when building with `cargo -Zbuild-std` and `RUSTFLAGS` containing `-Zprofile`.
This PR works around this issue by just ignoring `-Zprofile` for the `compiler-builtins` crate.
Auto merge of #71458 - ecstatic-morse:bootstrap-cfg-doc, r=Mark-Simulacrum
Set `--cfg bootstrap` for stage0 rustdoc
Resolves #71455.
With this patch, running `./x.py doc --stage 0 src/libstd` with a clean `build` dir successfully outputs docs for `core`, `alloc` and `std` in under a minute. This kind of turnaround for viewing small changes to the standard library documentation is quite nice, and I think we should endeavour to keep it working. I'm not sure how involved that would be though.
Rollup merge of #71330 - ecstatic-morse:const-qualif-lazy, r=oli-obk
Only run dataflow for const qualification if type-based check would fail
This is the optimization discussed in https://github.com/rust-lang/rust/issues/49146#issuecomment-614012476. We wait for `Qualif::in_any_value_of_ty` to return `true` before running dataflow. For bodies that deal mostly with primitive types, this will avoid running dataflow at all during const qualification.
This also removes the `BitSet` used to cache `in_any_value_of_ty` for each local, which was only necessary for an old version of #64470 that also handled promotability.
Mark Rousskov [Fri, 24 Apr 2020 17:22:52 +0000 (13:22 -0400)]
Take a single root node in range_search
The unsafe code can be justified within range_search, as it makes sure to not
overlap the returned references, but from the callers perspective it's an
entirely safe algorithm and there's no need for the caller to know about the
duplication.
Auto merge of #71509 - Dylan-DPC:rollup-n8s37rm, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #71235 (Tweak `'static` suggestion code)
- #71318 (miri-unleash tests: ensure they fire even with 'allow(const_err)')
- #71428 (Let compiletest recognize gdb 10.x)
- #71475 (Miri Frame: use mir::Location to represent position in function)
- #71476 (more compact way to adjust test sizes for Miri)
Rollup merge of #71475 - RalfJung:miri-frame-loc, r=ecstatic-morse
Miri Frame: use mir::Location to represent position in function
I only recently learned that `Location` exists, and it seems to perfectly fit what Miri needs to represent which statement we are currently executing. :)
Rollup merge of #71459 - divergentdave:pointer-offset-0x, r=RalfJung
Add leading 0x to offset in Debug fmt of Pointer
Currently the `Debug` format for `Pointer` prints its offset in hexadecimal, for example, `alloc38657819+e2` or `alloc35122748+64`. This PR adds a leading `0x` to the offset, in order to make it apparent that it is indeed a hexadecimal number. This came up during discussion of rust-lang/miri#1354. r? @RalfJung
Rollup merge of #71068 - pyfisch:unicode-version-stable, r=SimonSapin
Stabilize UNICODE_VERSION (feature unicode_version)
Tracking issue: #49726
r? @sfackler
#71020 changed the definition of `UNICODE_VERSION` just yesterday from a struct to a tuple. Maybe you want to wait some more before stabilizing this constant, on the other hand this is a very small and simple addition.
Rollup merge of #71063 - LeSeulArtichaut:document-unsafe, r=Mark-Simulacrum
Document unsafety in core::{option, hash}
Helps with #66219.
I think that the part that will need reviewing the most is the `hash/sip.rs` file.
r? @LukasKalbertodt (or someone else from the libs team)
Rollup merge of #70845 - varkor:const-generics-derive-eq-diagnostic, r=estebank
Make the `structural_match` error diagnostic for const generics clearer
The previous diagnostic caused confusion (https://github.com/rust-lang/rust/issues/70790), so this changes the message to be closer to the message for using non-`structural_match` constants in patterns, explicitly mentioning `#[derive(PartialEq, Eq)]`.
Rollup merge of #71470 - TyPR124:fix-doc-links, r=jonas-schievink
Fix doc links
This fixes a few doc links which were causing `cargo doc` to fail when using `--document-private-items --document-hidden-items` on libstd. Most of the fixes are just escaping '[' and ']' characters in doc comments, and one change actually fixes a doc link.
Rollup merge of #71408 - GuillaumeGomez:check-code-blocks-tags, r=kinnison
Check code blocks tags
Fixes #71347.
Explanations here: I realized recently that it was a common issue to confuse/misspell tags on code blocks. This is actually quite a big issue since it generally ends up in a code blocks being ignored since it's not being considered as a rust one. With this new warning, users will at least be notified about it.
PS: some improvements can be done on the error rendering but considering how big the PR already is, I think it's better to do it afterwards.
Rollup merge of #71404 - cuviper:chain-unfused, r=scottmcm
Don't fuse Chain in its second iterator
Only the "first" iterator is actually set `None` when exhausted,
depending on whether you iterate forward or backward. This restores
behavior similar to the former `ChainState`, where it would transition
from `Both` to `Front`/`Back` and only continue from that side.
However, if you mix directions, then this may still set both sides to
`None`, totally fusing the iterator.
Compiler returns
```
error: unexpected closing delimiter: `}`
--> main.rs:20:1
|
9 | ErrorHandled::Reported => {}
| -- this block is empty, you might have not meant to close it temp
...
20 | }
| ^ unexpected closing delimiter
Don't cache result of `in_any_value_of_ty` for locals
This was needed by an early version of dataflow-based const
qualification where `QualifCursor` needed to return a full `BitSet` with
the current state.
projects / rust.git / log