Deadbeef [Wed, 25 Aug 2021 11:53:16 +0000 (11:53 +0000)]
Introduce `~const`
- [x] Removed `?const` and change uses of `?const`
- [x] Added `~const` to the AST. It is gated behind const_trait_impl.
- [x] Validate `~const` in ast_validation.
- [ ] Add enum `BoundConstness` to the HIR. (With variants `NotConst` and
`ConstIfConst` allowing future extensions)
- [ ] Adjust trait selection and pre-existing code to use `BoundConstness`.
- [ ] Optional steps (*for this PR, obviously*)
- [ ] Fix #88155
- [ ] Do something with constness bounds in chalk
bors [Fri, 27 Aug 2021 01:07:17 +0000 (01:07 +0000)]
Auto merge of #88371 - Manishearth:rollup-pkkjsme, r=Manishearth
Rollup of 11 pull requests
Successful merges:
- #87832 (Fix debugger stepping behavior with `match` expressions)
- #88123 (Make spans for tuple patterns in E0023 more precise)
- #88215 (Reland #83738: "rustdoc: Don't load all extern crates unconditionally")
- #88216 (Don't stabilize creation of TryReserveError instances)
- #88270 (Handle type ascription type ops in NLL HRTB diagnostics)
- #88289 (Fixes for LLVM change 0f45c16f2caa7c035e5c3edd40af9e0d51ad6ba7)
- #88320 (type_implements_trait consider obligation failure on overflow)
- #88332 (Add argument types tait tests)
- #88340 (Add `c_size_t` and `c_ssize_t` to `std::os::raw`.)
- #88346 (Revert "Add type of a let tait test impl trait straight in let")
- #88348 (Add field types tait tests)
bors [Thu, 26 Aug 2021 22:26:23 +0000 (22:26 +0000)]
Auto merge of #87280 - lcnr:lazy-anon-const-default-substs, r=nikomatsakis
lazily "compute" anon const default substs
Continuing the work of #83086, this implements the discussed solution for the [unused substs problem](https://github.com/rust-lang/project-const-generics/blob/master/design-docs/anon-const-substs.md#unused-substs). As of now, anonymous constants inherit all of their parents generics, even if they do not use them, e.g. in `fn foo<T, const N: usize>() -> [T; N + 1]`, the array length has `T` as a generic parameter even though it doesn't use it. These *unused substs* cause some backwards incompatible, and imo incorrect behavior, e.g. #78369.
---
We do not actually filter any generic parameters here and the `default_anon_const_substs` query still a dummy which only checks that
- we now prevent the previously existing query cycles and are able to call `predicates_of(parent)` when computing the substs of anonymous constants
- the default anon consts substs only include the typeflags we assume it does.
Implementing that filtering will be left as future work.
---
The idea of this PR is to delay the creation of the anon const substs until after we've computed `predicates_of` for the parent of the anon const. As the predicates of the parent can however contain the anon const we still have to create a `ty::Const` for it.
We do this by changing the substs field of `ty::Unevaluated` to an option and modifying accesses to instead call the method `unevaluated.substs(tcx)` which returns the substs as before. If the substs - now `substs_` - of `ty::Unevaluated` are `None`, it means that the anon const currently has its default substs, i.e. the substs it has when first constructed, which are the generic parameters it has available. To be able to call `unevaluated.substs(tcx)` in a `TypeVisitor`, we add the non-defaulted method `fn tcx_for_anon_const_substs(&self) -> Option<TyCtxt<'tcx>>`. In case `tcx_for_anon_const_substs` returns `None`, unknown anon const default substs are skipped entirely.
Even when `substs_` is `None` we still have to treat the constant as if it has its default substs. To do this, `TypeFlags` are modified so that it is clear whether they can still change when *exposing* any anon const default substs. A new flag, `HAS_UNKNOWN_DEFAULT_CONST_SUBSTS`, is added in case some default flags are missing.
The rest of this PR are some smaller changes to either not cause cycles by trying to access the default anon const substs too early or to be able to access the `tcx` in previously unused locations.
cc `@rust-lang/project-const-generics`
r? `@nikomatsakis`
This is similar to what I was commenting here https://github.com/rust-lang/rust/pull/88332#discussion_r695939901
These is not part of TAITs so should not live in type-alias-impl-trait test directory.
I'm going to avoid adding this kind of tests in `type-alias-impl-trait` test directory and avoid thinking about them in this pass.
Rollup merge of #88340 - thomcc:c_size_t, r=joshtriplett
Add `c_size_t` and `c_ssize_t` to `std::os::raw`.
Apparently these aren't guaranteed to be the same, and are merely "always the same in practice" (see https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60).
This is a big footgun, but I suspect it can be alleviated if we expose this and start migrating people to it in advance of any platforms that ever have this as different.
I'll file a tracking issue after this gets some traction.
More details in the individual commit messages, but the summary is: LLVM deleted an unused-to-them method that we used, we worked around it to avoid annoying cleanup/restructuring in the Rust-side code.
Rollup merge of #88270 - lqd:hrtb-type-ascription, r=nikomatsakis
Handle type ascription type ops in NLL HRTB diagnostics
Currently, there are still a few cases of the "higher-ranked subtype error" of yore, 4 of which are related to type ascription.
This PR is a follow-up to #86700, adding support for type ascription type ops, and makes 3 of these tests output the same diagnostics in NLL mode as the migrate mode (and 1 is now much closer, especially if you ignore that it already outputs an additional error in NLL mode -- which could be a duplicate caused by a lack of normalization like [these comments point out](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/compiler/rustc_traits/src/type_op.rs#L122-L157), or an imprecision in some parts of normalization as [described here](https://github.com/rust-lang/rust/pull/86700#discussion_r689086688)).
Since we discussed these recently:
- [here](https://github.com/rust-lang/rust/pull/86700#discussion_r689158868), cc ````@matthewjasper,````
- and [here](https://github.com/rust-lang/rust/issues/57374#issuecomment-901500856), cc ````@Aaron1011.````
It should only leave [this TAIT test](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.rs) as still emitting [the terse error](https://github.com/rust-lang/rust/blob/9583fd1bdd0127328e25e5b8c24dff575ec2c86b/src/test/ui/type-alias-impl-trait/issue-57611-trait-alias.nll.stderr).
r? ````@estebank```` (so that they shake their fist at NLL's general direction less often) or ````@nikomatsakis```` or matthew or aaron, the more the merrier.
Rollup merge of #87832 - wesleywiser:fix_match_step, r=davidtwco
Fix debugger stepping behavior with `match` expressions
Previously, we would set up the source lines for `match` expressions so
that the code generated to perform the test of the scrutinee was matched
to the line of the arm that required the test and then jump from the arm
block to the "next" block was matched to all of the lines in the `match`
expression.
While that makes sense, it has the side effect of causing strange
stepping behavior in debuggers.
I've changed the source information so that all of the generated tests
are sourced to `match {scrutinee}` and the jumps are sourced to the last
line of the block they are inside. This resolves the weird stepping
behavior in all debuggers and resolves some instances of "ambiguous
symbol" errors in WinDbg preventing the user from setting breakpoints at
`match` expressions.
bors [Thu, 26 Aug 2021 19:15:09 +0000 (19:15 +0000)]
Auto merge of #87194 - eddyb:const-value-mangling, r=michaelwoerister,oli-obk
rustc_symbol_mangling: support structural constants and &str in v0.
This PR should unblock #85530 (except for float `const` generics, which AFAIK should've never worked).
(cc `@tmiasko` could the https://github.com/rust-lang/rust/pull/85530#issuecomment-857855379 failures be retried with a quick crater "subset" run of this PR + changing the default to `v0`? Just to make sure I didn't miss anything other than the floats)
The encoding is the one suggested before in e.g. https://github.com/rust-lang/rust/issues/61486#issuecomment-878932102, tho this PR won't by itself finish #61486, before closing that we'd likely want to move to `@oli-obk's` "valtrees" (i.e. #83234 and other associated work).
<hr>
**EDITs**:
1. switched unit/tuple/braced-with-named-fields `<const-fields>` prefixes from `"u"`/`"T"`/`""` to `"U"`/`"T"`/`"S"` to avoid the ambiguity reported by `@tmiasko` in https://github.com/rust-lang/rust/pull/87194#issuecomment-884279921.
Joshua Nelson [Sat, 21 Aug 2021 20:14:56 +0000 (20:14 +0000)]
Fix the bugs and add a regression test
- All attributes for an item need to be considered at once, they can't
be considered a line at a time.
- The top-level crate was not being visited. This bug was caught by
`extern-crate-used-only-in-link`, which I'm very glad I added.
- Make the loader private to the module, so that only one function is
exposed.
bors [Thu, 26 Aug 2021 15:24:01 +0000 (15:24 +0000)]
Auto merge of #88308 - eddyb:cooked-layouts, r=nagisa
Morph `layout_raw` query into `layout_of`.
Before this PR, `LayoutCx::layout_of` wrapped the `layout_raw` query, to:
* normalize the type, before attempting to compute the layout
* pass the layout to `record_layout_for_printing`, for `-Zprint-type-sizes`
Moving those two responsibilities into the query may reduce overhead (due to cached calls skipping those steps), but I want to do a perf run to know.
One of the changes I had to make was changing the return type of the query, to be able to both get out the type produced by normalizing inside the query *and* to match the signature of the old `TyCtxt::layout_of`. This change may be worse, perf-wise, so that's another reason I want to check.
The above-mentioned commit (part of the LLVM 14 development cycle)
removes a method that rustc uses somewhat extensively. We mostly switch
to lower-level methods that exist in all versions of LLVM we use, so no
new ifdef logic is required in most cases.
.L__unnamed_1:
.asciz "\376\312\357\276\255\336\000"
.zero 16
.size .L__unnamed_1, 24
```
which copies a bunch of zeros in place of the undef bytes, the same as before this change.
Edit: generating partially-undef constants isn't viable at the moment anyways due to #84565, so it's disabled
bors [Thu, 26 Aug 2021 01:14:16 +0000 (01:14 +0000)]
Auto merge of #88069 - Mark-Simulacrum:llvm-pgo, r=pietroalbini
PGO for LLVM builds on x86_64-unknown-linux-gnu in CI
This shows up to 6% less instruction counts with larger - up to 18% - wins on cycles
on multiple benchmarks, and up to 19% wins on the -j1 wall times for rustc self-compilation.
We can afford to spend the extra cycles building LLVM essentially once more for
the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50
minutes on average, and this adds just 10 more minutes. Given the sizeable
improvements in compiler performance, this is definitely worth it.
Noah Lev [Wed, 25 Aug 2021 21:40:06 +0000 (14:40 -0700)]
Adjust spans
* Highlight the whole pattern if it has no fields
* Highlight the whole definition if it has no fields
* Only highlight the pattern name if the pattern is multi-line
* Determine whether a pattern is multi-line based on distance from name
to last field, rather than first field
Mark Rousskov [Tue, 24 Aug 2021 21:15:14 +0000 (17:15 -0400)]
Bump sccache used in CI to v0.2.15
This skips bumping Windows sccache because we run into compilation failures when
doing so (-m32 not supported by clang-cl?). Not clear on cause, but seems
easiest to just hold back.
This should avoid PGO-related failures encountered on Linux, and more broadly
seems like a good idea on other platforms as well (though it is likely not
necessary right this moment).
Fix debugger stepping behavior around `match` expressions
Previously, we would set up the source lines for `match` expressions so
that the code generated to perform the test of the scrutinee was matched
to the line of the arm that required the test and then jump from the arm
block to the "next" block was matched to all of the lines in the `match`
expression.
While that makes sense, it has the side effect of causing strange
stepping behavior in debuggers.
I've changed the source information so that all of the generated tests
are sourced to `match {scrutinee}` and the jumps are sourced to the last
line of the block they are inside. This resolves the weird stepping
behavior in all debuggers and resolves some instances of "ambiguous
symbol" errors in WinDbg preventing the user from setting breakpoints at
`match` expressions.
Rollup merge of #88299 - ijackson:bufwriter, r=Mark-Simulacrum
Stabilise BufWriter::into_parts
The FCP for this has already completed, in #80690.
This was just blocked on #85901 (which changed the name), which is now merged. The original stabilisation MR was #84770 but that has a lot of noise in it, and I also accidentally deleted the branch while trying to tidy up. So here is a new MR. Sorry for the noise.
Rollup merge of #88298 - ijackson:errorkind-reorder, r=dtolnay
Errorkind reorder
I was doing a bit more work in this area and the untidiness of these two orderings bothered me.
The commit messages have the detailed rationale. For your convenience, I c&p them here:
```
io::ErrorKind: rationalise ordering in main enum
It is useful to keep some coherent structure to this ordering. In
particular, Other and Uncategorized should be next to each other, at
the end.
Also it seems to make sense to treat UnexpectedEof and OutOfMemory
specially, since they are not like the other errors (despite
OutOfMemory also being generatable by some OS errors).
So:
* Move Other to the end, just before Uncategorized
* Move Unsupported to between Interrupted and UnexpectedEof
* Add some comments documenting where to add things
```
```
io::Error: alphabeticise the match in as_str()
There was no rationale for the previous ordering.
```
r? kennytm since that's who rust-highfive picked before, in #88294 which I accidentally closed.
7 commits in 7e49659102f0977d9142190e1ba23345c0f00eb1..687e21bde2ea10c261f79fa14797c5137425098d
2021-08-03 21:41:35 -0400 to 2021-08-18 20:48:38 -0400
- Small tweaks to Ferris size and position
- Retain previous height: auto just in case
- Shrink and move ferris when possible
- Snapshot chapter 6 for nostarch
- Demonstrate variable as catch-all for match. Fixes rust-lang/book#1868.
- Improve the if let example to have a binding pattern. Fixes rust-lang/book#1401.
- Fixes typo (rust-lang/book#2816)
5 commits in c4644b427cbdaafc7a87be0ccdf5d8aaa07ac35f..cf0e151b7925a40f13fbc6573c6f97d5f94c7c17
2021-08-10 20:41:44 +0900 to 2021-08-22 11:47:02 -0300
- Fix typo “a Rc” → “an Rc” (rust-lang/rustc-dev-guide#1191)
- Expand THIR section with more details (rust-lang/rustc-dev-guide#1183)
- Remove docs for old -Z profile-queries flag
- update mdbook version to latest
- allow to quickly edit a page directly on github
Rollup merge of #88273 - jhpratt:update-iterator-docs, r=jyn514
Fix references to `ControlFlow` in docs
The `Iterator::for_each` method previously stated that it was not possible to use `break` and `continue` in it — this has been updated to acknowledge the stabilization of `ControlFlow`. Additionally, `ControlFlow` was referred to as `crate::ops::ControlFlow` which is not the correct path for an end user.
Rollup merge of #88226 - steffahn:an_rc, r=michaelwoerister
Fix typo “a Rc” → “an Rc” (and a few more)
After stumbling about it in the dev-guide, I’ve devided to eliminate all mentions of “a Rc”, replacing it with “an Rc”. E.g.
```plain
$ rg "(^|[^'])\ba\b[^\w=:]*\bRc"
compiler/rustc_data_structures/src/owning_ref/mod.rs
1149:/// Typedef of a owning reference that uses a `Rc` as the owner.
library/std/src/ffi/os_str.rs
919: /// Converts a [`OsString`] into a [`Rc`]`<OsStr>` without copying or allocating.
library/std/src/ffi/c_str.rs
961: /// Converts a [`CString`] into a [`Rc`]`<CStr>` without copying or allocating.
src/doc/rustc-dev-guide/src/query.md
61:are cheaply cloneable; insert a `Rc` if necessary).
src/doc/book/src/ch15-06-reference-cycles.md
72:decreases the reference count of the `a` `Rc<List>` instance from 2 to 1 as
library/alloc/src/rc.rs
1746: /// Converts a generic type `T` into a `Rc<T>`
```
_(the match in the book is a false positive)_
Since the dev-guide is a submodule, it’s getting a separate PR: rust-lang/rustc-dev-guide#1191
I’ve also gone ahead and done the same search for `RwLock` and hit a few cases in the `OwningRef` adaption. Then, I couldn’t keep the countless cases of “a owning …” or “a owner” unaddressed, which concludes this PR.
Rollup merge of #88218 - Aaron1011:missing-method-dyn, r=nagisa
Remove `Session.trait_methods_not_found`
Instead, avoid registering the problematic well-formed obligation
to begin with. This removes global untracked mutable state,
and avoids potential issues with incremental compilation.
Rollup merge of #88196 - asquared31415:named-asm-labels-refactor, r=Amanieu
Refactor `named_asm_labels` to a HIR lint
As discussed on #88169, the `named_asm_labels` lint could be moved to a HIR lint. That allows future lints or custom plugins or clippy lints to more easily access the `asm!` macro's data and create better error messages with the lints.
Rollup merge of #88157 - Icenowy:bootstrap-riscv64, r=Mark-Simulacrum
bootstrap.py: recognize riscv64 when auto-detect
The architecture auto-detect table has no entry for riscv64 (which rustc
uses riscv64gc for the first part of triplet, assuming it's a generic
Linux distro).
Add it to the table to allow riscv64 systems to bootstrap Rust.
Rollup merge of #88156 - steffahn:arc_make_mut_and_weak, r=Mark-Simulacrum
Adjust / fix documentation of `Arc::make_mut`
Related discussion in the users forum:
[Whatʼs this alleged difference between Arc::make_mut and Rc::make_mut? – The Rust Programming Language Forum](https://users.rust-lang.org/t/what-s-this-alleged-difference-between-arc-make-mut-and-rc-make-mut/63747?u=steffahn)
Also includes a small formatting improvement in the documentation of `Rc::make_mut`.
This PR makes the two documentations in question complete analogs. The previously claimed point in which one “differs from the behavior of” the other turns out to be incorrect, AFAIK.
One remaining inaccuracy: `Weak` pointers aren’t disassociated from the allocation but only from the contained value, i.e. in case of outstanding `Weak` pointers there still is a new allocation created, just the call to `.clone()` is avoided, instead the value is moved from one allocation to the other.
Rollup merge of #87944 - oconnor663:as_array_of_cells, r=scottmcm
add Cell::as_array_of_cells, similar to Cell::as_slice_of_cells
I'd like to propose adding `Cell::as_array_of_cells`, as a natural analog to `Cell::as_slice_of_cells`. I don't have a specific use case in mind, other than that supporting slices but not arrays feels like a gap. Do other folks agree with that intuition? Would this addition be substantial enough to need an RFC?
---
Previously, converting `&mut [T; N]` to `&[Cell<T>; N]` looks like this:
```rust
let array = &mut [1, 2, 3];
let cells: &[Cell<i32>; 3] = Cell::from_mut(&mut array[..])
.as_slice_of_cells()
.try_into()
.unwrap();
```
With this new helper method, it looks like this:
```rust
let array = &mut [1, 2, 3];
let cells = Cell::from_mut(array).as_array_of_cells();
```
bors [Wed, 25 Aug 2021 13:42:02 +0000 (13:42 +0000)]
Auto merge of #87937 - LeSeulArtichaut:active-if-let-guards, r=nagisa
Don't mark `if_let_guard` as an incomplete feature
I don't think there is any reason for `if_let_guard` to be an incomplete feature, and I think the reason they were marked in the first place was simply because they weren't implemented at all.
bors [Wed, 25 Aug 2021 10:58:43 +0000 (10:58 +0000)]
Auto merge of #85344 - cbeuw:remap-across-cwd, r=michaelwoerister
Correctly handle remapping from path containing the current directory with trailing paths
If we have a `auxiliary/lib.rs`, and we generate the metadata with `--remap-path-prefix $PWD/auxiliary=xyz`, the path to `$PWD/auxiliary/lib.rs` won't be correctly remapped in the metadata. This is because internally, path to the working directory itself and relative paths to files under the working directory are remapped separately (hence neither are affected since neither has `$PWD/auxiliary` as prefix), but the concatenation between the working directory and the relative path is not remapped. This PR fixes that.
bors [Wed, 25 Aug 2021 08:12:16 +0000 (08:12 +0000)]
Auto merge of #87875 - asquared31415:generic-lang-items, r=cjgillot
Improve detection of generics on lang items
Adds detection for the required generics for all lang items. Many lang items require an exact or minimum amount of generic arguments and if they don't exist, the compiler will ICE. This does not add any additional validation about bounds on generics or any other lang item restrictions.
bors [Wed, 25 Aug 2021 05:31:26 +0000 (05:31 +0000)]
Auto merge of #84333 - tmiasko:liveness-yield, r=tmandry
Improve liveness analysis for generators
Liveness analysis for generators assumes that execution always continues
normally after a yield point, not accounting for the fact that generator
could be dropped before completion.
If generators captures any variables by reference, those variables could
be used within a generator, or when the generator completes, but also
after each yield point in the case the generator is dropped.
Account for the case when generator is dropped after yielding, but
before running to the completion. This effectively considers all
variables captured by reference to be used after a yield point.
bors [Wed, 25 Aug 2021 02:17:41 +0000 (02:17 +0000)]
Auto merge of #88242 - bonega:allocation_range, r=oli-obk
Use custom wrap-around type instead of RangeInclusive
Two reasons:
1. More memory is allocated than necessary for `valid_range` in `Scalar`. The range is not used as an iterator and `exhausted` is never used.
2. `contains`, `count` etc. methods in `RangeInclusive` are doing very unhelpful(and dangerous!) things when used as a wrap-around range. - In general this PR wants to limit potentially confusing methods, that have a low probability of working.
Doing a local perf run, every metric shows improvement except for instructions.
Max-rss seem to have a very consistent improvement.
Mark Rousskov [Wed, 11 Aug 2021 17:17:21 +0000 (13:17 -0400)]
PGO for LLVM builds on x86_64-unknown-linux-gnu in CI
This shows up to 5% less instruction counts on multiple benchmarks, and up to
19% wins on the -j1 wall times for rustc self-compilation.
We can afford to spend the extra cycles building LLVM essentially once more for
the x86_64-unknown-linux-gnu CI build today. The builder finishes in around 50
minutes on average, and this adds just 10 more minutes. Given the sizeable
improvements in compiler performance, this is definitely worth it.