typeck::check::coercion - roll back failed unsizing type vars
This wraps unsizing coercions within an additional level of
`commit_if_ok`, which rolls back type variables if the unsizing coercion
fails. This prevents a large amount of type-variables from accumulating
while type-checking a large function, e.g. shaving 2GB off one of the
4GB peaks in #36799.
This is a performance-sensitive PR so please don't roll it up.
r? @eddyb
cc @nikomatsakis
add comparison operators to must-use lint (under `fn_must_use` feature)
Although RFC 1940 is about annotating functions with `#[must_use]`, a
key part of the motivation was linting unused equality operators.
(See
https://github.com/rust-lang/rfcs/pull/1812#issuecomment-265695898—it
seems to have not been clear to discussants at the time that marking the
comparison methods as `must_use` would not give us the lints on
comparison operators, at least in (what the present author understood
as) the most straightforward implementation, as landed in #43728
(3645b062).)
To rectify the situation, we here lint unused comparison operators as
part of the unused-must-use lint (feature gated by the `fn_must_use`
feature flag, which now arguably becomes a slight (tolerable in the
opinion of the present author) misnomer).
This is in the matter of #43302.
cc @crumblingstatue
This wraps unsizing coercions within an additional level of
`commit_if_ok`, which rolls back type variables if the unsizing coercion
fails. This prevents a large amount of type-variables from accumulating
while type-checking a large function, e.g. shaving 2GB off one of the
4GB peaks in #36799.
Improve diagnostics when attempting to match tuple enum variant with struct pattern
Adds an extra note as below to explain that a tuple pattern was probably intended.
```
error[E0026]: variant `X::Y` does not have a field named `data`
--> src/main.rs:18:16
|
18 | X::Y { data } => println!("The data is {}", data)
| ^^^^ variant `X::Y` does not have field `data`
error[E0027]: pattern does not mention field `0`
--> src/main.rs:18:9
|
18 | X::Y { data } => println!("The data is {}", data)
| ^^^^^^^^^^^^^ missing field `0`
|
= note: trying to match a tuple variant with a struct variant pattern
```
Fixes#41314.
incr.comp.: Add new DepGraph implementation.
This commits does a few things:
1. It adds the new dep-graph implementation -- *in addition* to the old one. This way we can start testing the new implementation without switching all tests at once.
2. It persists the new dep-graph (which includes query result fingerprints) to the incr. comp. caching directory and also loads this data.
3. It removes support for loading fingerprints of metadata imported from other crates (except for when running autotests). This is not needed anymore with red/green. It could provide a performance advantage but that's yet to be determined. For now, as red/green is not fully implemented yet, the cross-crate incremental tests are disabled.
Note, this PR is based on top of soon-to-be-merged #44696 and only the last 4 commits are new:
```
- incr.comp.: Initial implemenation of append-only dep-graph. (c90147c)
- incr.comp.: Do some various cleanup. (8ce20c5)
- incr.comp.: Serialize and deserialize new DepGraph. (0e13c1a)
- incr.comp.: Remove support for loading metadata fingerprints. (270a134)
EDIT 2:
- incr.comp.: Make #[rustc_dirty/clean] test for fingerprint equality ... (d8f7ff9)
```
(EDIT: GH displays the commits in the wrong order for some reason)
Also note that this PR is expected to certainly result in performance regressions in the incr. comp. test cases, since we are adding quite a few things (a whole additional dep-graph, for example) without removing anything. End-to-end performance measurements will only make sense again after red/green is enabled and all the legacy tracking has been turned off.
EDIT 2: Pushed another commit that makes the `#[rustc_dirty]`/`#[rustc_clean]` based autotests compared query result fingerprints instead of testing `DepNode` existence.
Record semantic types for all syntactic types in bodies
... and use recorded types in type privacy checking (types are recorded after inference, so there are no `_`s left).
Also use `hir_ty_to_ty` for types in signatures in type privacy checking.
This could also be potentially useful for save-analysis and diagnostics.
Fixes https://github.com/rust-lang/rust/pull/42125#issuecomment-305987755
r? @eddyb
std::sync::RwLock docs improvement
Addresses the `RwLock` part of #29377.
r? @steveklabnik
Added examples, links to types, and a small comparison between RwLock and Mutex.
Less confusing placeholder when RefCell is exclusively borrowed
Based on ExpHP's comment in [*RefCell.borrow_mut get strange result*](https://users.rust-lang.org/t/refcell-borrow-mut-get-strange-result/12994):
> it would perhaps be nicer if it didn't put something that could be misinterpreted as a valid string value
The previous Debug implementation would show:
RefCell { value: "<borrowed>" }
The new one is:
RefCell { value: <borrowed> }
rustc: Don't use DelimToken::None if possible
This commit fixes a regression from #44601 where lowering attribute to HIR now
involves expanding interpolated tokens to their actual tokens. In that commit
all interpolated tokens were surrounded with a `DelimToken::None` group of
tokens, but this ended up causing regressions like #44730 where the various
attribute parsers in `syntax/attr.rs` weren't ready to cope with
`DelimToken::None`. Instead of fixing the parser in `attr.rs` this commit
instead opts to just avoid the `DelimToken::None` in the first place, ensuring
that the token stream should look the same as it did before where possible.
Closes#44730
Make `-Z borrowck-mir` imply that `EndRegion`'s should be emitted.
Before this change, the `-Z borrowck-mir` flag is useless if you do not also pass `-Z emit-end-regions`.
So, in the same spirit as f2892ad281, make `-Z borrowck-mir` also emit `EndRegion` statements. (This will hopefully avoid some initial speed bumps for new-comers helping out with NLL.)
fix an incorrect assertion in the doc example for `std::io::copy`
I think this wasn't caught by CI because the `foo` wrapper function was only defined and not called. This seems to be the norm for doc examples that define a `foo` function. Is that on purpose?
Expand size_of docs
This PR does 3 things.
1. Adds a description of what pointer size means to the primitive pages for usize and isize.
2. Says the general size of things is not stable from compiler to compiler.
3. Adds a table of sizes of things that we do guarantee. As this is the first table in the libstd docs, I've included a picture of how that looks.
