Ensure that queries only return Copy types.
This should pervent the perf footgun of returning a result with an expensive `Clone` impl (like a `Vec` of a hash map).
I went for the stupid solution of allocating on an arena everything that was not `Copy`. Some query results could be made Copy easily, but I did not really investigate.
Fix typo in `std::fmt` docs
Hey!
Reading the docs (https://doc.rust-lang.org/std/fmt/#named-parameters), this seems like a typo?
The docs here also seem to mix “named argument” and “named parameter”? Intentional? Mistake?
debuginfo: Fix DW_AT_containing_type vtable debuginfo regression
This PR brings back the `DW_AT_containing_type` attribute for vtables after it has accidentally been removed in #89597.
It also implements a more accurate description of vtables. Instead of describing them as an array of void pointers, the compiler will now emit a struct type description with a field for each entry of the vtable.
r? ``@wesleywiser``
This PR should fix issue https://github.com/rust-lang/rust/issues/93164.
~~The PR is blocked on https://github.com/rust-lang/rust/pull/93154 because both of them modify the `codegen/debug-vtable.rs` test case.~~
Better suggestions when user tries to collect into an unsized `[_]`
1. Extend the predicate on `rustc_on_unimplemented` to support substitutions like note, label, etc (i.e. treat it as a `OnUnimplementedFormatString`) so we can have slightly more general `rustc_on_unimplemented` special-cases.
2. Add a `rustc_on_unimplemented` if we fail on `FromIterator<A> for [A]` which happens when we don't explicitly collect into a `vec<A>`, but then pass the return from a `.collect` call into something that takes a slice.
Fixes#91423
Refactor query system to maintain a global job id counter
This replaces the per-shard counters with a single global counter, simplifying
the JobId struct down to just a u64 and removing the need to pipe a DepKind
generic through a bunch of code. The performance implications on non-parallel
compilers are likely minimal (this switches to `Cell<u64>` as the backing
storage over a `u64`, but the latter was already inside a `RefCell` so it's not
really a significance divergence). On parallel compilers, the cost of a single
global u64 counter may be more significant: it adds a serialization point in
theory. On the other hand, we can imagine changing the counter to have a
thread-local component if it becomes worrisome or some similar structure.
The new design is sufficiently simpler that it warrants the potential for slight
changes down the line if/when we get parallel compilation to be more of a
default.
A u64 counter, instead of u32 (the old per-shard width), is chosen to avoid
possibly overflowing it and causing problems; it is effectively impossible that
we would overflow a u64 counter in this context.
Delete -Zquery-stats infrastructure
These statistics are computable from the self-profile data and/or ad-hoc collectable as needed, and in the meantime contribute to rustc bootstrap times -- locally, this PR shaves ~2.5% from rustc_query_impl builds in instruction counts.
If this does lose some functionality we want to keep, I think we should migrate it to self-profile (or a similar interface) rather than this ad-hoc reporting.
Store rlink data in opaque binary format on disk
This removes one of the only uses of JSON decoding (to Rust structs) from the compiler, and fixes the FIXME comment. It's not clear to me what the reason for using JSON here originally was, and from what I can tell nothing outside of rustc expects to read the emitted information, so it seems like a reasonable step to move it to the metadata-encoding format (rustc_serialize::opaque).
Mostly intended as a FIXME fix, though potentially a stepping stone to dropping the support for Decodable to be used to decode JSON entirely (allowing for better/faster APIs on the Decoder trait).
cc #64191
Improve opaque type higher-ranked region error message under NLL
Currently, any higher-ranked region errors involving opaque types
fall back to a generic "higher-ranked subtype error" message when
run under NLL. This PR adds better error message handling for this
case, giving us the same kinds of error messages that we currently
get without NLL:
```
error: implementation of `MyTrait` is not general enough
--> $DIR/opaque-hrtb.rs:12:13
|
LL | fn foo() -> impl for<'a> MyTrait<&'a str> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough
|
= note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>`, for any lifetime `'1`...
= note: ...but it actually implements `MyTrait<&'2 str>`, for some specific lifetime `'2`
error: aborting due to previous error
```
To accomplish this, several different refactoring needed to be made:
* We now have a dedicated `InstantiateOpaqueType` struct which
implements `TypeOp`. This is used to invoke `instantiate_opaque_types`
during MIR type checking.
* `TypeOp` is refactored to pass around a `MirBorrowckCtxt`, which is
needed to report opaque type region errors.
* We no longer assume that all `TypeOp`s correspond to canonicalized
queries. This allows us to properly handle opaque type instantiation
(which does not occur in a query) as a `TypeOp`.
A new `ErrorInfo` associated type is used to determine what
additional information is used during higher-ranked region error
handling.
* The body of `try_extract_error_from_fulfill_cx`
has been moved out to a new function `try_extract_error_from_region_constraints`.
This allows us to re-use the same error reporting code between
canonicalized queries (which can extract region constraints directly
from a fresh `InferCtxt`) and opaque type handling (which needs to take
region constraints from the pre-existing `InferCtxt` that we use
throughout MIR borrow checking).
Drop tracking: track borrows of projections
Previous efforts to ignore partially consumed values meant we were also not considering borrows of a projection. This led to cases where we'd miss borrowed types which MIR expected to be there, leading to ICEs.
This PR also includes the `-Zdrop-tracking` flag from #93313. If that PR lands first, I'll rebase to drop the commit from this one.
Fixes#93648
rustc_query_impl: reduce visibility of some modules/fn's
Locally this reduces number of exported functions from 15221 -> 14952 and size a little.
Perf run please?
Remove defaultness from ImplItem.
This information is not really used anywhere, except HIR pretty-printing. This makes ImplItem and TraitItem more similar.
rustdoc: tweak line spacing and paragraph spacing for accessibility
The [W3C Web Content Accessibility Guidelines](https://www.w3.org/WAI/WCAG21/Understanding/visual-presentation.html) specify a minimum line spacing of 1.5 and a minimum paragraph spacing of 1.5 times the line spacing. Our current line spacing (implemented by line-height) is 1.4, so it's a small bump to go up to 1.5. Similarly, we have a paragraph spacing of 0.6em. Bump that to 0.75em (which is 1.5 times the 0.5em distance between lines).
Also, fix all the font sizes so instead of being round-ish numbers in rem (like 1.1rem, 1.2rem), they are round numbers in pixels: 16px, 18px, 20px, 22px, 24px. Ensure each font size is at least 2 pixels different than the nearest other font size, so distinctions can be clearly seen. Overall the font-sizes are mostly staying the same, being rounded up or down as appropriate. This will make reasoning about consistent layout sizes much easier.
Remove a few unused styles.
Simplify the display of the mobile-topbar location, by setting its margins to auto rather than trying to size it exactly to the topbar.
Part of #59845.
Demo: https://rustdoc.crud.net/jsha/font-sizes-spacing/std/string/struct.String.html
r? `@GuillaumeGomez`
Update cargo
5 commits in 25fcb135d02ea897ce894b67ae021f48107d522b..c082648646cbb2be266df9ecbcdc253058158d68
2022-02-01 01:32:48 +0000 to 2022-02-08 14:55:05 +0000
- Add rustup link (rust-lang/cargo#10371)
- Improve startup time of bash completion. (rust-lang/cargo#10365)
- Stabilize `-Ztimings` as `--timings` (rust-lang/cargo#10245)
- Remove needless borrow (rust-lang/cargo#10360)
- Compute non custom build and non transitive deps for doc (rust-lang/cargo#10341)
Rollup of 7 pull requests
Successful merges:
- #91950 (Point at type when a `static` `#[global_allocator]` doesn't `impl` `GlobalAlloc`)
- #92715 (Do not suggest char literal for zero-length strings)
- #92917 (Don't constrain projection predicates with inference vars in GAT substs)
- #93206 (Use `NtCreateFile` instead of `NtOpenFile` to open a file)
- #93732 (add fut/back compat tests for implied trait bounds)
- #93764 (⬆️ rust-analyzer)
- #93767 (deduplicate `lcnr` in mailmap)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This replaces the per-shard counters with a single global counter, simplifying
the JobId struct down to just a u64 and removing the need to pipe a DepKind
generic through a bunch of code. The performance implications on non-parallel
compilers are likely minimal (this switches to `Cell<u64>` as the backing
storage over a `u64`, but the latter was already inside a `RefCell` so it's not
really a significance divergence). On parallel compilers, the cost of a single
global u64 counter may be more significant: it adds a serialization point in
theory. On the other hand, we can imagine changing the counter to have a
thread-local component if it becomes worrisome or some similar structure.
The new design is sufficiently simpler that it warrants the potential for slight
changes down the line if/when we get parallel compilation to be more of a
default.
A u64 counter, instead of u32 (the old per-shard width), is chosen to avoid
possibly overflowing it and causing problems; it is effectively impossible that
we would overflow a u64 counter in this context.
Currently, any higher-ranked region errors involving opaque types
fall back to a generic "higher-ranked subtype error" message when
run under NLL. This PR adds better error message handling for this
case, giving us the same kinds of error messages that we currently
get without NLL:
```
error: implementation of `MyTrait` is not general enough
--> $DIR/opaque-hrtb.rs:12:13
|
LL | fn foo() -> impl for<'a> MyTrait<&'a str> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `MyTrait` is not general enough
|
= note: `impl MyTrait<&'2 str>` must implement `MyTrait<&'1 str>`, for any lifetime `'1`...
= note: ...but it actually implements `MyTrait<&'2 str>`, for some specific lifetime `'2`
error: aborting due to previous error
```
To accomplish this, several different refactoring needed to be made:
* We now have a dedicated `InstantiateOpaqueType` struct which
implements `TypeOp`. This is used to invoke `instantiate_opaque_types`
during MIR type checking.
* `TypeOp` is refactored to pass around a `MirBorrowckCtxt`, which is
needed to report opaque type region errors.
* We no longer assume that all `TypeOp`s correspond to canonicalized
queries. This allows us to properly handle opaque type instantiation
(which does not occur in a query) as a `TypeOp`.
A new `ErrorInfo` associated type is used to determine what
additional information is used during higher-ranked region error
handling.
* The body of `try_extract_error_from_fulfill_cx`
has been moved out to a new function `try_extract_error_from_region_constraints`.
This allows us to re-use the same error reporting code between
canonicalized queries (which can extract region constraints directly
from a fresh `InferCtxt`) and opaque type handling (which needs to take
region constraints from the pre-existing `InferCtxt` that we use
throughout MIR borrow checking).
add fut/back compat tests for implied trait bounds
the `guard` test was tested to cause a segfault with `-Zchalk`, very nice
cc ``@nikomatsakis`` #44491#25860
Use `NtCreateFile` instead of `NtOpenFile` to open a file
Generally the internal `Nt*` functions should be avoided but when we do need to use one we should stick to the most commonly used for the job. To that end, this PR replaces `NtOpenFile` with `NtCreateFile`.
NOTE: The initial version of this comment hypothesised that this may help with some recent false positives from malware scanners. This hypothesis proved wrong. Sorry for the distraction.
Don't constrain projection predicates with inference vars in GAT substs
cc #91762
Not a fix, but a mitigation to prevent a backwards-compatible hazard where we normalize using a predicate only because it's the only one available, but shouldn't. This would constrain an inference variable which didn't really want. We already do this when selecting a projection candidate, which isn't always correct. But changing that is a problem for a different day.
Also found out that a suggestion for `await`ing a future was using the wrong substs.
r? ``@nikomatsakis``
Do not suggest char literal for zero-length strings
PR #92507 adds a hint to switch to single quotes when a char is expected and a single-character string literal is provided.
The check to ensure the string literal is one character long missed the 0-char case, and would incorrectly offer the hint.
This PR adds the missing check, and a test case to confirm the new behavior.
