Rollup merge of #98633 - c410-f3r:yet-another-let-chain, r=estebank
Fix last `let_chains` blocker
In order to forbid things like `let x = (let y = 1);` or `if let a = 1 && { let x = let y = 1; } {}`, the parser **HAS** to know the context of `let`.
This context thing is not a surprise in the parser because you can see **a lot** of ad hoc fixes mixing parsing logic with validation logic creating code that looks more like spaghetti with tomato sauce.
To make things even greater, a new ad hoc fix was added to only allow `let`s in a valid `let_chains` context by checking the previously processed token. This was the only solution I could think of and believe me, I thought about it for a long time 👍
In the long term, it should be preferable to segregate different responsibilities or create a more robust and cleaner parser framework.
cc https://github.com/rust-lang/rust/pull/94927
cc https://github.com/rust-lang/rust/issues/53667
Auto merge of #99165 - matthiaskrgr:rollup-rqpelfa, r=matthiaskrgr
Rollup of 8 pull requests
Successful merges:
- #97210 (Support `-A`, `-W`, `-D` and `-F` when running `./x.py clippy`)
- #99055 (Fix rustdoc help options)
- #99075 (Fix duplicated type annotation suggestion)
- #99124 (Fix sized check ICE in asm check)
- #99142 (fix(doctest): treat fatal parse errors as incomplete attributes)
- #99145 (Don't rerun the build script for the compiler each time on non-windows platforms)
- #99146 (Do not error during method probe on `Sized` predicates for types that aren't the method receiver)
- #99161 (compiletest: trim edition before passing as flag)
Rollup merge of #99146 - compiler-errors:issue-61525, r=lcnr
Do not error during method probe on `Sized` predicates for types that aren't the method receiver
Fixes #61525
This is safe even though we're skipping an error because we end up confirming the method, which means we're still checking the `Sized` predicate in the end. It just means that we don't emit an erroneous message as below:
```
error: the `query` method cannot be invoked on a trait object
--> src/lib.rs:14:11
|
14 | 1.query::<dyn ToString>("")
| ^^^^^
|
= note: another candidate was found in the following trait, perhaps add a `use` for it:
`use crate::Example;`
```
Also fixes erroneously suggesting the same trait over again, as seen in the `issue-35976.rs` UI test.
Rollup merge of #99145 - jyn514:dont-rerun-build-script, r=wesleywiser
Don't rerun the build script for the compiler each time on non-windows platforms
In practice, this doesn't matter very much because the script takes ~no time to run.
But this makes `CARGO_LOG=info` easier to read, and theoretically saves a few milliseconds.
Rollup merge of #99124 - compiler-errors:issue-99122, r=oli-obk
Fix sized check ICE in asm check
Fixes (beta nominated, so doesn't close) #99122
1. Moves a check for unresolved inference variables to _before_ other checks that could possibly ICE. We're not changing behavior here, just doing the same thing earlier in the function.
2. Erases region variables in sized check (which are not resolved at this point) because rustc will also ICE when region vars are passed to a query which does not canonicalize them.
Rollup merge of #99075 - danobi:dup_type_hint_sugg, r=petrochenkov
Fix duplicated type annotation suggestion
Before, there was more or less duplicated suggestions to add type hints.
Fix by clearing more generic suggestions when a more specific suggestion
is possible.
Auto merge of #96978 - lqd:win_pgo2, r=Mark-Simulacrum
Utilize PGO for windows x64 rustc dist builds
This PR adds PGO support for the CI x64 windows dist builds.
These are the results from running the rustc-perf benchmarks:
![image](https://user-images.githubusercontent.com/247183/177662869-683a8034-7c95-42bf-9900-9ffd66677fcf.png)
Thanks to `@Kobzol,` `@michaelwoerister,` `@wesleywiser,` `@Mark-Simulacrum` for their precious help.
Rémy Rakic [Tue, 14 Jun 2022 20:19:07 +0000 (22:19 +0200)]
make linux PGO script more generic
This extracts the linux-isms into variables, so that the script can be
extended to do PGO on windows. These variables will be overriden in a
few spots, in windows-specific blocks.
Rémy Rakic [Mon, 16 May 2022 01:40:52 +0000 (03:40 +0200)]
extend bootstrap for PGO on windows
When building LLVM/LLD as part of a build that asks LLVM to generate profiles, e.g. when
doing PGO, cmake or clang-cl don't automatically link clang's profiler runtime in,
causing undefined reference errors at link-time.
We do that manually, by adding clang's resource library folder to the library search path:
- for LLVM itself, by extending the linker args that `rustc_llvm`'s build script
uses, to avoid the linker errors when linking `rustc_driver`.
- for LLD, by extending cmake's linker flags during the LLD build step.
Auto merge of #99151 - Dylan-DPC:rollup-40aqkxy, r=Dylan-DPC
Rollup of 5 pull requests
Successful merges:
- #98882 (explain doc comments in macros a bit)
- #98907 (Deny float const params even when `adt_const_params` is enabled)
- #99091 (Do not mention private types from other crates as impl candidates)
- #99140 (Implement `SourceMap::is_span_accessible`)
- #99147 (Mention similarly named associated type even if it's not clearly in supertrait)
Rollup merge of #99147 - compiler-errors:issue-55673, r=lcnr
Mention similarly named associated type even if it's not clearly in supertrait
Due to query cycle avoidance, we sometimes restrict the candidates in `complain_about_assoc_type_not_found` too much so that we can't detect typo replacements from just supertraits.
This creates a more general note of the existence of a similarly named associated type from _all_ visible traits when possible.
Rollup merge of #99140 - TaKO8Ki:implement-is-accessible-span, r=fee1-dead
Implement `SourceMap::is_span_accessible`
This patch adds `SourceMap::is_span_accessible` and replaces `span_to_snippet(span).is_ok()` and `span_to_snippet(span).is_err()` with it. This removes a `&str` to `String` conversion.
Auto merge of #98369 - jyn514:configure.py, r=Mark-Simulacrum
Remove unsupported options in configure.py
I've seen people using `optimize = false` and `full-bootstrap = true` in the past, without knowing
that they're not recommended. Remove `optimize` and a few other options that are always a bad idea,
and document that full-bootstrap is only for testing reproducible builds.
Joshua Nelson [Mon, 11 Jul 2022 04:57:25 +0000 (23:57 -0500)]
Don't rerun the build script for the compiler each time on linux
In practice, this doesn't matter very much because the script takes ~no time to run.
But this makes `CARGO_LOG=info` easier to read, and theoretically saves a few milliseconds.
Auto merge of #99130 - jyn514:std-cache-invalidation, r=Mark-Simulacrum
Fix `x build library/std compiler/rustc`
Previously, this was broken because of improper caching:
1. `StepDescription::maybe_run` builds `Compile::Std`, which only built `std` and not `proc_macro`
1. `Std` calls `builder.ensure(StdLink)`
1. `Rustc` calls `ensure(Std)`, which builds all crates, including `proc_macro`
1. `Rustc` calls `ensure(StdLink)`. `ensure` would see that it had already been run and do nothing. <-- bug is here
1. Cargo gives an error that `proc_macro` doesn't exist.
This fixes the caching by adding `crates` to `StdLink`, so it will get rerun if the crates that are built change.
Auto merge of #98526 - jyn514:download-llvm-outside-checkout, r=Mark-Simulacrum
Allow using `download-ci-llvm = true` outside the git checkout
`@bjorn3` noticed that this is already allowed today when download-llvm is disabled, but breaks with it enabled:
```
$ ./rust2/x.py build
fatal: not a git repository (or any of the parent directories): .git
thread 'main' panicked at 'command did not execute successfully: "git" "rev-list" "--author=bors@rust-lang.org" "-n1" "--first-parent" "HEAD" "--" "/home/jnelson/rust-lang/rust2/src/llvm-project" "/home/jnelson/rust-lang/rust2/src/bootstrap/download-ci-llvm-stamp" "/home/jnelson/rust-lang/rust2/src/version"
expected success, got: exit status: 128', src/bootstrap/native.rs:134:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Support it too for consistency. It's unclear to me when anyone would need to use this, but `@bjorn3`
feels we should support it, and it's not much additional effort to get it working.
Joshua Nelson [Sun, 10 Jul 2022 22:24:43 +0000 (17:24 -0500)]
Fix `x build library/std compiler/rustc`
Previously, this was broken because of improper caching:
1. `StepDescription::maybe_run` builds `Compile::Std`, which only built `std` and not `proc_macro`
1. `Std` calls `builder.ensure(StdLink)`
1. `Rustc` calls `ensure(Std)`, which builds all crates, including `proc_macro`
1. `Rustc` calls `ensure(StdLink)`. `ensure` would see that it had already been run and do nothing. <-- bug is here
1. Cargo gives an error that `proc_macro` doesn't exist.
This fixes the caching by adding `crates` to `StdLink`, so it will get rerun if the crates that are
built change. This also does the same for `RustcLink`; it doesn't matter in practice currently
because nothing uses it except `impl Step for Rustc`, but it will avoid bugs if we start using it in
the future (e.g. to build individual crates for rustfmt).
Rollup merge of #99128 - oxalica:fix/ci-llvm-patchelf, r=jyn514
Fix `download-ci-llvm` NixOS patching for binaries
LLVM tools should also be patched, since they are used in some tests, specially,
- src/test/run-make-fulldeps/cross-lang-lto (llvm-ar)
- src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs (llvm-ar)
- src/test/run-make-fulldeps/issue-64153 (llvm-objdump)
To be more future proof, we should patch all binaries in `bin`, which is done in this PR.
Rollup merge of #98713 - nikomatsakis:issue-98693, r=jackh726
promote placeholder bounds to 'static obligations
In NLL, when we are promoting a bound out from a closure, if we have a requirement that `T: 'a` where `'a` is in a higher universe, we were previously ignoring that, which is totally wrong. We should be promoting those constraints to `'static`, since universes are not expressible across closure boundaries.
Fixes #98693
~~(Marking as WIP because I'm still running tests, haven't add the new test, etc)~~
Fix `download-ci-llvm` NixOS patching for binaries
LLVM tools should also be patched, since they are used in some tests,
specially,
- src/test/run-make-fulldeps/cross-lang-lto (llvm-ar)
- src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs (llvm-ar)
- src/test/run-make-fulldeps/issue-64153 (llvm-objdump)
To be more future proof, we should patch all binaries in `bin`.
Joshua Nelson [Sun, 26 Jun 2022 09:39:46 +0000 (04:39 -0500)]
Allow using `download-ci-llvm = true` outside the git checkout
@bjorn3 noticed that this is already allowed today when download-llvm is disabled, but breaks with it enabled:
```
$ ./rust2/x.py build
fatal: not a git repository (or any of the parent directories): .git
thread 'main' panicked at 'command did not execute successfully: "git" "rev-list" "--author=bors@rust-lang.org" "-n1" "--first-parent" "HEAD" "--" "/home/jnelson/rust-lang/rust2/src/llvm-project" "/home/jnelson/rust-lang/rust2/src/bootstrap/download-ci-llvm-stamp" "/home/jnelson/rust-lang/rust2/src/version"
expected success, got: exit status: 128', src/bootstrap/native.rs:134:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Support it too for consistency. It's unclear to me when anyone would need to use this, but @bjorn3
feels we should support it, and it's not much additional effort to get it working.
This also updates a bunch of other git commands that were similarly depending on the current directory.
Joshua Nelson [Wed, 22 Jun 2022 03:26:13 +0000 (22:26 -0500)]
Remove unsupported options in configure.py
I've seen people using `optimize = false` and `full-bootstrap = true` in the past, without knowing
that they're not recommended. Remove `optimize` and a few other options that are always a bad idea,
and document that full-bootstrap is only for testing reproducible builds.
Auto merge of #98463 - mystor:expand_expr_bool, r=eddyb
proc_macro: Fix expand_expr expansion of bool literals
Previously, the expand_expr method would expand bool literals as a
`Literal` token containing a `LitKind::Bool`, rather than as an `Ident`.
This is not a valid token, and the `LitKind::Bool` case needs to be
handled seperately.
Tests were added to more deeply compare the streams in the expand-expr
test suite to catch mistakes like this in the future.
Auto merge of #99112 - matthiaskrgr:rollup-uv2zk4d, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #99045 (improve print styles)
- #99086 (Fix display of search result crate filter dropdown)
- #99100 (Fix binary name in help message for test binaries)
- #99103 (Avoid some `&str` to `String` conversions)
- #99109 (fill new tracking issue for `feature(strict_provenance_atomic_ptr)`)
Rollup merge of #99086 - GuillaumeGomez:search-result-crate-filter-dropdown, r=notriddle
Fix display of search result crate filter dropdown
In case a crate name is too long, the `<select>` completely overflows its parent. Another problem is that there is left margin on the `select` which break the alignment. You can see both issues here:
Rollup merge of #99045 - 1011X:patch-1, r=GuillaumeGomez
improve print styles
this change removes some interactive elements in ``@media` print` form.
more specifically, it removes the sidebar, source links, the expand/collapse toggle buttons, and the `#copy-path` button.
it also adjusts some spacing and removes the `.top-doc` description completely if it's currently collapsed.
Auto merge of #95295 - CAD97:layout-isize, r=scottmcm
Enforce that layout size fits in isize in Layout
As it turns out, enforcing this _in APIs that already enforce `usize` overflow_ is fairly trivial. `Layout::from_size_align_unchecked` continues to "allow" sizes which (when rounded up) would overflow `isize`, but these are now declared as library UB for `Layout`, meaning that consumers of `Layout` no longer have to check this before making an allocation.
(Note that this is "immediate library UB;" IOW it is valid for a future release to make this immediate "language UB," and there is an extant patch to do so, to allow Miri to catch this misuse.)
See also #95252, [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Layout.20Isn't.20Enforcing.20The.20isize.3A.3AMAX.20Rule).
Fixes https://github.com/rust-lang/rust/issues/95334
> [B]ecause of the non-trivial presence of both of these among code published on e.g. crates.io:
>
> 1. **`Layout` "producers" / `GlobalAlloc` "users"**: smart pointers (including `alloc::rc` copies with small tweaks), collections, etc.
> 2. **`Layout` "consumers" / `GlobalAlloc` "providers"**: perhaps fewer of these, but anything built on top of OS APIs like `mmap` will expose `> isize::MAX` allocations (on 32-bit hosts) if they lack extra checks
>
> IMO the only responsible option is to enforce the `isize::MAX` limit in `Layout`, which:
>
> * makes `Layout` _sound_ in terms of only ever allowing allocations where `(alloc_base_ptr: *mut u8).offset(size)` is never UB
> * frees both "producers" and "consumers" of `Layout` from manually reimplementing the checks
> * manual checks can be risky, e.g. if the final size passed to the allocator isn't the one being checked
> * this applies retroactively, fixing the overall soundness of existing code with zero transition period or _any_ changes required from users (as long as going through `Layout` is mandatory, making a "choke point")
>
>
> Feel free to quote this comment onto any relevant issue, I might not be able to keep track of developments.
> As someone who spent way too much time optimizing libcollections checks for this stuff and tried to splatter docs about it everywhere on the belief that it was a reasonable thing for people to manually take care of: I concede the point, it is not reasonable. I am wholy spiritually defeated by the fact that _liballoc_ of all places is getting this stuff wrong. This isn't throwing shade at the folks who implemented these Rc features, but rather a statement of how impractical it is to expect anyone out in the wider ecosystem to enforce them if _some of the most audited rust code in the library that defines the very notion of allocating memory_ can't even reliably do it.
>
> We need the nuclear option of Layout enforcing this rule. Code that breaks this rule is _deeply_ broken and any "regressions" from changing Layout's contract is a _correctness_ fix. Anyone who disagrees and is sufficiently motivated can go around our backs but the standard library should 100% refuse to enable them.
cc also `@RalfJung` `@rust-lang/wg-allocators.` Even though this technically supersedes #95252, those potential failure points should almost certainly still get nicer panics than just "unwrap failed" (which they would get by this PR).
It might additionally be worth recommending to users of the `Layout` API that they should ideally use `.and_then`/`?` to complete the entire layout calculation, and then `panic!` from a single location at the end of `Layout` manipulation, to reduce the overhead of the checks and optimizations preserving the exact location of each `panic` which are conceptually just one failure: allocation too big.
Probably deserves a T-lang and/or T-libs-api FCP (this technically solidifies the [objects must be no larger than `isize::MAX`](https://rust-lang.github.io/unsafe-code-guidelines/layout/scalars.html#isize-and-usize) rule further, and the UCG document says this hasn't been RFCd) and a crater run. Ideally, no code exists that will start failing with this addition; if it does, it was _likely_ (but not certainly) causing UB.
Changes the raw_vec allocation path, thus deserves a perf run as well.
I suggest hiding whitespace-only changes in the diff view.
Auto merge of #97522 - xfix:stabilize-slice-from-raw-parts, r=dtolnay
Partially stabilize const_slice_from_raw_parts
This doesn't stabilize methods working on mutable pointers.
This pull request continues from #94946.
Pinging `@rust-lang/wg-const-eval` this because I use `rustc_allow_const_fn_unstable`. I believe this is justifiable as it's already possible to use `slice::from_raw_parts` in stable by abusing `transmute`. The stable alternative to this would be to provide a stable const implementation of `std::ptr::from_raw_parts` (as it can already be implemented in stable).
Auto merge of #99056 - lcnr:higher_ranked_sub, r=oli-obk
don't use `commit_if_ok` during `higher_ranked_sub`
This snapshot doesn't really do anything useful for us, especially once we deal with placeholder outlive bounds during trait solving.
I guess that currently the idea is that `higher_ranked_sub` could cause a later `leak_check` to fail even if the combine operation isn't actually relevant. But really, using combine outside of snapshot and ignoring its result is wrong anyways, as it can constrain inference variables.
Auto merge of #98957 - RalfJung:zst-are-different, r=lcnr,oli-obk
don't allow ZST in ScalarInt
There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
`ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.
So I propose we stop using ScalarInt to represent ZST (which are clearly not integers). Instead, we can add new ZST variants to those types that did not have other variants which could be used for this purpose.
Based on https://github.com/rust-lang/rust/pull/98831. Only the commits starting from "don't allow ZST in ScalarInt" are new.
Auto merge of #99082 - matthiaskrgr:rollup-nouwsh7, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #99022 (MIR dataflow: Rename function to `always_storage_live_locals`)
- #99050 (Clarify MIR semantics of storage statements)
- #99067 (Intra-doc-link-ify reference to Clone::clone_from)
There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
`ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.
So instead add new ZST variants to those types that did not have other variants
which could be used for this purpose.