compiletest: Obtain timestamps for common inputs only once
Obtain timestamps for common inputs (e.g., libraries in run-lib path, or
sources in `src/tool/compiletest/`) only once and reuse the result,
instead of repeating the work for each test case.
Fix link to Exten in Vec::set_len
Fixes#66354
Unrelated to this PR, I think we should stop using `../../std/MODULE` and replace it with `../MODULE` that way if you're looking at docs in `core` or `alloc` clicking at a link won't forward you to `std`.
fix an ICE in macro's diagnostic message
This has two small fixes:
1. for the left brace, we don't need `<space>{`, simply `{` is enough.
2. for the right brace, it tries to peel off one character even when the close delim is missing. Without this fix, it would crash in some cases. (as shown in the new test case)
r? @estebank
Improve errors after re rebalance coherence
Following #65247, I noticed that some error messages should be updated to reflect the changes of `re_rebalance_coherence` (also there was a [note](https://rust-lang.github.io/rfcs/2451-re-rebalancing-coherence.html#teaching-users) in the RFC about it).
First, error message `E0210` was updated to match the RFC, and I also tried to improve a little the error when the "order" of types is problematic.
For code like this:
```
#![feature(re_rebalance_coherence)] // Now stable
struct Wrap<T>(T);
impl<T> From<Wrap<T>> for T {
fn from(x: Wrap<T>) -> T {
x.0
}
}
```
The old error was:
```
error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`)
--> src/lib.rs:5:6
|
5 | impl<T> From<Wrap<T>> for T {
| ^ type parameter `T` must be used as the type parameter for some local type
|
= note: only traits defined in the current crate can be implemented for a type parameter
```
and the new error is:
```
error[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`Wrap<T>`)
--> main.rs:66:6
|
66 | impl<T> From<Wrap<T>> for T {
| ^ type parameter `T` must be covered by another type when it appears before the first local type (`Wrap<T>`)
|
= note: implementing a foreign trait is only possible if at least one of the types for which is it implemented is local, and no uncovered type parameters appear before that first local type
= note: in this case, 'before' refers to the following order: `impl<..> ForeignTrait<T1, ..., Tn> for T0`, where `T0` is the first and `Tn` is the last
```
I tried to point at the uncovered `T`, but couldn't get something which was reliable (but I'll be happy to try if someone points me in the right direction).
r? @estebank
cc @nikomatsakis
Fixes#65247
Fix ICE when documentation includes intra-doc-link
When collecting intra-doc-links we could trigger the loading of extra crates into the crate store due to name resolution finding crates referred to in documentation but not in code. This might be due to
configuration differences or simply referring to something else.
This would cause an ICE because the newly loaded crate metadata existed in a crate store associated with the rustdoc global context, but the resolver had its own crate store cloned just before the documentation processing began and as such it could try and look up crates in a store which lacked them.
In this PR, I add support for `--extern-private` to the `rustdoc` tool so that it is supported for `compiletest` to then pass the crates in; and then I fix the issue by forcing the resolver to look over all the crates before we then lower the input ready for processing into documentation.
The first commit (the `--extern-private`) could be replaced with a commit which adds support for `--extern` to `compiletest` if preferred, though I think that adding `--extern-private` to `rustdoc` is more useful anyway since it makes the CLI a little more like `rustc`'s which might help reduce surprise for someone running it by hand or in their own test code.
The PR is meant to fix#66159 though it may also fix#65840.
cc @GuillaumeGomez
Add a HIR pass to check consts for `if`, `loop`, etc.
Resolves#66125.
This PR adds a HIR pass to check for high-level control flow constructs that are forbidden in a const-context. The MIR const-checker is unable to provide good spans for these since they are lowered to control flow primitives (e.g., `Goto` and `SwitchInt`), and these often don't map back to the underlying statement as a whole. This PR is intended only to improve diagnostics once `if` and `match` become commonplace in constants (behind a feature flag). The MIR const-checker will continue to operate unchanged, and will catch anything this check might miss.
In this implementation, the HIR const-checking pass is run much earlier than the MIR one, so it will supersede any errors from the latter. I will need some mentoring if we wish to change this, since I'm not familiar with the diagnostics system. Moving this pass into the same phase as the MIR const-checker could also help keep backwards compatibility for items like `const _: () = loop { break; };`, which are currently (erroneously?) accepted by the MIR const-checker (see #62272).
r? @Centril
cc @eddyb (since they filed #62272)
This PR BREAKS CODE THAT WAS ACCEPTED ON STABLE. It's arguably a bug
that this was accepted in the first place, but here we are. See #62272
for more info.
These errors will be triggered before the MIR const-checker runs,
causing all other errors to be silenced. They are now checked in the
`const-{if,loop}` tests.
These high-level constructs get mapped to control-flow primitives by the
time the MIR const-checker runs, making it hard to get the span for the
erroneous expression.
Obtain timestamps for common inputs (e.g., libraries in run-lib path, or
sources in `src/tool/compiletest/`) only once and reuse the result,
instead of repeating the work for each test case.
No functional changes intended.
Rollup of 14 pull requests
Successful merges:
- #65932 (download .tar.xz if python3 is used)
- #66094 (Fix documentation for `Iterator::count()`.)
- #66166 (rename cfg(rustdoc) into cfg(doc))
- #66186 (Add long error explanation for E0623)
- #66227 (docs: Fix link to BufWriter::flush)
- #66248 (add raw ptr variant of UnsafeCell::get)
- #66292 (add Result::map_or)
- #66297 (Add a callback that allows compiler consumers to override queries.)
- #66317 (Use a relative bindir for rustdoc to find rustc)
- #66330 (Improve non-exhaustiveness handling in usefulness checking)
- #66331 (Add some tests for fixed ICEs)
- #66334 (Move Session fields to CrateStore)
- #66335 (Move self-profile infrastructure to data structures)
- #66337 (Remove dead code for encoding/decoding lint IDs)
Failed merges:
r? @ghost
Move self-profile infrastructure to data structures
The single dependency on queries (QueryName) can be fairly easily
abstracted via a trait and this further decouples Session from librustc
(the primary goal).
This is intended as a precursor to moving Session out of librustc, but since that involves lots of smaller steps that move around code I'm splitting it up into separate PRs.
Move Session fields to CrateStore
`allocator_kind` and `injected_panic_runtime` are both query-like, this moves them out of Session and into CrateStore, avoiding the `Once` they previously had by clearing separating initialization and de-initialization.
Add some tests for fixed ICEs
Closes#30904 (fixed between nightly-2019-07-14 and nightly-2019-07-31)
Closes#40231 (example 1 is fixed in 1.32.0, example 2 is fixed in 1.38.0)
Closes#52432 (fixed in rustc 1.40.0-beta.1 (76b40532a 2019-11-05))
Closes#63279 (fixed in rustc 1.40.0-nightly (246be7e1a 2019-10-25))
r? @Centril
Improve non-exhaustiveness handling in usefulness checking
The comments around code paths for the `non_exhaustive` feature mention stuff like "we act as if the type had an extra unmatcheable constructor". So I thought I'd make this explicit by defining a special constructor that does exactly this.
This makes those code paths a bit more legible and less prone to error.
Use a relative bindir for rustdoc to find rustc
In bootstrap, we set `RUSTC_INSTALL_BINDIR` to `config.bindir`, so
rustdoc can find rustc relative to the toolchain sysroot. However, if a
distro script like Fedora's `%configure` sets an absolute path, then
rustdoc's `sysroot.join(bin_path)` ignores that sysroot altogether.
That would be OK once the toolchain is actually installed, but it breaks
the in-tree doc tests during the build, since `/usr/bin/rustc` is still
the old version. So now we try to make `RUSTC_INSTALL_BINDIR` relative
to the sysroot prefix in the first place.
r? @Mark-Simulacrum
Add a callback that allows compiler consumers to override queries.
This pull request adds an additional callback that allows compiler consumers such as Prusti and MIRAI to override queries. My hope is that in this way it will be possible to get access to the internal compiler information (e.g. borrow checker) without major changes to the compiler.
This pull request is work in progress because I am still testing if I can get the information which I need.
cc @nikomatsakis
r? @oli-obk
add Result::map_or
This PR adds this API to make it consistent with `Option::map_or`.
```rust
impl<T, E> Result<T, E> {
pub fn map_or<U, F: FnOnce(T) -> U>(self, default: U, f: F) -> U {
match self {
Ok(t) => f(t),
Err(_) => default,
}
}
}
```
This API is very small. We already has a similar API for `Option::map_or`.
add raw ptr variant of UnsafeCell::get
This has come up recently in https://github.com/rust-lang/rust/pull/66051 (Cc @Centril @pitdicker) as well as in discussion with @nikomatsakis and in unrelated discussion with @withoutboats.
docs: Fix link to BufWriter::flush
One of the links in the docs was being rendered as a literal
open-bracket followed by a single quote, instead of being transformed
into a link. Fix it to match the link earlier in the same paragraph.
Fix documentation for `Iterator::count()`.
The documentation of std::core::Iterator::count() stated that the number returned is the number of times `next` is called on the iterator. However this is not true as the number of times `next` is called is exactly one plus the number returned by `count()`.
proposal for BTreeMap/Set min/max, #62924
- Which pair of names: #62924 lists the existing possibilities min/max, first/last, (EDIT) front/back, peek(/peek_back?). Iterators have next/next_back or next/last. I'm slightly in favour of first/last because min/max might suggest they search over the entire map, and front/back pretends they are only about position.
- Return key only instead of pair like iterator does?
- If not, then keep the _key_value suffix? ~~Also provide variant with mutable value? But there is no such variant for get_key_value.~~
- Look for and upgrade more usages of `.iter().next()` and such in the libraries? I only upgraded the ones I contributed myself, all very recently.
