Update cargo
8 commits in 8a0d4d9c9abc74fd670353094387d62028b40ae9..6e07d2dfb7fc87b1c9489de41da4dafa239daf03
2020-03-24 17:57:04 +0000 to 2020-03-31 03:22:39 +0000
- Fix man page typo for "Owner Options". (rust-lang/cargo#8057)
- enable progress bar on all UNIX platforms (rust-lang/cargo#8054)
- Squelch some rustdoc warnings. (rust-lang/cargo#8052)
- Remove clippy tests. (rust-lang/cargo#8053)
- Fix -Zfeatures=itarget with certain host dependencies (rust-lang/cargo#8048)
- Checking for binary that is built as an implicit dependency of an integration test. (rust-lang/cargo#8020)
- Use stabilized version of rustdoc's --crate-version (rust-lang/cargo#8039)
- Remove the `git-checkout` subcommand. (rust-lang/cargo#8040)
compiletest: don't use `std::io::stdout()`, as it bypasses `set_print`.
This PR undoes a change made during #69916, which became unnecessary during review but was left in by accident, and which isn't correct due to `libtest` using `std::io::set_print`, which overwrites the `println!` behavior but *not* `writeln!(std::io::stdout(), ...)`.
The effect of using `writeln!(std::io::stdout(), ...)` was that the diff output would show *while* running the tests, instead of at the end, when failing tests are listed.
r? @Mark-Simulacrum cc @oli-obk
cargotest: remove webrender
The current webrender commit occasionally fails without a reason, and the latest webrender commit is missing a dependency on our Windows builders. It's not worth installing an extra dependency for cargotest, and the spurious failure makes keeping this test not worth it.
r? @Mark-Simulacrum
The current webrender commit occasionally fails without a reason, and
the latest webrender commit is missing a dependency on our Windows
builders. It's not worth installing an extra dependency for cargotest,
and the spurious failure makes keeping this test not worth it.
Shrink Unicode tables (even more)
This shrinks the Unicode tables further, building upon the wins in #68232 (the previous counts differ due to an interim Unicode version update, see #69929.
The new data structure is slower by around 3x, on the benchmark of looking up every Unicode scalar value in each data set sequentially in every data set included. Note that for ASCII, the exposed functions on `char` optimize with direct branches, so ASCII will retain the same performance regardless of internal optimizations (or the reverse). Also, note that the size reduction due to the skip list (from where the performance losses come) is around 40%, and, as a result, I believe the performance loss is acceptable, as the routines are still quite fast. Anywhere where this is hot, should probably be using a custom data structure anyway (e.g., a raw bitset) or something optimized for frequently seen values, etc.
This PR updates both the bitset data structure, and introduces a new data structure similar to a skip list. For more details, see the [main.rs] of the table generator, which describes both. The commits mostly work individually and document size wins.
As before, this is tested on all valid chars to have the same results as nightly (and the canonical Unicode data sets), happily, no bugs were found.
[main.rs]: fb4a715e18/src/tools/unicode-table-generator/src/main.rs
Set | Previous | New | % of old | Codepoints | Ranges |
----------------|---------:|------:|-----------:|-----------:|-------:|
Alphabetic | 3055 | 1599 | 52% | 132875 | 695 |
Case Ignorable | 2136 | 949 | 44% | 2413 | 410 |
Cased | 934 | 359 | 38% | 4286 | 141 |
Cc | 43 | 9 | 20% | 65 | 2 |
Grapheme Extend | 1774 | 813 | 46% | 1979 | 344 |
Lowercase | 985 | 867 | 88% | 2344 | 652 |
N | 1266 | 419 | 33% | 1781 | 133 |
Uppercase | 934 | 777 | 83% | 1911 | 643 |
White_Space | 140 | 37 | 26% | 25 | 10 |
----------------|----------|-------|------------|------------|--------|
Total | 11267 | 5829 | 51% | - | - |
In practice, for the two data sets that still use the bitset encoding (uppercase
and lowercase) this is not a significant win, so just drop it entirely. It costs
us about 5 bytes, and the complexity is nontrivial.
This arranges for the sparser sets (everything except lower and uppercase) to be
encoded in a significantly smaller context. However, it is also a performance
trade-off (roughly 3x slower than the bitset encoding). The 40% size reduction
is deemed to be sufficiently important to merit this performance loss,
particularly as it is unlikely that this code is hot anywhere (and if it is,
paying the memory cost for a bitset that directly represents the data seems
worthwhile).
Alphabetic : 1599 bytes (- 937 bytes)
Case_Ignorable : 949 bytes (- 822 bytes)
Cased : 359 bytes (- 429 bytes)
Cc : 9 bytes (- 15 bytes)
Grapheme_Extend: 813 bytes (- 675 bytes)
Lowercase : 863 bytes
N : 419 bytes (- 619 bytes)
Uppercase : 776 bytes
White_Space : 37 bytes (- 46 bytes)
Total table sizes: 5824 bytes (-3543 bytes)
Changes:
````
remove redundant import
rustup https://github.com/rust-lang/rust/pull/68404
rustup https://github.com/rust-lang/rust/pull/69644
rustup https://github.com/rust-lang/rust/pull/70344
Move verbose_file_reads to restriction
move redundant_pub_crate to nursery
readme: explain how to run only a single lint on a codebase
Remove dependency on `matches` crate
Move useless_transmute to nursery
nursery group -> style
Update for PR feedback
Auto merge of #5314 - ehuss:remove-git2, r=flip1995
Lint for `pub(crate)` items that are not crate visible due to the visibility of the module that contains them
````
Fixes#70456
Add GitHub Actions configuration
This PR adds the GitHub Actions configuration to the rust-lang/rust repository. The configuration will be run in parallel with Azure Pipelines until the evaluation finishes: the infrastructure team will then decide whether to switch.
Since GitHub Actions doesn't currently have any way to include pieces of configuration, this also adds the `src/tools/expand-yaml-anchors` tool, which serves as a sort of templating system. Otherwise the configuration is a mostly straight port from the Azure Pipelines configuration (thanks to all the PRs opened in the past).
There are still a few small things I need to fix before we can land this, but it's mostly complete and ready for an initial review.
r? @Mark-Simulacrum
Prepare for LLVM 10 upgrade
This is #67759 minus the submodule update.
* Fix two compatibility issues in the rustllvm wrapper.
* Update data layout strings in tests.
* Fix LLVM version comparison (this become a problem because the major version has two digits now).
r? @cuviper
`-C incremental` was introduced over two years ago. `-Z incremental` was
kept for transitioning, but it's been long enough now that it should be
ok to remove it.
submodules: update clippy from d8e6e4cf to 1ff81c1b
Changes:
````
rustup https://github.com/rust-lang/rust/pull/69968/
Fix documentation generation for configurable lints
Fix single binding in closure
Improvement: Don't show function body in needless_lifetimes
````
Fixes#70310
r? @Dylan-DPC
Changes:
````
rustup https://github.com/rust-lang/rust/pull/69968/
Fix documentation generation for configurable lints
Fix single binding in closure
Improvement: Don't show function body in needless_lifetimes
````
LLVM seems to at least sometimes optimize better when the length comes directly
from the `len()` of the array vs. an equivalent integer.
Also, this allows easier copy/pasting of the function into compiler explorer for
experimentation.
We find that it is common for large ranges of chars to be false -- and that
means that it is plausibly common for us to ask about a word that is entirely
empty. Therefore, we should make sure that we do not need to rotate bits or
otherwise perform some operation to map to the zero word; canonicalize it first
if possible.
Previously, all words in the (deduplicated) bitset would be stored raw -- a full
64 bits (8 bytes). Now, those words that are equivalent to others through a
specific mapping are stored separately and "mapped" to the original when
loading; this shrinks the table sizes significantly, as each mapped word is
stored in 2 bytes (a 4x decrease from the previous).
The new encoding is also potentially non-optimal: the "mapped" byte is
frequently repeated, as in practice many mapped words use the same base word.
Currently we only support two forms of mapping: rotation and inversion. Note
that these are both guaranteed to map transitively if at all, and supporting
mappings for which this is not true may require a more interesting algorithm for
choosing the optimal pairing.
Updated sizes:
Alphabetic : 2622 bytes (- 414 bytes)
Case_Ignorable : 1803 bytes (- 330 bytes)
Cased : 808 bytes (- 126 bytes)
Cc : 32 bytes
Grapheme_Extend: 1508 bytes (- 252 bytes)
Lowercase : 901 bytes (- 84 bytes)
N : 1064 bytes (- 156 bytes)
Uppercase : 838 bytes (- 96 bytes)
White_Space : 91 bytes (- 6 bytes)
Total table sizes: 9667 bytes (-1,464 bytes)
This avoids wasting a small amount of space for some of the data sets.
The chunk resizing is caused by but not directly related to changes in this
commit.
Alphabetic : 3036 bytes
Case_Ignorable : 2133 bytes (- 3 bytes)
Cased : 934 bytes
Cc : 32 bytes
Grapheme_Extend: 1760 bytes (-14 bytes)
Lowercase : 985 bytes
N : 1220 bytes (- 5 bytes)
Uppercase : 934 bytes
White_Space : 97 bytes
Total table sizes: 11131 bytes (-22 bytes)
Currently the test file takes a while to compile -- 30 seconds or so -- but
since it's not going to be committed, and is just for local testing, that seems
fine.
Try chunk sizes between 1 and 64, selecting the one which minimizes the number
of bytes used. 16, the previous constant, turned out to be a rather good choice,
with 5/9 of the datasets still using it.
Alphabetic : 3036 bytes (- 19 bytes)
Case_Ignorable : 2136 bytes
Cased : 934 bytes
Cc : 32 bytes (- 11 bytes)
Grapheme_Extend: 1774 bytes
Lowercase : 985 bytes
N : 1225 bytes (- 41 bytes)
Uppercase : 934 bytes
White_Space : 97 bytes (- 43 bytes)
Total table sizes: 11153 bytes (-114 bytes)
If the unicode-downloads folder already exists, we likely just fetched the data,
so don't make any further network requests. Unicode versions are released rarely
enough that this doesn't matter much in practice.
Extend search
I realized that when looking for "struct:String" in the rustdoc search for example, the "in arguments" and "returned" tabs were always empty. After some investigation, I realized it was because we only provided the name, and not the type, making it impossible to pass the "type filtering" check.
To resolve this, I added the type alongside the name. Note for the future: we could improve this by instead only registering the path id and use the path dictionary directly. The only problem with that solution (which I already tested) is that it becomes complicated for types in other crates. It'd force us to handle both case with an id and a case with `(name, type)`. I found the current PR big enough to not want to provide it directly. However, I think this is definitely worth it to make it work this way in the future.
About the two tests I added: they don't have much interest except checking that we actually have something returned in the search in the cases of a type filtering with and without literal search.
I also had to update a bit the test script to add the new locally global (haha) variable I created (`NO_TYPE_FILTER`). I added this variable to make the code easier to read than just "-1".
r? @kinnison
cc @ollie27
