Stabilize `const_constructor`
# Stabilization proposal
I propose that we stabilize `#![feature(const_constructor)]`.
Tracking issue: https://github.com/rust-lang/rust/issues/61456
Version target: 1.40 (2019-11-05 => beta, 2019-12-19 => stable).
## What is stabilized
### User guide
Tuple struct and tuple variant constructors are now considered to be constant functions. As such a call expression where the callee has a tuple struct or variant constructor "function item" type can be called:
```rust
const fn make_options() {
// These already work because they are special cased:
Some(0);
(Option::Some)(1);
// These also work now:
let f = Option::Some;
f(2);
{Option::Some}(3);
<Option<_>>::Some(5);
}
```
### Motivation
Consistency with other `const fn`. Consistency between syntactic path forms.
This should also ensure that constructors implement `const Fn` traits and can be coerced to `const fn` function pointers, if they are introduced.
## Tests
* [ui/consts/const_constructor/const-construct-call.rs](0d75ab2293/src/test/ui/consts/const_constructor/const-construct-call.rs) - Tests various syntactic forms, use in both `const fn` and `const` items, and constructors in both the current and extern crates.
* [ui/consts/const_constructor/const_constructor_qpath.rs](1850dfcdab/src/test/ui/consts/const_constructor/const_constructor_qpath.rs) - Tests that type qualified paths to enum variants are also considered to be `const fn`.(#64247)
r? @oli-obk
Closes#61456
Closes #64247
Gather together usefulness tests
I took most tests that were testing only for match exhaustiveness, pattern refutability or match arm reachability, and put them in the same test folder. I found it helpful to have them all in the same place when working on the usefulness algorithm.
librustc_lexer: Enhance documentation
This PR enhances documentation state of the `librustc_lexer` (as initiative caused by [rustc-guide#474](https://github.com/rust-lang/rustc-guide/issues/474)), by adding:
- Module documentation.
- Doc-comments (and a bit of usual comments) in non-obvious (as for me) places.
r? @petrochenkov
cc @Centril
Stabilize `Option::flatten`
- PR: https://github.com/rust-lang/rust/pull/60256
- Tracking issue: https://github.com/rust-lang/rust/issues/60258
@elahn
> I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it?
@ethanboxx
> @Centril Helped me get this merged. What is the stabilization process?
@Centril
> @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP.
So here I am.
I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
I took most tests that were testing only for match exhaustiveness,
pattern refutability or match arm reachability, and put them in
the same test folder.
This allows us to remove `static_panic_msg` from the SSA<->LLVM
boundary, along with its fat pointer representation for &str.
Also changes the signature of PanicInfo::internal_contructor to
avoid copying.
Closes#65856.
Rollup of 6 pull requests
Successful merges:
- #65566 (Use heuristics to suggest assignment)
- #65738 (Coherence should allow fundamental types to impl traits when they are local)
- #65777 (Don't ICE for completely unexpandable `impl Trait` types)
- #65834 (Remove lint callback from driver)
- #65839 (Clean up `check_consts` now that new promotion pass is implemented)
- #65855 (Add long error explaination for E0666)
Failed merges:
r? @ghost
Clean up `check_consts` now that new promotion pass is implemented
`check_consts::resolver` contained a layer of abstraction (`QualifResolver`) to allow the existing, eager style of qualif propagation to work with either a dataflow results cursor or by applying the transfer function directly (if dataflow was not needed e.g. for promotion). However, #63812 uses a different, lazy paradigm for checking promotability, which makes this unnecessary. This PR cleans up `check_consts::validation` to use `FlowSensitiveResolver` directly, instead of through the now obselete `QualifResolver` API.
Also, this contains a few commits (the first four) that address some FIXMEs in #63812 regarding code duplication. They could be split out, but I think they will be relatively noncontroversial? Notably, `validation::Mode` is renamed to `ConstKind` and used in `promote_consts` to denote what kind of item we are in.
This is best reviewed commit-by-commit and is low priority.
r? @eddyb
Remove lint callback from driver
This is leftover from a restructuring of lint registration for drivers; it should now happen via the register_lints field on Config rather than this function.
This is not used by anyone to my knowledge (including the compiler itself); it was introduced in an abandoned refactor in #65193.
Don't ICE for completely unexpandable `impl Trait` types
Save the resolution of these types (to themselves) to the typeck tables so that they will eventually reach E0720.
closes#65561
Coherence should allow fundamental types to impl traits when they are local
After #64414, `impl<T> Remote for Box<T> { }` is disallowed, but it is also disallowed in liballoc, where `Box` is a local type!
Enabling `#![feature(re_rebalance_coherence)]` in `liballoc` results in:
```
error[E0210]: type parameter `F` must be used as the type parameter for some local type (e.g., `MyStruct<F>`)
--> src\liballoc\boxed.rs:1098:1
|
1098 | impl<F: ?Sized + Future + Unpin> Future for Box<F> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type parameter `F` must be used as the type parameter for some local type
```
This PR relaxes `uncover_fundamental_ty` to skip local fundamental types.
I didn't add a test since `liballoc` already fails to compile, but I can add one if needed.
r? @nikomatsakis
cc #63599
Use heuristics to suggest assignment
When detecting a possible `=` -> `:` typo in a `let` binding, suggest
assigning instead of setting the type.
Partially address #57828.
rustc: add `Span`s to `inferred_outlives_of` predicates.
This would simplify #59789, and I suspect it has some potential in diagnostics (although we don't seem to use the predicate `Span`s much atm).
trait-based structural match implementation
Moves from using a `#[structural_match]` attribute to using a marker trait (or pair of such traits, really) instead.
Fix#63438.
(This however does not remove the hacks that I believe were put into place to support the previous approach of injecting the attribute based on the presence of both derives... I have left that for follow-on work.)
Redesign the interface to the unikernel HermitCore
We are developing the unikernel HermitCore, where the kernel is written in Rust and is already part of the Rust Standard Library. The interface between the standard library and the kernel based on a small C library. With this pull request, we remove completely the dependency to C and use lld as linker. Currently, the kernel will be linked to the application as static library, which is published at https://github.com/hermitcore/libhermit-rs.
We don’t longer support the C interface to the kernel. Consequently, we remove this part from the Rust Standard Library.
Rollup of 8 pull requests
Successful merges:
- #65743 (rustc_typeck: don't record direct callees in generator_interior.)
- #65761 (libsyntax: Enhance documentation of the AST module)
- #65772 (Remove the last remaining READMEs)
- #65773 (Increase spacing for suggestions in diagnostics)
- #65791 (Adding doc on keyword continue)
- #65824 (rustc: make DefPathData (and friends) Copy (now that it uses Symbol).)
- #65828 (Derive Eq and Hash for SourceInfo again)
- #65842 (Add more information on rustdoc search)
Failed merges:
- #65825 (rustc: use IndexVec<DefIndex, T> instead of Vec<T>.)
r? @ghost
