default binding modes: add pat_binding_modes
This PR kicks off the implementation of the [default binding modes RFC][1] by
introducing the `pat_binding_modes` typeck table mentioned in the [mentoring
instructions][2].
It is a WIP because I wasn't able to avoid all uses of the binding modes as
not all call sites are close enough to the typeck tables. I added marker
comments to any line matching `BindByRef|BindByValue` so that reviewers
are aware of all of them.
I will look into changing the HIR (as suggested in [2]) to not carry a
`BindingMode` unless one was explicitly specified, but this PR is good for
a first round of comments.
The actual changes are quite small and CI will fail due to overlong lines
caused by the marker comments.
See #42640.
cc @nikomatsakis
[1]: https://github.com/rust-lang/rfcs/pull/2005
[2]: https://github.com/rust-lang/rust/issues/42640#issuecomment-313535089
CFG construction takes a large amount of time and memory, especially for
large constants. If such a constant contains no actions on lvalues, it
can't have borrowck problems and can be ignored by it.
This removes the 4.9GB borrowck peak from #36799. It seems that HIR had
grown by 300MB and MIR had grown by 500MB from the last massif
collection and that remains to be investigated, but this at least shaves
the borrowck peak.
rustbuild: Remove `--enable-llvm-clean-rebuild`
This was intended for bots back in the day where we'd persist caches of LLVM
builds across runs, but nowadays we don't do that on any of the bots so this
option is no longer necessary
save subobligations in the projection cache
The projection cache explicitly chose not to "preserve" subobligations for projections, since the fulfillment context ought to have been doing so. But for the trait evaluation scheme that causes problems. This PR reproduces subobligations. This has the potential to slow down compilation, but minimal investigation suggests it does not do so.
One hesitation about this PR: I could not find a way to make a standalone test case for #43132 (but admittedly I did not try very hard).
Fixes#43132.
r? @arielb1
a couple more error explanations for posterity
E0436, E0595, and moving E0569 to where it belongs in the file rather than being bizarrely out of numerical order
r? @GuillaumeGomez
This was intended for bots back in the day where we'd persist caches of LLVM
builds across runs, but nowadays we don't do that on any of the bots so this
option is no longer necessary
librustc_driver: Remove -Z option from usage on stable compiler
The `-Z` flag has been disabled since Rust 1.19 stable, but it still shows in `rustc --help`.
This PR addresses the inconsistency by removing the message on the stable channel.
We want the error explanations to appear in numerical order so that
they're easy to find. (Also, any other order would be arbitrary and thus
not constitute a Schelling point.) Bizarrely, the extended information
for E0569 was placed between E0244 and E0318 in
librustc_typeck/diagnostics.rs (when the code was introduced in
9a649c32). This commit moves it to be between E0562 and E0570, where it
belongs.
(Also, at reviewer request, say "Erroneous code example", the standard
verbiage that it has been decided that we say everywhere.)
This example focuses on struct-like enum variants, because it's not
immediately obvious in what other context we can get E0436 alone,
without any other, more serious, errors. (Triggering E0436 with a union
also emits a separate "union expressions should have exactly one field"
error.)
(One might argue that we ought to accept the functional record update
syntax for struct-like enums, but that is beyond the scope of this
error-index-comprehensiveness commit.)
rustdoc: print associated types in traits "implementors" section
When viewing a trait's implementors, they won't show anything about the implementation other than any bounds on the generics. You can see the full implementation details on the page for the type, but if the type is external (e.g. it's an extension trait being implemented for primitives), then you'll never be able to see the details of the implementation without opening the source code. This doesn't solve everything about that, but it does still show an incredibly useful piece of information: the associated types. This can help immensely for traits like `Deref` or `IntoIterator` in libstd, and also for traits like `IntoFuture` outside the standard library.
Fixes#24200🚨 BIKESHED ALERT 🚨 The indentation and sizing of the types is suspect. I put it in the small text so it wouldn't blend in with the next impl line. (It shares a CSS class with the where clauses, as you can see in the following image.) However, the indentation is nonstandard. I initially tried with no indentation (looked awkward and blended too well with the surrounding impls) and with 4-space indentation (too easy to confuse with where clauses), before settling on the 2-space indentation seen below. It's... okay, i guess. Open to suggestions.
