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.
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).
Auto merge of #87480 - GuillaumeGomez:rollup-3ly8t5d, r=GuillaumeGomez
Rollup of 8 pull requests
Successful merges:
- #87436 (Suggest `;` on parse error where applicable)
- #87444 (Flatten nested `format!` calls)
- #87447 (Miri: santiy check that null pointer can never have an AllocId)
- #87457 (freebsd remove compiler workaround.)
- #87458 (Fix help message for modification to &T created by &{t})
- #87464 (Remove unnecessary `structhead` parameter from `render_union`)
- #87473 (Notify the Rust 2021 edition working group in zulip of edition bugs)
- #87474 (Add missing whitespace after attribute in HTML template)
Rollup merge of #87464 - camelid:rm-union-structhead, r=jyn514
Remove unnecessary `structhead` parameter from `render_union`
`structhead` is used for `render_struct` so that the logic for rendering
structs can be shared between struct variants and struct items. However,
`render_union` is not used anywhere except for rendering union items, so
its `structhead` parameter is unnecessary.
Rollup merge of #87458 - ibraheemdev:help-msg-block-borrow, r=oli-obk
Fix help message for modification to &T created by &{t}
Previous:
```rust
error[E0594]: cannot assign to `*x` which is behind a `&` reference
--> src/main.rs:3:5
|
2 | let x: &usize = &mut{0};
| ------- help: consider changing this to be a mutable reference: `&mut mut{0}`
3 | *x = 1;
| ^^^^^^ `x` is a `&` reference, so the data it refers to cannot be written
```
Auto merge of #87439 - ThibsG:FixDocTypo, r=jonas-schievink
Fix doc typo
Just a typo in doc that has a bad rendering here: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/expr_use_visitor/struct.ExprUseVisitor.html#method.walk_captures
Noah Lev [Sun, 25 Jul 2021 23:28:52 +0000 (16:28 -0700)]
Remove unnecessary `structhead` parameter from `render_union`
`structhead` is used for `render_struct` so that the logic for rendering
structs can be shared between struct variants and struct items. However,
`render_union` is not used anywhere except for rendering union items, so
its `structhead` parameter is unnecessary.
Auto merge of #85646 - Moxinilian:separate-const-switch, r=cjgillot
MIR opt: separate constant predecessors of a switch
For each block S ending with a switch, this pass copies S for each of S's predecessors that seem to assign the value being switched over as a const. This is done using a somewhat simple heuristic to determine what seems to be a const transitively.
More precisely, this is what the pass does:
- find a block that ends in a switch
- track if there is an unique place set before the current basic block that determines the result of the switch (this is the part that resolves switching over discriminants)
- if there is, iterate over the parents that have a reasonable terminator and find if the found determining place is likely to be (transitively) set from a const within that parent block
- if so, add the corresponding edge to a vector of edges to duplicate
- once this is done, iterate over the found edges: copy the target block and replace the reference to the target block in the origin block with the new block
This pass is not optimal and could probably duplicate in more cases, but the intention was mostly to address cases like in #85133 or #85365, to avoid creating new enums that get destroyed immediately afterwards (notably making the new try v2 `?` desugar zero-cost).
A benefit of this pass working the way it does is that it is easy to ensure its correctness: the worst that can happen is for it to needlessly copy a basic block, which is likely to be destroyed by cleanup passes afterwards. The complex parts where aliasing matters are only heuristics and the hard work is left to further passes like ConstProp.
# LLVM blocker
Unfortunately, I believe it would be unwise to enable this optimization by default for now. Indeed, currently switch lowering passes like SimplifyCFG in LLVM lose the information on the set of possible variant values, which means it tends to actually generate worse code with this optimization enabled. A fix would have to be done in LLVM itself. This is something I also want to look into. I have opened [a bug report at the LLVM bug tracker](https://bugs.llvm.org/show_bug.cgi?id=50455).
When this is done, I hope we can enable this pass by default. It should be fairly fast and I think it is beneficial in many cases. Notably, it should be a sound alternative to simplify-arm-identity. By the way, ConstProp only seems to pick up the optimization in functions that are not generic. This is however most likely an issue in ConstProp that I will look into afterwards.
This is my first contribution to rustc, and I would like to thank everyone on the Zulip mir-opt chat for the help and support, and especially `@scottmcm` for the guidance.
projects / rust.git / log