During metadata loading, the AdtDefs for every ADT in the universe need
to be loaded (for example, for coherence of builtin traits). For that,
the attributes of the AdtDef need to be loaded too.
The attributes of a struct are duplicated between 2 def ids - the
constructor def-id, and the "type" def id. Loading attributes for both
def-ids, which was done in #53721, slowed the compilation of small
crates by 2-3%. This PR makes sure we only load the attributes for the
"type" def-id, avoiding the slowdown.
Rollup of 16 pull requests
Successful merges:
- #53652 (define copy_within on slices)
- #54261 (Make `dyn` a keyword in the 2018 edition)
- #54280 (remove (more) CAS API from Atomic* types where not natively supported)
- #54323 (rustbuild: drop color handling)
- #54350 (Support specifying edition in doc test)
- #54370 (Improve handling of type bounds in `bit_set.rs`.)
- #54371 (add -Zui-testing to rustdoc)
- #54374 (Make 'proc_macro::MultiSpan' public.)
- #54402 (Use no_default_libraries for all NetBSD flavors)
- #54409 (Detect `for _ in in bar {}` typo)
- #54412 (add applicability to span_suggestion call)
- #54413 (Add UI test for deref recursion limit printing twice)
- #54415 (parser: Tweak function parameter parsing to avoid rollback on succesfull path)
- #54420 (Compress `Liveness` data some more.)
- #54422 (Simplify slice's first(_mut) and last(_mut) with get)
- #54446 (Unify christianpoveda's emails)
Failed merges:
- #54058 (Introduce the partition_dedup/by/by_key methods for slices)
r? @ghost
avoid leaking host details in proc macro metadata decoding
proc macro crates are essentially implemented as dynamic libraries using
a dlopen-based ABI. They are also Rust crates, so they have 2 worlds -
the "host" world in which they are defined, and the "target" world in
which they are used.
For all the "target" world knows, the proc macro crate might not even
be implemented in Rust, so leaks of details from the host to the target
must be avoided for correctness.
Because the "host" DefId space is different from the "target" DefId
space, any leak involving a DefId will have a nonsensical or
out-of-bounds DefKey, and will cause all sorts of crashes.
This PR fixes all leaks I have found in `decoder`. In particular, #54059
was caused by host native libraries leaking into the target, which feels
like it might even be a correctness issue if it doesn't cause an ICE.
Fixes#54059
Simplify slice's first(_mut) and last(_mut) with get
This change makes these functions easier to read and interpret. I haven't detected any difference in performance locally.
r? @Mark-Simulacrum
Compress `Liveness` data some more.
Profiling shows that the `(reader, writer, used)` triples used by
liveness analysis almost always have invalid `reader` and `writer`
fields. We can take advantage of this knowledge to use a compressed
representation for them, falling back to a secondary table for the
uncommon cases.
This change reduces instruction counts on numerous benchmarks, the best
by 16%. It also reduces max-rss on numerous benchmarks, the best by 38%.
The patch also renames these triples from `Users` to `RWU`, because it's
confusing having a type whose name is plural and then used within
vectors whose names are also plural.
r? @nikomatsakis
parser: Tweak function parameter parsing to avoid rollback on succesfull path
Since rollback is not perfect and may e.g. leave non-fatal errors after it, we need to make sure compilation fails if it happens.
So in particular case of `fn parse_arg_general` we need to parse the "good" `TYPE` first and only then rollback and recover erroneous `PAT: TYPE` if necessary.
Found when working on https://github.com/rust-lang/rfcs/pull/2544#issuecomment-423293222.
r? @ghost
Add UI test for deref recursion limit printing twice
Closes#38940
Does ``NOTE`` in the test need to be changed to ``HELP`` if its in the stderr?
``help: consider adding a `#![recursion_limit="20"]` attribute to your crate``
It doesn't appear to complaining locally that the line isn't set to ``HELP`` in the test, and the guide says
> HELP and SUGGESTION*
> * Note: SUGGESTION must follow immediately after HELP.
yet there's no concrete suggestion emitted.
r? @estebank
Use no_default_libraries for all NetBSD flavors
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close#49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
add -Zui-testing to rustdoc
Before we depend on the `rustdoc-ui` tests some more, let's make rustdoc act the same as the compiler when they're actually being executed.
Improve handling of type bounds in `bit_set.rs`.
Currently, `BitSet` doesn't actually know its own domain size; it just
knows how many words it contains. We can make it better.
remove (more) CAS API from Atomic* types where not natively supported
closes#54276
In PR #51953 I made the Atomic* types available on targets like thumbv6m and
msp430 with the intention of *only* exposing the load and store API on those
types -- the rest of the API doesn't work on those targets because the are no
native instructions to implement CAS loops.
Unfortunately, it seems I didn't properly cfg away all the CAS API on those
targets, as evidenced in #54276. This PR amends the issue by removing the rest
of the CAS API.
This is technically a breaking change because *libraries* that were using this
API and were being compiled for e.g. thumbv6m-none-eabi will stop compiling.
However, using those libraries (before this change) in programs (binaries) would
lead to linking errors when compiled for e.g. thumbv6m so this change
effectively shifts a linker error in binaries to a compiler error in libraries.
On a side note: extending the Atomic API is a bit error prone because of these
non-cas targets. Unless the author of the change is aware of these targets and
properly uses `#[cfg(atomic = "cas")]` they could end up exposing new CAS API on
these targets. I can't think of a test to check that an API is not present on
some target, but we could extend the `tidy` tool to check that *all* newly added
atomic API has the `#[cfg(atomic = "cas")]` attribute unless it's whitelisted in
`tidy` then the author of the change would have to verify if the API can be used
on non-cas targets.
In any case, I'd like to plug this hole ASAP. We can revisit testing in a
follow-up issue / PR.
r? @alexcrichton
cc @mvirkkunen
define copy_within on slices
This is a safe wrapper around `ptr::copy`, for regions within a single slice. Previously, safe in-place copying was only available as a side effect of `Vec::drain`.
I've wanted this API a couple times in the past, and I figured I'd just whip up a PR to help discuss it. It's possible something like this exists elsewhere and I just missed it. It might also be a big enough addition to warrant an RFC, I'm not sure.
Stabilize crate_in_paths, extern_absolute_paths and extern_prelude on all editions.
Needed for beta, path-related migrations to Rust 2018 don't work on RC1 without these stabilizations.
r? @aturon cc @nikomatsakis @Centril @alexcrichton
`ui`ify run-pass
This addresses the remainder of #53764 by first converting `src/test/run-pass` into another `ui`-style test suite, and then turning on `compare-mode=nll` for that new suite.
After this lands, we can address #54047 for the short term by moving all the `src/test/ui/run-pass` tests back to `src/test/run-pass`.
(Longer term, the compiler team's current (hypothetical sketch of a) plan (see [1][], [2][]) is unify all the tests by embedding these meta-properties like "// run-pass` into their headers explicitly and dropping the significance of their location on the file system.)
[1]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/subject/weekly.20meeting.202018-09-13/near/133889370
[2]: https://github.com/rust-lang/rust/issues/54047#issuecomment-421030356
This commit brings in a few Cargo updates
* Updates Cargo with experimental HTTP/2 support - a post on the forums
will be made about testing this when available.
* Bumps Cargo's own version number
* In the case of `derive-same-struct`, it seemed cleaner to add the
output than to try to modify the macro itself (which is where the
output is coming from).
* In the case of `custom-derive-partial-eq`, it was just easier to add
the output than to attempt to port the test to use a procedural
macro.
