Auto merge of #86664 - m-ou-se:uninit-track-caller, r=JohnTitor
Add #[track_caller] for some function in core::mem.
These functions can panic for some types. This makes the panic point to the code that calls e.g. mem::uninitialized(), instead of inside the definition of mem::uninitialized.
Auto merge of #86998 - m-ou-se:const-panic-fmt-as-str, r=oli-obk
Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and std::panicking::being_panic_fmt with a call to a new const fn: core::panicking::const_panic_fmt. That function uses fmt::Arguments::as_str() to get the str and calls panic_str with that instead.
panic!() invocations with formatting arguments are still not accepted, as the creation of such a fmt::Arguments cannot be done in constant functions right now.
Auto merge of #87416 - Aaron1011:query-side-effect, r=cjgillot
Create `QuerySideEffects` and use it for diagnostics
The code for saving and loading diagnostics during execution is generalized to handle a new `QuerySideEffects` struct. Currently, this struct just holds diagnostics - in a follow-up PR, I plan to add support for storing attriutes marked as used during query execution.
This is a pure refactor, with no intended behavior changes.
Removes the implementations that depend on the user-definable trait `Copy`.
Fixes #85873 in the most straightforward way.
<hr>
_Edit:_ This PR now contains additional trait infrastructure to avoid performance regressions around in-place collect, see the discussion in this thread starting from the codegen test failure at https://github.com/rust-lang/rust/pull/85874#issuecomment-872327577.
With this PR, `TrustedRandomAccess` gains additional documentation that specifically allows for and specifies the safety conditions around subtype coercions – those coercions can happen in safe Rust code with the `Zip` API’s usage of `TrustedRandomAccess`. This PR introduces a new supertrait of `TrustedRandomAccess`(currently named `TrustedRandomAccessNoCoerce`) that _doesn’t allow_ such coercions, which means it can be still be useful for optimizing cases such as in-place collect where no iterator is handed out to a user (who could do coercions) after a `get_unchecked` call; the benefit of the supertrait is that it doesn’t come with the additional safety conditions around supertraits either, so it can be implemented for more types than `TrustedRandomAccess`.
The `TrustedRandomAccess` implementations for `vec::IntoIter`, `vec_deque::IntoIter`, and `array::IntoIter` are removed as they don’t conform with the newly documented safety conditions, this way unsoundness is removed. But this PR in turn (re-)adds a `TrustedRandomAccessNoCoerce` implementation for `vec::IntoIter` to avoid performance regressions from stable in a case of in-place collecting of `Vec`s [the above-mentioned codegen test failure]. Re-introducing the (currently nightly+beta-only) impls for `VecDeque`’s and `[T; N]`’s iterators is technically possible, but goes beyond the scope of this PR (i.e. it can happen in a future PR).
Auto merge of #87569 - JohnTitor:rollup-7ydfetw, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #81050 (Stabilize core::task::ready!)
- #81363 (Remove P: Unpin bound on impl Future for Pin)
- #86839 (Add doc aliases to fs.rs)
- #87435 (fix example code for E0617)
- #87451 (Add support for tuple struct field documentation)
- #87491 (Integrate context into the memorial to Anna)
- #87521 (Add long explanation for E0498)
- #87527 (Don't run MIR unsafeck at all when using `-Zthir-unsafeck`)
- #87550 (Add `CI_ONLY_WHEN_CHANNEL` and run `x86_64-gnu-stable` only on nightly)
- #87565 (Use backticks when referring to `core::future::Ready` in panic message)
Rollup merge of #87491 - jamesmunns:integrate-memorial, r=Mark-Simulacrum
Integrate context into the memorial to Anna
This came up after I reviewed https://github.com/rust-lang/rust/pull/87298, but I didn't propose this in time before that PR was merged.
If y'all feel this is too much churn on the file, no worries, feel free to close, but I felt this was a more fitting integration of the memorial into the test suite.
Rollup merge of #81363 - jonhoo:no-unpin-in-pin-future-impl, r=m-ou-se
Remove P: Unpin bound on impl Future for Pin
We can safely produce a `Pin<&mut P::Target>` without moving out of the `Pin` by using `Pin::as_mut` directly.
The `Unpin` bound was originally added in #56939 following the recommendation of ``@withoutboats`` in https://github.com/rust-lang/rust/issues/55766#issue-378417538
That comment does not give explicit justification for why the bound should be added. The relevant context was:
> [ ] Remove `impl<P> Unpin for Pin<P>`
>
> This impl is not justified by our standard justification for unpin impls: there is no pointer direction between `Pin<P>` and `P`. Its usefulness is covered by the impls for pointers themselves.
>
> This futures impl (link to the impl changed in this PR) will need to change to add a `P: Unpin` bound.
The decision to remove the unconditional impl of `Unpin for Pin` is sound (these days there is just an auto-impl for when `P: Unpin`). But, I think the decision to also add the `Unpin` bound for `impl Future` may have been unnecessary. Or if that's not the case, I'd be very interested to have the argument for why written down somewhere. The bound _appears_ to not be needed, as demonstrated by the change requiring no unsafe code and by the existence of `Pin::as_mut`.
This PR stabilizes the `task::ready!` macro. Similar to https://github.com/rust-lang/rust/pull/80886, this PR was waiting on https://github.com/rust-lang/rust/issues/74355 to be fixed.
The `task::ready!` API has existed in the futures ecosystem for several years, and was added on nightly last year in https://github.com/rust-lang/rust/pull/70817. The motivation for this macro is the same as it was back then: virtually every single manual future implementation makes use of this; so much so that it's one of the few things included in the [futures-core](https://docs.rs/futures-core/0.3.12/futures_core) library.
Mara Bos [Tue, 6 Jul 2021 12:38:26 +0000 (12:38 +0000)]
Make const panic!("..") work in Rust 2021.
During const eval, this replaces calls to core::panicking::panic_fmt and
std::panicking::being_panic_fmt with a call to a new const fn:
core::panicking::const_panic_fmt. That function uses
fmt::Arguments::as_str() to get the str and calls panic_str with that
instead.
panic!() invocations with formatting arguments are still not accepted,
as the creation of such a fmt::Arguments cannot be done in constant
functions right now.
Mara Bos [Sun, 27 Jun 2021 12:41:50 +0000 (12:41 +0000)]
Add #[track_caller] for some function in core::mem.
These functions can panic for some types. This makes the panic point to
the code that calls e.g. mem::uninitialized(), instead of inside the
definition of mem::uninitialized.
Frank Steffahn [Thu, 3 Jun 2021 13:53:12 +0000 (15:53 +0200)]
Improve documentation of TrustedRandomAccess
Include new details regarding coercions to a subtype.
These conditions also explain why the previously removed implementations
for {array, vec, vec_deque}::IntoIter<T> were unsound, because they introduced
an extra `T: Clone` for the TrustedRandomAccess impl, even though their parameter T
is covariant.
Rollup merge of #87524 - FabianWolff:issue-87495, r=Aaron1011
Fix ICE in `diagnostic_hir_wf_check`
Fixes #87495. The [documentation for `ObligationCauseCode::WellFormed`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/traits/enum.ObligationCauseCode.html#variant.WellFormed) says that
> it is always correct [...] to specify `WellFormed(None)`
instead of `WellFormed(Some(...))`, which seems to have caused the issue here, as `diagnostic_hir_wf_check` does not expect to be called with an associated constant and will ICE:
Rollup merge of #87513 - hudson-ayers:bootstrap-py-fix, r=jyn514
bootstrap.py: change `git log` option to indicate desired behavior
When determining which LLVM artifacts to download, bootstrap.py calls: `git log --author=bors --format=%H -n1 -m --first-parent --
src/llvm-project src/bootstrap/download-ci-llvm-stamp src/version`. However, the `-m` option has no effect, per the `git log` help:
> -m
> This option makes diff output for merge commits to be shown in the
> default format. -m will produce the output only if -p is given as
> well. The default format could be changed using log.diffMerges
> configuration parameter, which default value is separate.
Accordingly, this commit removes use of the -m option in favor of ~~`--diff-merges=off`~~ `--no-patch`, since no diff information is needed, and in fact the presence of a diff breaks the command. Tested using git 2.32, this does not change the output of the command.
The motivation for this change is that some patched versions of git change the behavior of the `-m` flag to imply `-p`, rather than to do nothing unless `-p` is passed. These patched versions of git lead to this script not working. Google's corp-provided git is one such example.
Rollup merge of #87500 - Smittyvb:min-max-docs, r=kennytm
Document math behind MIN/MAX consts on integers
Currently the documentation for `[integer]::{MIN, MAX}` doesn't explain where the constants come from. This documents how the values of those constants are related to powers of 2.
Rollup merge of #87443 - jyn514:submodules-take-n, r=jyn514
Don't treat git repos as non-existent when `ignore_git` is set
The new submodule handling depends on `is_git()` to be accurate to
decide whether it should handle submodules at all or not. Unfortunately,
`is_git()` treated "this directory does not have a git repository" and
"this repository should not be used for SHA/version/commit date info"
the same. This changes it to distinguish the two.
To clarify: ignore_get is set by default whenever channel == "dev", which it is by default whenever you're compiling locally. So basically everyone would hit this, not just people who had explicitly configured ignore_git.
Here's an example of an error this fixes:
```
$ x build
Updating only changed submodules
Submodules updated in 0.01 seconds
Finished dev [unoptimized + debuginfo] target(s) in 0.17s
warning: x.py has made several changes recently you may want to look at
help: consider looking at the changes in `src/bootstrap/CHANGELOG.md`
note: to silence this warning, add `changelog-seen = 2` at the top of `config.toml`
Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.16s
Copying stage0 std from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
Building LLVM for x86_64-unknown-linux-gnu
detected home dir change, cleaning out entire build directory
running: "cmake" "/home/joshua/rustc3/src/llvm-project/llvm" "-G" "Ninja" "-DLLVM_ENABLE_ASSERTIONS=OFF" "-DLLVM_TARGETS_TO_BUILD=AArch64;ARM;BPF;Hexagon;MSP430;Mips;NVPTX;PowerPC;RISCV;Sparc;SystemZ;WebAssembly;X86" "-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR" "-DLLVM_INCLUDE_EXAMPLES=OFF" "-DLLVM_INCLUDE_DOCS=OFF" "-DLLVM_INCLUDE_BENCHMARKS=OFF" "-DLLVM_ENABLE_TERMINFO=OFF" "-DLLVM_ENABLE_LIBEDIT=OFF" "-DLLVM_ENABLE_BINDINGS=OFF" "-DLLVM_ENABLE_Z3_SOLVER=OFF" "-DLLVM_PARALLEL_COMPILE_JOBS=48" "-DLLVM_TARGET_ARCH=x86_64" "-DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown-linux-gnu" "-DLLVM_ENABLE_ZLIB=ON" "-DLLVM_ENABLE_LIBXML2=OFF" "-DLLVM_VERSION_SUFFIX=-rust-dev" "-DCMAKE_INSTALL_MESSAGE=LAZY" "-DCMAKE_C_COMPILER=gcc" "-DCMAKE_CXX_COMPILER=g++" "-DCMAKE_ASM_COMPILER=gcc" "-DCMAKE_C_FLAGS=-ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_CXX_FLAGS=-ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_INSTALL_PREFIX=/home/joshua/rustc3/build/x86_64-unknown-linux-gnu/llvm" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC -m64" "-DCMAKE_BUILD_TYPE=Release"
CMake Error: The source directory "/home/joshua/rustc3/src/llvm-project/llvm" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
thread 'main' panicked at '
command did not execute successfully, got: exit status: 1
build script failed, must exit now', /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.44/src/lib.rs:885:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
finished in 0.783 seconds
Build completed unsuccessfully in 0:00:01
```
I *believe* this regression was only introduced in https://github.com/rust-lang/rust/pull/87380, not https://github.com/rust-lang/rust/pull/82653. ``@petrochenkov`` can you check that this fixes the issue you encountered in https://github.com/rust-lang/rust/pull/82653#issuecomment-886113679 ?
Rollup merge of #87330 - inquisitivecrystal:extend-reserve, r=JohnTitor
Use hashbrown's `extend_reserve()` in `HashMap`
When we added `extend_reserve()` to our implementation of `Extend` for `HashMap`, hashbrown didn't have a version we could use. Now that hashbrown has added it, we should use its version instead of implementing it ourself.
Auto merge of #86251 - Smittyvb:thir-tree-again, r=oli-obk
Support -Z unpretty=thir-tree again
Currently `-Z unpretty=thir-tree` is broken after some THIR refactorings. This re-implements it, making it easier to debug THIR-related issues.
We have to do analyzes before getting the THIR, since trying to create THIR from invalid HIR can ICE. But doing those analyzes requires the THIR to be built and stolen. We work around this by creating a separate query to construct the THIR tree string representation.
Auto merge of #86735 - jhpratt:rfc-3107, r=petrochenkov
Implement RFC 3107: `#[derive(Default)]` on enums with a `#[default]` attribute
This PR implements RFC 3107, which permits `#[derive(Default)]` on enums where a unit variant has a `#[default]` attribute. See comments for current status.
Auto merge of #85769 - jhpratt:stabilize-const-transmute-union, r=RalfJung
Stabilize `const_fn_transmute`, `const_fn_union`
This PR stabilizes the `const_fn_transmute` and `const_fn_union` features. It _does not_ stabilize any methods (obviously aside from `transmute`) that are blocked on only these features.
Auto merge of #80367 - camelid:check_match-combine-loop, r=Nadrieril
Combine two loops in `check_match`
Suggested by Nadrieril in
https://github.com/rust-lang/rust/pull/79051#discussion_r548778186.
Opening to get a perf run. Hopefully this code doesn't require everything in the
first loop to be done before running the second! (It shouldn't though.)
When determining which LLVM artifacts to download, bootstrap.py
calls: `git log --author=bors --format=%H -n1 -m --first-parent --
src/llvm-project src/bootstrap/download-ci-llvm-stamp src/version`.
However, the `-m` option has no effect, per the `git log` help:
> -m
> This option makes diff output for merge commits to be shown in the
> default format. -m will produce the output only if -p is given as
> well. The default format could be changed using log.diffMerges
> configuration parameter, which default value is separate.
Accordingly, this commit removes use of the -m option in favor of
`--no-patch`, to make clear that this command should never output
diff information, as the SHA-1 hash is the only desired output.
Tested using git 2.32, this does not change the
output of the command.
The motivation for this change is that some patched versions of git
change the behavior of the `-m` flag to imply `-p`, rather than to do
nothing unless `-p` is passed. These patched versions of git lead to
this script not working. Google's corp-provided git is one such example.
17 commits in eac55314210519238652f12b30fec9daea61f7fe..a07036f864b37896b31eb996cd7aedb489f69a1f
2021-07-19 11:08:01 -0400 to 2021-07-26 20:19:46 -0400
- Set expectations a bit more realistically
- Snapshot of chapter 4 for nostarch
- A few small wording tweaks in ch 4
- Clarify that it's not stack/heap exactly that matters for copy/non copy, fixes rust-lang/book#2799
- Clarify a detail around move. Fixes rust-lang/book#2413.
- Clarify places that changed because of NLL. Fixes rust-lang/book#1939.
- nostarch ch3
- Small edits to chapter 3
- (rust-lang/book#2797)
- Update ch03-03-how-functions-work.md: Pervasive -> Prevalent. (rust-lang/book#2796)
- Address loop labels and continue. Fixes rust-lang/book#1392.
- Clarify behavior of integer division. Fixes rust-lang/book#2248.
- Demonstrate how scope interacts with shadowing
- Add another cross-reference to the new unit type introduction
- Introduce the unit type with tuples. Fixes rust-lang/book#1933.
- Reword sentence to not have numbers separated only by a comma
- Link directly to other installation page. Fixes rust-lang/book#1609
Rollup merge of #87502 - ehuss:update-cargo, r=ehuss
Update cargo
8 commits in cebef2951ee69617852844894164b54ed478a7da..d21c22870e58499d6c31f1bef3bf1255eb021666
2021-07-22 13:01:52 +0000 to 2021-07-26 20:23:21 +0000
- Fix version string. (rust-lang/cargo#9727)
- Allow publishing from workspace root. (rust-lang/cargo#9559)
- Better msg for wrong position (rust-lang/cargo#9723)
- Stabilize the rustc-link-arg option (rust-lang/cargo#9557)
- Warning when using features in replace (rust-lang/cargo#9681)
- Refactor if let chains to matches! macro (rust-lang/cargo#9721)
- Weather is not nice today.. (rust-lang/cargo#9720)
- Update should_use_metadata function (rust-lang/cargo#9653)
Rollup merge of #86450 - tmiasko:move-size-limit, r=pnkfelix
Add flag to configure `large_assignments` lint
The `large_assignments` lints detects moves over specified limit. The
limit is configured through `move_size_limit = "N"` attribute placed at
the root of a crate. When attribute is absent, the lint is disabled.
Make it possible to enable the lint without making any changes to the
source code, through a new flag `-Zmove-size-limit=N`. For example, to
detect moves exceeding 1023 bytes in a cargo crate, including all
dependencies one could use:
Auto merge of #87431 - the8472:array-iter-fold, r=kennytm
implement fold() on array::IntoIter to improve flatten().collect() perf
With #87168 flattening `array::IntoIter`s is now `TrustedLen`, the `FromIterator` implementation for `Vec` has a specialization for `TrustedLen` iterators which uses internal iteration. This implements one of the main internal iteration methods on `array::Into` to optimize the combination of those two features.
This should address the main issue in #87411
```
# old
test vec::bench_flat_map_collect ... bench: 2,244,024 ns/iter (+/- 18,903)
# new
test vec::bench_flat_map_collect ... bench: 172,863 ns/iter (+/- 2,141)
```
Auto merge of #85305 - MarcusDunn:master, r=pnkfelix
Stabilize bindings_after_at
attempting to stabilze bindings_after_at [#65490](https://github.com/rust-lang/rust/issues/65490), im pretty new to the whole thing so any pointers are greatly appreciated.
Auto merge of #83491 - jyn514:remove-pretty, r=pnkfelix
Remove unstable `--pretty` flag
It doesn't do anything `--unpretty` doesn't, and due to a bug, also
didn't show up in `--help`. I don't think there's any reason to keep it
around, I haven't seen anyone using it.
Auto merge of #87062 - poliorcetics:fix-85462, r=dtolnay
Make StrSearcher behave correctly on empty needle
Fix #85462.
This will not affect ABI since the other variant of the enum is bigger.
It may break some code, but that would be very strange: usually people
don't continue after the first `Done` (or `None` for a normal iterator).