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](https://github.com/rust-lang/rust/blob/0d75ab2293a106eb674ac01860910cfc1580837e/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](https://github.com/rust-lang/rust/blob/1850dfcdabf8258a1f023f26c2c59e96b869dd95/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)
Rollup merge of #65880 - Nadrieril:gather-usefulness-tests, r=varkor
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.
Rollup merge of #65849 - popzxc:document-librustc_lexer, r=petrochenkov
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.
@eddyb suggested doing this intrinsic implementation ahead of actually implementing the `#[track_caller]` attribute so that there's an easily tested intermediate step between adding the shim and wiring up the attribute.
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.
bors [Sun, 27 Oct 2019 16:15:40 +0000 (16:15 +0000)]
Auto merge of #65869 - Centril:rollup-bzlo74f, r=Centril
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)
Rollup merge of #65839 - ecstatic-morse:promo-sanity-fixes, r=eddyb
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.
Rollup merge of #65834 - Mark-Simulacrum:driver-clean, r=nikomatsakis
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.
Rollup merge of #65738 - ohadravid:re-rebalance-coherence-allow-fundamental-local, r=nikomatsakis
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.
bors [Sun, 27 Oct 2019 09:35:12 +0000 (09:35 +0000)]
Auto merge of #65519 - pnkfelix:issue-63438-trait-based-structural-match, r=matthewjasper
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.)
bors [Sat, 26 Oct 2019 19:35:59 +0000 (19:35 +0000)]
Auto merge of #65167 - hermitcore:rusty-hermit, r=alexcrichton
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.
bors [Sat, 26 Oct 2019 16:14:16 +0000 (16:14 +0000)]
Auto merge of #65845 - Centril:rollup-28jtjfc, r=Centril
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>.)
Rollup merge of #65828 - bjorn3:add_source_info_eq_hash, r=petrochenkov
Derive Eq and Hash for SourceInfo again
In https://github.com/bjorn3/rustc_codegen_cranelift/blob/75c24b9c9677600422ec86fa9f4c78fe3678d2ce/src/common.rs#L368 I store it in a `indexmap::IndexSet`, which requires `Eq` and `Hash`. Unfortunately they were removed in https://github.com/rust-lang/rust/pull/65647, so I can't update to latest nightly.
Rollup merge of #65761 - popzxc:document-ast, r=petrochenkov
libsyntax: Enhance documentation of the AST module
This PR enhances documentation state to the `libsyntax/ast.rs` (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.
- Minor style fixes to improve module readability.
Rollup merge of #65743 - eddyb:generator-on-call, r=matthewjasper
rustc_typeck: don't record direct callees in generator_interior.
For expressions like `f(g().await)` we were recording `f` as needing to be kept in a temporary (and therefore be tracked by the generator type) across the suspend, even if a function/method path.
However, this is never needed, and can cause issues with complex function types (see #65244).
Dylan MacKenzie [Wed, 23 Oct 2019 19:10:08 +0000 (12:10 -0700)]
Remove `QualifResolver` abstraction
This is a relic from earlier attempts at dataflow-based const validation
that attempted to do promotion at the same time. #63812 takes a
different approach: `IsNotPromotable` is no longer a `Qualif` and is
computed lazily instead of eagerly. As a result, there's no need for an
eager `TempPromotionResolver`, and we can use the only implementer of
`QualifResolver` directly instead of through a trait.
bors [Sat, 26 Oct 2019 00:11:36 +0000 (00:11 +0000)]
Auto merge of #63812 - eddyb:promo-sanity, r=oli-obk
rustc_mir: double-check const-promotion candidates for sanity.
Previously, const promotion involved tracking information about the value in a MIR local (or any part of the computation leading up to that value), aka "qualifs", in a quite stateful manner, which is hard to extend to arbitrary CFGs without a dataflow pass.
However, the nature of the promotion we do is that it's effectively an SSA-like "tree" (or DAG, really), of assigned-once locals - which is how we can take them from the original MIR in the first place.
This structure means that the subset of the MIR responsible for computing any given part of a const-promoted value is readily analyzable by walking that tree/DAG.
This PR implements such an analysis in `promote_consts`, reusing the `HasMutInterior` / `NeedsDrop` computation from `qualify_consts`, but reimplementing the equivalent of `IsNotPromotable` / `IsNotImplicitlyPromotable`.
Eventually we should be able to remove `IsNotPromotable` / `IsNotImplicitlyPromotable` from `qualify_consts`, which will simplify @ecstatic-morse's dataflow-based const-checking efforts.
But currently this is mainly for a crater check-only run - it will compare the results from the old promotion collection and the new promotion validation and ICE if they don't match.
Mark Rousskov [Fri, 25 Oct 2019 23:27:57 +0000 (19:27 -0400)]
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.
bors [Fri, 25 Oct 2019 20:41:28 +0000 (20:41 +0000)]
Auto merge of #65826 - JohnTitor:rollup-mr6crka, r=JohnTitor
Rollup of 6 pull requests
Successful merges:
- #65705 (Add {String,Vec}::into_raw_parts)
- #65749 (Insurance policy in case `iter.size_hint()` lies.)
- #65799 (Fill tracking issue number for `array_value_iter`)
- #65800 (self-profiling: Update measureme to 0.4.0 and remove non-RAII methods from profiler.)
- #65806 (Add [T]::as_ptr_range() and [T]::as_mut_ptr_range().)
- #65810 (SGX: Clear additional flag on enclave entry)
Yuki Okushi [Fri, 25 Oct 2019 17:46:02 +0000 (02:46 +0900)]
Rollup merge of #65810 - raoulstrackx:ac_mitigation, r=nagisa
SGX: Clear additional flag on enclave entry
An attacker could set both the AC flag in CR0 as in rflags. This causes the enclave to perform an AEX upon a misaligned memory access, and an attacker learns some information about the internal enclave state.
The AC flag in rflags is copied from userspace upon an enclave entry. Upon AEX it is copied and later restored. This patch forces the rflag.AC bit to be reset right after an enter.
Yuki Okushi [Fri, 25 Oct 2019 17:45:59 +0000 (02:45 +0900)]
Rollup merge of #65800 - michaelwoerister:measureme-0.4.0, r=wesleywiser
self-profiling: Update measureme to 0.4.0 and remove non-RAII methods from profiler.
This PR removes all non-RAII based profiling methods from `SelfProfilerRef` :tada:
It also delegates the `TimingGuard` implementation to `measureme`, now that that is available there.
Yuki Okushi [Fri, 25 Oct 2019 17:45:57 +0000 (02:45 +0900)]
Rollup merge of #65749 - Centril:insurance-policy, r=RalfJung
Insurance policy in case `iter.size_hint()` lies.
Follow up to https://github.com/rust-lang/rust/pull/64949/files#r334235076.
(If the perf impact is bad we can use `debug_assert!` instead.)
The good news is that the UI tests pass locally so `iter.size_hint()` seems to be honest *thus far*.
On the other hand, with the status quo we do not have an insurance policy should that change in some case. This is problematic because a) this could possibly make some program be accepted which shouldn't, b) the compiler itself could have memory unsafety if the correctness of the iterator is assumed in `unsafe { ... }` code (even though the blame lies with the `unsafe { ... }` block in question.)
Migrate from `#[structural_match]` attribute a lang-item trait.
(Or more precisely, a pair of such traits: one for `derive(PartialEq)` and one
for `derive(Eq)`.)
((The addition of the second marker trait, `StructuralEq`, is largely a hack to
work-around `fn (&T)` not implementing `PartialEq` and `Eq`; see also issue
rust-lang/rust#46989; otherwise I would just check if `Eq` is implemented.))
Note: this does not use trait fulfillment error-reporting machinery; it just
uses the trait system to determine if the ADT was tagged or not. (Nonetheless, I
have kept an `on_unimplemented` message on the new trait for structural_match
check, even though it is currently not used.)
Note also: this does *not* resolve the ICE from rust-lang/rust#65466, as noted
in a comment added in this commit. Further work is necessary to resolve that and
other problems with the structural match checking, especially to do so without
breaking stable code (adapted from test fn-ptr-is-structurally-matchable.rs):
where we would hit a problem with the strategy of unconditionally checking for
`PartialEq` because the type `for <'a> fn(&'a SM)` does not currently even
*implement* `PartialEq`.
----
added review feedback:
* use an or-pattern
* eschew `return` when tail position will do.
* don't need fresh_expansion; just add `structural_match` to appropriate `allow_internal_unstable` attributes.
also fixed example in doc comment so that it actually compiles.
Rollup merge of #65731 - fusion-engineering-forks:set-extension, r=dtolnay
Prevent unnecessary allocation in PathBuf::set_extension.
It was allocating a new `OsString` that was immediately dropped after using it with `set_file_name`. Now it directly changes the extension in the original buffer, without touching the rest of the file name or allocating a temporary string.
Rollup merge of #65685 - oxalica:statx-eperm, r=alexcrichton
Fix check of `statx` and handle EPERM
Should fix #65662
https://github.com/rust-lang/rust/issues/65662#issuecomment-544593939
> I think a reasonable solution might be to do something like try to stat AT_CWD initially and if that fails with EPERM or ENOSYS we disable the syscall entirely, otherwise it's cached as always good to use.
Rollup merge of #65315 - spastorino:intern-place-projection, r=oli-obk
Intern place projection
This should sit on top of https://github.com/rust-lang/rust/pull/65197. After that one merged, I'm gonna rebase on top of it.
The important commits are the last three and there's a bunch of code repetition that I'm going to remove but for that I need to refactor some things that probably need to be added before this PR.
Anyway this work helps as is because we can run perf tests :).
Rollup merge of #65074 - Rantanen:json-byte-pos, r=matklad
Fix the start/end byte positions in the compiler JSON output
Track the changes made during normalization in the `SourceFile` and use this information to correct the `start_byte` and `end_byte` fields in the JSON output.
This should ensure the start/end byte fields can be used to index the original file, even if Rust normalized the source code for parsing purposes. Both CRLF to LF and BOM removal are handled with this one.
The rough plan was discussed with @matklad in rust-lang-nursery/rustfix#176 - although I ended up going with `u32` offset tracking so I wouldn't need to deal with `u32 + i32` arithmetics when applying the offset to the span byte positions.
Rollup merge of #64639 - davidtwco:rfc-2008-stabilization, r=Centril
Stabilize `#[non_exhaustive]` (RFC 2008)
Fixes #44109.
This pull request stabilizes the `#[non_exhaustive]` attribute, which is used to indicate that a type will have more fields / variants added in the future. It can be applied to `struct`s, `enum`s and `enum` variants. See https://github.com/rust-lang/rust/issues/44109#issuecomment-533356866 for the stabilization report.