bors [Tue, 8 Dec 2020 03:43:39 +0000 (03:43 +0000)]
Auto merge of #79820 - ehuss:update-cargo, r=ehuss
Update cargo
10 commits in 63d0fe43449adcb316d34d98a982b597faca4178..d274fcf862b89264fa2c6b917b15230705257317
2020-12-02 01:44:30 +0000 to 2020-12-07 23:08:44 +0000
- Clarify cargo manifest edition field docs (rust-lang/cargo#8953)
- Run rustdoc doctests relative to the workspace (rust-lang/cargo#8954)
- Workaround fs issue in `cargo publish`. (rust-lang/cargo#8950)
- Fix panic with -Zbuild-std and no roots. (rust-lang/cargo#8942)
- Slightly optimize `cargo vendor` (rust-lang/cargo#8937)
- Fixes rust-lang/cargo#8783 , cargo new fails without a author name or email (rust-lang/cargo#8912)
- Fix test escaping __CARGO_TEST_ROOT (rust-lang/cargo#8929)
- Add period to allowed feature name characters. (rust-lang/cargo#8932)
- faq: small fixes (rust-lang/cargo#8931)
- Fix semver documentation tests. (rust-lang/cargo#8930)
Rich Kadel [Tue, 8 Dec 2020 01:41:53 +0000 (17:41 -0800)]
Fixes to Rust coverage
Fixes: #79725
Some macros can create a situation where `fn_sig_span` and `body_span`
map to different files.
New documentation on coverage tests incorrectly assumed multiple test
binaries could just be listed at the end of the `llvm-cov` command,
but it turns out each binary needs a `--object` prefix.
This PR fixes the bug and updates the documentation to correct that
issue. It also fixes a few other minor issues in internal implementation
comments, and adds documentation on getting coverage results for doc
tests.
bors [Mon, 7 Dec 2020 22:47:20 +0000 (22:47 +0000)]
Auto merge of #79653 - tmiasko:naked-functions, r=Amanieu
Validate naked functions definitions
Validate that naked functions are defined in terms of a single inline assembly
block that uses only `const` and `sym` operands and has `noreturn` option.
Implemented as future incompatibility lint with intention to migrate it into
hard error. When it becomes a hard error it will ensure that naked functions are
either unsafe or contain an unsafe block around the inline assembly. It will
guarantee that naked functions do not reference functions parameters (obsoleting
part of existing checks from #79411). It will limit the definitions of naked
functions to what can be reliably supported. It will also reject naked functions
implemented using legacy LLVM style assembly since it cannot satisfy those
conditions.
bors [Mon, 7 Dec 2020 17:35:02 +0000 (17:35 +0000)]
Auto merge of #79751 - aDotInTheVoid:json-true-idx, r=jyn514
Rustdoc: Use correct def_id for doctree::Import
The default overwrites the crate root, which crashes rustdoc-json.
While investigating this, It turns out somehow, some items are being documented twice. I'm not sure how this is happening but for now, we just make sure they were the same if they have the same id.
Aman Arora [Thu, 19 Nov 2020 03:54:31 +0000 (22:54 -0500)]
Move handling UpvarRef to PlaceBuilder
- This allows us to delay figuring out the index of a capture
in the closure structure when all projections to atleast form
a capture have been applied to the builder
bors [Sun, 6 Dec 2020 08:08:05 +0000 (08:08 +0000)]
Auto merge of #79734 - ethanboxx:inferred_const_note, r=varkor
Const parameters can not be inferred with `_` help note
This should close: #79557
# Example output
```
error[E0747]: type provided when a constant was expected
--> inferred_const_note.rs:6:19
|
6 | let a = foo::<_, 2>([0, 1, 2]);
| ^
|
= help: Const parameters can not be inferred with `_`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0747`.
```
bors [Sun, 6 Dec 2020 07:18:33 +0000 (07:18 +0000)]
Auto merge of #6421 - xFrednet:4176-unreadable-literal-lint-fractal-option, r=Manishearth
Added a lint-fraction-readability flag to the configuration
This adds an option to disable the `unreadable_literal` lint for floats with a longer fraction. This allows users to write `0.100200300` without getting a warning. Fixes #4176
I have some open questions about this PR:
1. I've named the option `lint-fraction-readability` is this a good name or should I rename it to something else?
2. What should the default configuration value be?
* The current default value is `true` as this was also the previous default.
3. Do I have to document this new option somewhere else or will it be extracted from the code comment?
4. The current fix option will also rewrite the fraction if the integer part violates the `unreadable_literal` lint it would otherwise also trigger the `inconsistent_digit_grouping` lint. Is this also okay?
* `1.100200300` will be unaffected by the fix function
* `100200300.100200300` will be effected and fixed to `100_200_300.100_200_300`
---
The project needed some getting used to but I'm happy with the result. A big thank you to `@flip1995` for giving me some pointers for this implementation and to everyone for the great introduction documentation!
---
changelog: Added the `unreadable-literal-lint-fractions` configuration to disable the `unreadable_literal` lint for fractions
bors [Sun, 6 Dec 2020 01:15:37 +0000 (01:15 +0000)]
Auto merge of #79650 - the8472:fix-take, r=dtolnay
Fix incorrect io::Take's limit resulting from io::copy specialization
The specialization introduced in #75272 fails to update `io::Take` wrappers after performing the copy syscalls which bypass those wrappers. The buffer flushing before the copy does update them correctly, but the bytes copied after the initial flush weren't subtracted.
The fix is to subtract the bytes copied from each `Take` in the chain of wrappers, even when an error occurs during the syscall loop. To do so the `CopyResult` enum now has to carry the bytes copied so far in the error case.
Tomasz Miąsko [Sun, 6 Dec 2020 00:00:00 +0000 (00:00 +0000)]
Compress RWU from at least 32 bits to 4 bits
The liveness uses a mixed representation of RWUs based on the
observation that most of them have invalid reader and invalid
writer. The packed variant uses 32 bits and unpacked 96 bits.
Unpacked data contains reader live node and writer live node.
Since live nodes are used only to determine their validity,
RWUs can always be stored in a packed form with four bits for
each: reader bit, writer bit, used bit, and one extra padding
bit to simplify packing and unpacking operations.
bors [Sat, 5 Dec 2020 20:30:58 +0000 (20:30 +0000)]
Auto merge of #79685 - sivadeilra:fix_env_vars_win, r=davidtwco
Fix src/test/ui/env-vars.rs on 128-core machines on Windows
On Windows, the environment variable NUMBER_OF_PROCESSORS has special
meaning. Unfortunately, you can get different answers, depending on
whether you are enumerating all environment variables or querying a
specific variable. This was causing the src/test/ui/env-vars.rs test
to fail on machines with more than 64 processors when run on Windows.
bors [Sat, 5 Dec 2020 15:58:06 +0000 (15:58 +0000)]
Auto merge of #79445 - SNCPlay42:struct-tail-recursion-limit, r=oli-obk
check the recursion limit when finding a struct's tail
fixes #79437
This does a `delay_span_bug` (via `ty_error_with_message`) rather than emit a new error message, under the assumption that there will be an error elsewhere (even if the type isn't infinitely recursive, just deeper than the recursion limit, this appears to be the case).
Aaron Hill [Fri, 4 Dec 2020 23:37:21 +0000 (18:37 -0500)]
Properly re-use def path hash in incremental mode
Fixes #79661
In incremental compilation mode, we update a `DefPathHash -> DefId`
mapping every time we create a `DepNode` for a foreign `DefId`.
This mapping is written out to the on-disk incremental cache, and is
read by the next compilation session to allow us to lazily decode
`DefId`s.
When we decode a `DepNode` from the current incremental cache, we need
to ensure that any previously-recorded `DefPathHash -> DefId` mapping
gets recorded in the new mapping that we write out. However, PR #74967
didn't do this in all cases, leading to us being unable to decode a
`DefPathHash` in certain circumstances.
This PR refactors some of the code around `DepNode` deserialization to
prevent this kind of mistake from happening again.
bors [Fri, 4 Dec 2020 22:30:19 +0000 (22:30 +0000)]
Auto merge of #79673 - ijackson:intoinnerintoinnererror, r=m-ou-se
Provide IntoInnerError::into_parts
Hi. This is an updated version of the IntoInnerError bits of my previous portmanteau MR #78689. Thanks to `@jyn514` and `@m-ou-se` for helpful comments there.
I have made this insta-stable since it seems like it will probably be uncontroversial, but that is definitely something that someone from the libs API team should be aware of and explicitly consider.
I included a tangentially-related commit providing documentation of the buffer full behaviiour of `&mut [u8] as Write`; the behaviour I am documenting is relied on by the doctest for `into_parts`.
bors [Fri, 4 Dec 2020 20:07:04 +0000 (20:07 +0000)]
Auto merge of #79286 - TimDiekmann:rename-allocref, r=Lokathor,Wodann,m-ou-se
Rename `AllocRef` to `Allocator` and `(de)alloc` to `(de)allocate`
Calling `Box::alloc_ref` and `Vec::alloc_ref` sounds like allocating a reference. To solve this ambiguity, this renames `AllocRef` to `Allocator` and `alloc` to `allocate`. For a more detailed explaination see https://github.com/rust-lang/wg-allocators/issues/76.
Ian Jackson [Mon, 2 Nov 2020 20:58:12 +0000 (20:58 +0000)]
IntoInnerError: Provide into_parts
In particular, IntoIneerError only currently provides .error() which
returns a reference, not an owned value. This is not helpful and
means that a caller of BufWriter::into_inner cannot acquire an owned
io::Error which seems quite wrong.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
bors [Fri, 4 Dec 2020 11:21:35 +0000 (11:21 +0000)]
Auto merge of #79680 - Nadrieril:fix-regression-79284, r=jonas-schievink
Fix perf regression caused by #79284
https://github.com/rust-lang/rust/pull/79284 only moved code around but this changed inlining and caused a large perf regression. This fixes it for me, though I'm less confident than usual because the regression was not observable with my usual (i.e. incremental) compilation settings.