Move the target libLLVM to llvm-tools-preview
For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.
Here are the dist sizes that I got before and after this change:
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M
The installed size should reduce by exactly one `libLLVM.so` (~70-80M),
unless you also install `llvm-tools`, and then it should be identical.
Resolves#70838.
Clean up logic around live locals in generator analysis
Resolves#69902. Requires #71893.
I've found it difficult to make changes in the logic around live locals in `generator/transform.rs`. It uses a custom dataflow analysis, `MaybeRequiresStorage`, that AFAICT computes whether a local is either initialized or borrowed. That analysis is using `before` effects, which we should try to avoid if possible because they are harder to reason about than ones only using the unprefixed effects. @pnkfelix has suggested removing "before" effects entirely to simplify the dataflow framework, which I might pursue someday.
This PR replaces `MaybeRequiresStorage` with a combination of the existing `MaybeBorrowedLocals` and a new `MaybeInitializedLocals`. `MaybeInitializedLocals` is just `MaybeInitializedPlaces` with a coarser resolution: it works on whole locals instead of move paths. As a result, I was able to simplify the logic in `compute_storage_conflicts` and `locals_live_across_suspend_points`.
This is not exactly equivalent to the old logic; some generators are now smaller than before. I believe this was because the old logic was too conservative, but I'm not as familiar with the constraints as the original implementers were, so I could be wrong. For example, I don't see a reason the size of the `mixed_sizes` future couldn't be 5K. It went from 7K to 6K in this PR.
r? @jonas-schievink @tmandry
Improve documentation of `slice::from_raw_parts`
This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.
Providing that very pattern as a counter-example could help mitigate that.
See also: https://internals.rust-lang.org/t/pre-rfc-add-join-seq-method-to-slices-and-strs/11936/13
r? @RalfJung
Intern predicates
Implements the first step of https://github.com/rust-lang/compiler-team/issues/285
Renames `ty::Predicate` to `ty::PredicateKind`, which is now interned.
To ease the transition, `ty::Predicate` is now a struct containing a reference
to `ty::PredicateKind`.
r? @ghost
De-abuse TyKind::Error in exhaustiveness checking
Replaces https://github.com/rust-lang/rust/pull/71074. Context: https://github.com/rust-lang/rust/issues/70866.
In order to remove the use of `TyKind::Error`, I had to make sure we skip over those fields whose inhabitedness should not be observed. This is potentially error-prone however, since we must be careful not to mix filtered and unfiltered lists of patterns. I managed to hide away most of the filtering behind a new `Fields` struct, that I used everywhere relevant. I quite like the result; I think the twin concepts of `Constructor` and `Fields` make a good mental model.
As usual, I tried to separate commits that shuffle code around from commits that require more thought to review.
cc @varkor @Centril
This is to provide a more explicit statement against a code pattern that
many people end up coming with, since the reason of it being unsound
comes from the badly known single-allocation validity rule.
Providing that very pattern as a counter-example could help mitigate that.
Co-authored-by: Ralf Jung <post@ralfj.de>
Experimentally add `ffi_const` and `ffi_pure` extern fn attributes
Add FFI function attributes corresponding to clang/gcc/... `const` and `pure`.
Rebased version of #58327 by @gnzlbg with the following changes:
- Switched back from the `c_ffi_const` and `c_ffi_pure` naming to `ffi_const` and `ffi_pure`, as I agree with https://github.com/rust-lang/rust/pull/58327#issuecomment-462718772 and this nicely aligns with `ffi_returns_twice`
- (Hopefully) took care of all of @hanna-kruppe's change requests in the original PR
r? @hanna-kruppe
Rollup of 7 pull requests
Successful merges:
- #71854 (Make `std::char` functions and constants associated to `char`.)
- #72111 (rustc-book: Document `-Z strip=val` option)
- #72272 (Fix going back in history to a search result page on firefox)
- #72296 (Suggest installing VS Build Tools in more situations)
- #72365 (Remove unused `StableHashingContext::node_to_hir_id` method)
- #72371 (FIX - Char documentation for unexperienced users)
- #72397 (llvm: Expose tiny code model to users)
Failed merges:
r? @ghost
FIX - Char documentation for unexperienced users
This is my first PR on rust and even if I've read [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests) I'm ensure everything is perfect. Sorry if I didn't follow the exact procedure.
**What it does:**
- Add an example in the char documentation
**Explanation**
Unexperienced users might not know that punctuation is `Case_Ignorable` and not `Uppercase` and `Lowercase` which mean that when checking if a string is uppercase one might be tempted to write:
```rust
my_string.chars().all(char::is_uppercase)
```
However this will return false for `"HELLO WORLD"` which is not intuitive. Since the function `is_case_ignorable` doesn't exists I believe the correct way to check is:
```rust
!my_string.chars().any(char::is_lowercase)
```
The aim of this example is to prevent unexperienced users to make an error which punctuation chars.
Suggest installing VS Build Tools in more situations
When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be [impenetrable](https://pastebin.com/MRMCr7HM) to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.
This only applies when Microsoft's link tool is expected.
Fix going back in history to a search result page on firefox
This bug was actually firefox not re-running JS script when you go back in history. To trigger it on the current docs:
* Make a search
* Pick an element (which isn't on the same page as the current element!)
* Go back in history
Instead of having the search results, you'll see the normal doc page. You can find a small explanation about it [here](http://web.archive.org/web/20100428053932/http://www.firefoxanswer.com/firefox/672-firefoxanswer.html).
r? @kinnison
cc @ollie27
Dumb NRVO
This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis.
I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges.
r? @ghost
Use `T`'s discriminant type in `mem::Discriminant<T>` instead of `u64`.
fixes#70509
Adds the lang-item `discriminant_kind`.
Updates the function signature of `intrinsics::discriminant_value`.
Adds the *probably permanently unstable* trait `DiscriminantKind`.
`mem::Discriminant` should now be smaller in some cases.
r? @ghost
For running the compiler, we usually only need LLVM from `$sysroot/lib`,
which rustup will make available with `LD_LIBRARY_PATH`. We've also been
shipping LLVM in the `$target/lib` directory, which bloats the download
and installed size. The only times we do need the latter are for the
RPATH of `llvm-tools-preview` binaries, and for linking `rustc-dev`
libraries. We'll move it to the `llvm-tools-preview` component directly,
and `rustc-dev` will have an implicit dependency on it.
Here are the dist sizes that I got before and after this change:
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 1.3M 24M
llvm-tools-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 748K 17M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.gz 83M 61M
rustc-1.45.0-dev-x86_64-unknown-linux-gnu.tar.xz 56M 41M
The installed size should reduce by exactly one `libLLVM.so` (~70-80M),
unless you also install `llvm-tools`, and then it should be identical.
When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be impenetrable to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.
This only applies when Microsoft's link tool is expected. Not `lld-link` or other MSVC compatible linkers.
Adjust the zero check in `RawVec::grow`.
This was supposed to land as part of #72227. (I wish `git push` would
abort when you have uncommited changes.)
r? @Amanieu
Continue lowering for unsupported async generator instead of returning an error.
This way the hir is "valid" and we can remove one more call to
`opt_node_id_to_hir_id` but an error is still emitted.
This is another partial fix for #71104
r? @eddyb
Make `fold` standalone.
`fold` is currently implemented via `try_fold`, but implementing it
directly results in slightly less LLVM IR being generated, speeding up
compilation of some benchmarks.
r? @cuviper
Suggest fixes and add error recovery for `use foo::self`
Fixes#63741.
I have implemented 2 suggestions on how to fix a `use foo::self` import, however I feel like showing them both might be too verbose.
Additionally, I have also implemented error recovery as [menitoned](https://github.com/rust-lang/rust/issues/63741#issuecomment-602391091) by @comex.
I believe r? @estebank deals with diagnostics.
