Jonas Schievink [Wed, 11 Nov 2020 19:59:00 +0000 (20:59 +0100)]
Rollup merge of #78417 - ssomers:btree_chop_up_2, r=Mark-Simulacrum
BTreeMap: split off most code of append
To complete #78056, move the last single-purpose pieces of code out of map.rs into a separate module. Also, tweaked documentation and safeness - I doubt think this code would be safe if the iterators passed in wouldn't be as sorted as the method says they should be - and bounds on MergeIterInner.
Jonas Schievink [Wed, 11 Nov 2020 19:58:56 +0000 (20:58 +0100)]
Rollup merge of #78354 - 12101111:rustbuild_profiler, r=Mark-Simulacrum
Support enable/disable sanitizers/profiler per target
This PR add options under `[target.*]` of `config.toml` which can enable or disable sanitizers/profiler runtime for corresponding target.
If these options are empty, the global options under `[build]` will take effect.
Jonas Schievink [Wed, 11 Nov 2020 19:58:52 +0000 (20:58 +0100)]
Rollup merge of #78216 - workingjubilee:duration-zero, r=m-ou-se
Duration::zero() -> Duration::ZERO
In review for #72790, whether or not a constant or a function should be favored for `#![feature(duration_zero)]` was seen as an open question. In https://github.com/rust-lang/rust/issues/73544#issuecomment-691701670 an invitation was opened to either stabilize the methods or propose a switch to the constant value, supplemented with reasoning. Followup comments suggested community preference leans towards the const ZERO, which would be reason enough.
ZERO also "makes sense" beside existing associated consts for Duration. It is ever so slightly awkward to have a series of constants specifying 1 of various units but leave 0 as a method, especially when they are side-by-side in code. It seems unintuitive for the one non-dynamic value (that isn't from Default) to be not-a-const, which could hurt discoverability of the associated constants overall. Elsewhere in `std`, methods for obtaining a constant value were even deprecated, as seen with [std::u32::min_value](https://doc.rust-lang.org/std/primitive.u32.html#method.min_value).
Most importantly, ZERO costs less to use. A match supports a const pattern, but const fn can only be used if evaluated through a const context such as an inline `const { const_fn() }` or a `const NAME: T = const_fn()` declaration elsewhere. Likewise, while https://github.com/rust-lang/rust/issues/73544#issuecomment-691949373 notes `Duration::zero()` can optimize to a constant value, "can" is not "will". Only const contexts have a strong promise of such. Even without that in mind, the comment in question still leans in favor of the constant for simplicity. As it costs less for a developer to use, may cost less to optimize, and seems to have more of a community consensus for it, the associated const seems best.
bors [Wed, 11 Nov 2020 16:24:43 +0000 (16:24 +0000)]
Auto merge of #78790 - Gankra:rust-src-vendor, r=Mark-Simulacrum
Vendor libtest's dependencies in the rust-src component
This is the Rust side of https://github.com/rust-lang/wg-cargo-std-aware/issues/23
Note that this won't produce a useful result for `cargo -Zbuild-std` if there are multiple versions of a crate vendored, but will otherwise produce a valid vendor dir.
See https://github.com/rust-lang/cargo/pull/8834 for the other half of this change.
Nicholas-Baron [Fri, 6 Nov 2020 21:24:55 +0000 (13:24 -0800)]
Changed unwrap_or to unwrap_or_else in some places.
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.
A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.
The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
bors [Wed, 11 Nov 2020 01:18:18 +0000 (01:18 +0000)]
Auto merge of #78920 - jonas-schievink:rollup-w2mjsuh, r=jonas-schievink
Rollup of 14 pull requests
Successful merges:
- #76765 (Make it more clear what an about async fn's returns when referring to what it returns)
- #78574 (Use check-pass instead of build-pass in regions ui test suite)
- #78669 (Use check-pass instead of build-pass in some consts ui test suits)
- #78847 (Assert that a return place is not used for indexing during integration)
- #78854 (Workaround for "could not fully normalize" ICE )
- #78875 (rustc_target: Further cleanup use of target options)
- #78887 (Add comments to explain memory usage optimization)
- #78890 (comment attribution fix)
- #78896 (Clarified description of write! macro)
- #78897 (Add missing newline to error message of the default OOM hook)
- #78898 (add regression test for #78892)
- #78908 ((rustdoc) [src] link for types defined by macros shows invocation, not defintion)
- #78910 (Fix links to stabilized versions of some intrinsics)
- #78912 (Add macro test for min-const-generics)
Jonas Schievink [Tue, 10 Nov 2020 13:45:32 +0000 (14:45 +0100)]
Rollup merge of #78908 - liketechnik:fix_macro_expand_src_link, r=jyn514
(rustdoc) [src] link for types defined by macros shows invocation, not defintion
Previously the [src] link on types defined by a macro pointed to the macro definition.
This pr makes the Clean-Implementation for Spans aware of macro defined types, so that the link points to the invocation instead.
I'm not totally sure if it's okay to add the 'macro awareness' in the Clean-Implementation, because it erases that knowledge for all following code. Maybe it would be more sensible to add the check only for the link generation at https://github.com/rust-lang/rust/blob/25f6938da459a57b43bdf16ed6bdad3225b2a3ce/src/librustdoc/html/render/mod.rs#L1619
Jonas Schievink [Tue, 10 Nov 2020 13:45:28 +0000 (14:45 +0100)]
Rollup merge of #78897 - hyd-dev:alloc-error-hook-newline, r=m-ou-se
Add missing newline to error message of the default OOM hook
Currently the default OOM hook in libstd does not end the error message with a newline:
```
memory allocation of 4 bytes failedtimeout: the monitored command dumped core
/playground/tools/entrypoint.sh: line 11: 7 Aborted timeout --signal=KILL ${timeout} "$`@"`
```
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=030d8223eb57dfe47ef157709aa26542
This is because the `fmt::Arguments` passed to `dumb_print()` does not end with a newline. All other calls to `dumb_print()` in libstd pass a `\n`-ended `fmt::Arguments` to `dumb_print()`. For example:
https://github.com/rust-lang/rust/blob/25f6938da459a57b43bdf16ed6bdad3225b2a3ce/library/std/src/sys_common/util.rs#L18
I think the `\n` was forgotten in #51264.
This PR appends `\n` to the error string.
~~Note that I didn't add a test, because I didn't find tests for functions in ` library/std/src/alloc.rs` or a test that is similar to the test of this change would be.~~ *Edit: CI told me there is an existing test. Sorry.*
Jonas Schievink [Tue, 10 Nov 2020 13:45:17 +0000 (14:45 +0100)]
Rollup merge of #78847 - tmiasko:inline-return-place, r=matthewjasper
Assert that a return place is not used for indexing during integration
The inliner integrates call destination place with callee return place
by remapping the local and adding extra projections as necessary.
If a call destination place contains any projections (which is already
possible) and a return place is used in an indexing projection (most
likely doesn't happen yet) the end result would be incorrect.
Add an assertion to ensure that potential issue won't go unnoticed in
the presence of more sophisticated copy propagation scheme.
Jonas Schievink [Tue, 10 Nov 2020 13:45:15 +0000 (14:45 +0100)]
Rollup merge of #78669 - sasurau4:test/check-pass-consts, r=jyn514
Use check-pass instead of build-pass in some consts ui test suits
Helps with #62277
Changed tests modified by https://github.com/rust-lang/rust/pull/57175 because of the stabilization `#![feature(const_let)]`.
They should be compile-fail because the feature gate checking disallow the feature before stabilization. So the feature gate checking have nothing to do with codegen according to https://rustc-dev-guide.rust-lang.org/feature-gate-ck.html.
Jonas Schievink [Tue, 10 Nov 2020 13:45:13 +0000 (14:45 +0100)]
Rollup merge of #78574 - sasurau4:test/check-pass-regions, r=jyn514
Use check-pass instead of build-pass in regions ui test suite
## Overview
Helps with #62277
Region inference have nothing to do with codegen because they are erased before codegen.
Ref: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Is.20region.20inference.20.20nothing.20to.20do.20with.20codegen.20process.3F/near/215956759
Jonas Schievink [Tue, 10 Nov 2020 13:45:09 +0000 (14:45 +0100)]
Rollup merge of #76765 - guswynn:async_return, r=tmandry
Make it more clear what an about async fn's returns when referring to what it returns
see #76547
This is *likely* not the ONLY place that this happens to be unclear, but we can move this fn to rustc_middle or something like that and reuse it if need be, to apply it to more diagnostics
One outstanding question I have is, if the fn returns (), should I make the message more clear (what about `fn f()` vs `fn f() -> ()`, can you tell those apart in the hir?)
bors [Tue, 10 Nov 2020 10:43:14 +0000 (10:43 +0000)]
Auto merge of #78904 - Dylan-DPC:rollup-8d2w3vu, r=Dylan-DPC
Rollup of 12 pull requests
Successful merges:
- #74754 (Add `#[cfg(panic = '...')]`)
- #76468 (Improve lifetime name annotations for closures & async functions)
- #77016 (Test clippy on PR CI on changes)
- #78480 (BTreeMap: fix pointer provenance rules)
- #78502 (Update Chalk to 0.36.0)
- #78513 (Infer the default host target from the host toolchain if possible)
- #78566 (Enable LLVM Polly via llvm-args.)
- #78580 (inliner: Break inlining cycles)
- #78710 (rustc_ast: Do not panic by default when visiting macro calls)
- #78746 (Demote i686-unknown-freebsd to tier 2 compiler target)
- #78830 (fix `super_visit_with` for `Terminator`)
- #78844 (Monomorphize a type argument of size-of operation during codegen)
(rustdoc) [src] link for types defined by macros shows invocation
Previously the [src] link on types defined by a macro
pointed to the macro definition.
This commit makes the Clean-Implementation for Spans
aware of macro defined types,
so that the link points to the invocation instead.
Dylan DPC [Mon, 9 Nov 2020 18:07:02 +0000 (19:07 +0100)]
Rollup merge of #78844 - tmiasko:monomorphize-sizeof, r=oli-obk
Monomorphize a type argument of size-of operation during codegen
This wasn't necessary until MIR inliner started to consider drop glue as
a candidate for inlining; introducing for the first time a generic use
of size-of operation.
No test at this point since this only happens with a custom inlining
threshold.
Dylan DPC [Mon, 9 Nov 2020 18:06:57 +0000 (19:06 +0100)]
Rollup merge of #78746 - pietroalbini:i686-freebsd, r=Mark-Simulacrum
Demote i686-unknown-freebsd to tier 2 compiler target
While technically the `i686-unknown-freebsd` target has been a tier 2 development platform for a long time, with full toolchain tarballs available on static.rust-lang.org, due to a bug in the manifest generation the target was never available for download through rustup.
The infrastructure team privately inquired the FreeBSD package maintainers, and they weren't relying on those tarballs either, so it's a fair assumption to say practically nobody is using those tarballs.
This PR then removes the CI builder that produces full tarballs for the target, and moves the compilation of `rust-std` for the target in `dist-various-2`. The `x86_64-unknown-freebsd` target is *not* affected.
cc `@rust-lang/infra` `@rust-lang/compiler` `@rust-lang/release`
r? `@Mark-Simulacrum`
Dylan DPC [Mon, 9 Nov 2020 18:06:55 +0000 (19:06 +0100)]
Rollup merge of #78710 - petrochenkov:macvisit, r=davidtwco
rustc_ast: Do not panic by default when visiting macro calls
Panicking by default made sense when we didn't have HIR or MIR and everything worked on AST, but now all AST visitors run early and majority of them have to deal with macro calls, often by ignoring them.
The second commit renames `visit_mac` to `visit_mac_call`, the corresponding structures were renamed earlier in https://github.com/rust-lang/rust/pull/69589.
Dylan DPC [Mon, 9 Nov 2020 18:06:53 +0000 (19:06 +0100)]
Rollup merge of #78580 - tmiasko:inline-loop, r=oli-obk
inliner: Break inlining cycles
Keep track of all instances inlined so far. When examining a new call
sites from an inlined body, skip those where callee had been inlined
already to avoid potential inlining cycles.
Dylan DPC [Mon, 9 Nov 2020 18:06:51 +0000 (19:06 +0100)]
Rollup merge of #78566 - JRF63:polly, r=Mark-Simulacrum
Enable LLVM Polly via llvm-args.
I think doing it this way is better than in #51061. Polly has other useful options and we probably don't want to create a `-Z` flag for each one of them.
I noticed that `-lto` seems to interfere with polly in this specific microbenchmark, as enabling it causes the perf to drop to that of non-polly builds.
Dylan DPC [Mon, 9 Nov 2020 18:06:49 +0000 (19:06 +0100)]
Rollup merge of #78513 - jyn514:rustup-toolchain, r=Mark-Simulacrum
Infer the default host target from the host toolchain if possible
- `beta-x86_64-unknown-linux-gnu` has beta stripped
- `rustc2` is ignored
This fixes ongoing issues where x.py will detect the wrong host triple
between MSVC and GNU.
I don't think this will break anyone's workflow - I'd be very surprised if you a) had no `[build]` section in `config.toml`, b) had rustc installed, and c) expected the default target to be something other than the default target used by `rustc`. But I could be wrong - I'm happy to hear user stories :)
Dylan DPC [Mon, 9 Nov 2020 18:06:42 +0000 (19:06 +0100)]
Rollup merge of #77016 - Mark-Simulacrum:clippy-tests, r=pietroalbini
Test clippy on PR CI on changes
This runs the tools builder (which builds and tests tools, including clippy) when the clippy submodule changes. This essentially returns us to the prior state when clippy was a submodule; it makes sense for us to test it on CI when it changes. It might make sense for it to be tested regardless of changing but it is somewhat rare for it to fail and we don't want to add to CI time for the majority of PRs which don't affect it.
Dylan DPC [Mon, 9 Nov 2020 18:06:39 +0000 (19:06 +0100)]
Rollup merge of #76468 - SNCPlay42:lifetime-names, r=Mark-Simulacrum
Improve lifetime name annotations for closures & async functions
* Don't refer to async functions as "generators" in error output
* Where possible, emit annotations pointing exactly at the `&` in the return type of closures (when they have explicit return types) and async functions, like we do for arguments.
Addresses #74072, but I wouldn't call that *closed* until annotations are identical for async and non-async functions.
* Emit a better annotation when the lifetime doesn't appear in the full name type, which currently happens for opaque types like `impl Future`. Addresses #74497, but further improves could probably be made (why *doesn't* it appear in the type as `impl Future + '1`?)
This is included in the same PR because the changes to `give_name_if_anonymous_region_appears_in_output` would introduce ICE otherwise (it would return `None` in cases where it didn't previously, which then gets `unwrap`ped)
Dylan DPC [Mon, 9 Nov 2020 18:06:37 +0000 (19:06 +0100)]
Rollup merge of #74754 - davidhewitt:cfg-panic, r=ecstatic-morse
Add `#[cfg(panic = '...')]`
This PR adds conditional compilation according to the panic strategy.
I've come across a need for a flag like this a couple of times while writing tests: #74301 , https://github.com/rust-lang/rust/pull/73670#issuecomment-653629031
I'm not sure if I need to add a feature gate for this flag?
bors [Mon, 9 Nov 2020 11:08:07 +0000 (11:08 +0000)]
Auto merge of #78201 - joshtriplett:rustc-tls-model, r=Mark-Simulacrum
Compile rustc crates with the initial-exec TLS model
This should produce more efficient code, with fewer calls to
__tls_get_addr. The tradeoff is that libraries using it won't work with
dlopen, but that shouldn't be a problem for rustc's internal libraries.
bors [Mon, 9 Nov 2020 00:36:58 +0000 (00:36 +0000)]
Auto merge of #78889 - Dylan-DPC:rollup-6zjhahf, r=Dylan-DPC
Rollup of 12 pull requests
Successful merges:
- #77640 (Refactor IntErrorKind to avoid "underflow" terminology)
- #78026 (Define `fs::hard_link` to not follow symlinks.)
- #78114 (Recognize `private_intra_doc_links` as a lint)
- #78228 (Promote aarch64-unknown-linux-gnu to Tier 1)
- #78345 (Fix handling of item names for HIR)
- #78437 (BTreeMap: stop mistaking node for an orderly place)
- #78476 (fix some incorrect aliasing in the BTree)
- #78674 (inliner: Use substs_for_mir_body)
- #78748 (Implement destructuring assignment for tuples)
- #78868 (Fix tab focus on restyled switches)
- #78878 (Avoid overlapping cfg attributes when both macOS and aarch64)
- #78882 (Nicer hunk headers for rust files)
Dylan DPC [Mon, 9 Nov 2020 00:13:44 +0000 (01:13 +0100)]
Rollup merge of #78748 - fanzier:tuple-assignment, r=petrochenkov
Implement destructuring assignment for tuples
This is the first step towards implementing destructuring assignment (RFC: https://github.com/rust-lang/rfcs/pull/2909, tracking issue: #71126). This PR is the first part of #71156, which was split up to allow for easier review.
Quick summary: This change allows destructuring the LHS of an assignment if it's a (possibly nested) tuple.
It is implemented via a desugaring (AST -> HIR lowering) as follows:
```rust
(a,b) = (1,2)
```
... becomes ...
```rust
{
let (lhs0,lhs1) = (1,2);
a = lhs0;
b = lhs1;
}
```
Thanks to `@varkor` who helped with the implementation, particularly around default binding modes.
Dylan DPC [Mon, 9 Nov 2020 00:13:42 +0000 (01:13 +0100)]
Rollup merge of #78674 - tmiasko:inline-substs-for-mir-body, r=oli-obk
inliner: Use substs_for_mir_body
Changes from 68965 extended the kind of instances that are being
inlined. For some of those, the `instance_mir` returns a MIR body that
is already expressed in terms of the types found in substitution array,
and doesn't need further substitution.
Use `substs_for_mir_body` to take that into account.
Dylan DPC [Mon, 9 Nov 2020 00:13:40 +0000 (01:13 +0100)]
Rollup merge of #78476 - RalfJung:btree-alias, r=Mark-Simulacrum
fix some incorrect aliasing in the BTree
This line is wrong:
```
ptr::copy(slice.as_ptr().add(idx), slice.as_mut_ptr().add(idx + 1), slice.len() - idx);
```
When `slice.as_mut_ptr()` is called, that creates a mutable reference to the entire slice, which invalidates the raw pointer previously returned by `slice.as_ptr()`. (Miri currently misses this because raw pointers are not tracked properly.)
Dylan DPC [Mon, 9 Nov 2020 00:13:38 +0000 (01:13 +0100)]
Rollup merge of #78437 - ssomers:btree_no_ord_at_node_level, r=Mark-Simulacrum
BTreeMap: stop mistaking node for an orderly place
A second mistake in #77612 was to ignore the node module's rightful comment "this module doesn't care whether the entries are sorted". And there's a much simpler way to visit the keys in order, if you check this separately from a single pass checking everything.
Dylan DPC [Mon, 9 Nov 2020 00:13:35 +0000 (01:13 +0100)]
Rollup merge of #78345 - jyn514:proper-names, r=varkor
Fix handling of item names for HIR
- Handle variants, fields, macros in `Node::ident()`
- Handle the crate root in `opt_item_name`
- Rewrite `item_name` in terms of `opt_item_name`
I need this for both https://github.com/rust-lang/rust/pull/77820 and https://github.com/rust-lang/rust/pull/78082, so splitting it out into a separate PR so it can land early.
Dylan DPC [Mon, 9 Nov 2020 00:13:33 +0000 (01:13 +0100)]
Rollup merge of #78228 - pietroalbini:finally, r=Mark-Simulacrum
Promote aarch64-unknown-linux-gnu to Tier 1
This PR promotes the `aarch64-unknown-linux-gnu` target to Tier 1, as proposed by [RFC 2959]:
* The `aarch64-gnu` CI job is moved from `auto-fallible` to `auto`.
* The platform support documentation is updated, uplifting the target to Tiert 1 with a note about missing stack probes support.
* Building the documentation is enabled for the target, as we produce the `rust-docs` component for all Tier 1 platforms.
Dylan DPC [Mon, 9 Nov 2020 00:13:31 +0000 (01:13 +0100)]
Rollup merge of #78114 - jyn514:private, r=oli-obk
Recognize `private_intra_doc_links` as a lint
Previously, trying to allow this would give another error!
```
warning: unknown lint: `private_intra_doc_links`
--> private.rs:1:10
|
1 | #![allow(private_intra_doc_links)]
| ^^^^^^^^^^^^^^^^^^^^^^^ help: did you mean: `broken_intra_doc_links`
|
= note: `#[warn(unknown_lints)]` on by default
warning: public documentation for `DocMe` links to private item `DontDocMe`
--> private.rs:2:11
|
2 | /// docs [DontDocMe]
| ^^^^^^^^^ this item is private
|
= note: `#[warn(private_intra_doc_links)]` on by default
= note: this link will resolve properly if you pass `--document-private-items`
```
Fixes the issue found in https://github.com/rust-lang/rust/pull/77249#issuecomment-712339227.
r? ````````@Manishearth````````
Does anyone know why this additional step is necessary? It seems weird this has to be declared in 3 different places.
Dylan DPC [Mon, 9 Nov 2020 00:13:28 +0000 (01:13 +0100)]
Rollup merge of #78026 - sunfishcode:symlink-hard-link, r=dtolnay
Define `fs::hard_link` to not follow symlinks.
POSIX leaves it [implementation-defined] whether `link` follows symlinks.
In practice, for example, on Linux it does not and on FreeBSD it does.
So, switch to `linkat`, so that we can pick a behavior rather than
depending on OS defaults.
Pick the option to not follow symlinks. This is somewhat arbitrary, but
seems the less surprising choice because hard linking is a very
low-level feature which requires the source and destination to be on
the same mounted filesystem, and following a symbolic link could end
up in a different mounted filesystem.
Dylan DPC [Mon, 9 Nov 2020 00:13:25 +0000 (01:13 +0100)]
Rollup merge of #77640 - ethanboxx:int_error_matching_attempt_2, r=KodrAus
Refactor IntErrorKind to avoid "underflow" terminology
This PR is a continuation of #76455
# Changes
- `Overflow` renamed to `PosOverflow` and `Underflow` renamed to `NegOverflow` after discussion in #76455
- Changed some of the parsing code to return `InvalidDigit` rather than `Empty` for strings "+" and "-". https://users.rust-lang.org/t/misleading-error-in-str-parse-for-int-types/49178
- Carry the problem `char` with the `InvalidDigit` variant.
- Necessary changes were made to the compiler as it depends on `int_error_matching`.
- Redid tests to match on specific errors.
Tomasz Miąsko [Mon, 9 Nov 2020 00:00:00 +0000 (00:00 +0000)]
inliner: Break inlining cycles
When examining candidates for inlining, reject those that are determined
to be recursive either because of self-recursive calls or calls to any
instances already inlined.
bors [Sun, 8 Nov 2020 20:00:51 +0000 (20:00 +0000)]
Auto merge of #78712 - petrochenkov:visitok, r=Aaron1011
rustc_ast: Visit tokens stored in AST nodes in mutable visitor
After #77271 token visiting is enabled only for one visitor in `rustc_expand\src\mbe\transcribe.rs` which applies hygiene marks to tokens produced by declarative macros (`macro_rules` or `macro`), so this change doesn't affect anything else.
When a macro has some interpolated token from an outer macro in its output
```rust
macro inner() {
$interpolated
}
```
we can use the usual interpretation of interpolated tokens in token-based model - a None-delimited group - to write this macro in an equivalent form
```rust
macro inner() {
⟪ a b c d ⟫
}
```
When we are expanding the macro `inner` we need to apply hygiene marks to all tokens produced by it, including the tokens inside the group.
Before this PR we did this by visiting the AST piece inside the interpolated token and applying marks to all spans in it.
I'm not sure this is 100% correct (ideally we should apply the marks to tokens and then re-parse the AST from tokens), but it's a very good approximation at least.
We didn't however apply the marks to actual tokens stored in the nonterminal, so if we used the nonterminal as a token rather than as an AST piece (e.g. passed it to a proc macro), then we got hygiene bugs.
This PR applies the marks to tokens in addition to the AST pieces thus fixing the issue.
Collapse all uses of `target.options.foo` into `target.foo`
with an eye on merging `TargetOptions` into `Target`.
`TargetOptions` as a separate structure is mostly an implementation detail of `Target` construction, all its fields logically belong to `Target` and available from `Target` through `Deref` impls.
bors [Sun, 8 Nov 2020 13:49:17 +0000 (13:49 +0000)]
Auto merge of #78874 - m-ou-se:rollup-3jp1ijj, r=m-ou-se
Rollup of 19 pull requests
Successful merges:
- #76097 (Stabilize hint::spin_loop)
- #76227 (Stabilize `Poll::is_ready` and `is_pending` as const)
- #78065 (make concurrency helper more pleasant to read)
- #78570 (Remove FIXME comment in print_type_sizes ui test suite)
- #78572 (Use SOCK_CLOEXEC and accept4() on more platforms.)
- #78658 (Add a tool to run `x.py` from any subdirectory)
- #78706 (Fix run-make tests running when LLVM is disabled)
- #78728 (Constantify `UnsafeCell::into_inner` and related)
- #78775 (Bump Rustfmt and RLS)
- #78788 (Correct unsigned equivalent of isize to be usize)
- #78811 (Make some std::io functions `const`)
- #78828 (use single char patterns for split() (clippy::single_char_pattern))
- #78841 (Small cleanup in `TypeFoldable` derive macro)
- #78842 (Honor the rustfmt setting in config.toml)
- #78843 (Less verbose debug logging from inlining integrator)
- #78852 (Convert a bunch of intra-doc links)
- #78860 (rustc_resolve: Use `#![feature(format_args_capture)]`)
- #78861 (typo and formatting)
- #78865 (Don't fire `CONST_ITEM_MUTATION` lint when borrowing a deref)
Mara Bos [Sun, 8 Nov 2020 12:36:33 +0000 (13:36 +0100)]
Rollup merge of #78865 - Aaron1011:fix/const-item-mut-reborrow, r=varkor
Don't fire `CONST_ITEM_MUTATION` lint when borrowing a deref
Fixes #78819
This extends the check for dereferences added in PR #77324
to cover mutable borrows, as well as direct writes. If we're operating
on a dereference of a `const` item, we shouldn't be firing the lint.
Mara Bos [Sun, 8 Nov 2020 12:36:26 +0000 (13:36 +0100)]
Rollup merge of #78843 - tmiasko:inline-trace, r=wesleywiser
Less verbose debug logging from inlining integrator
The inlining integrator produces relatively verbose and uninteresting
logs. Move them from a debug log level to a trace level, so that they
can be easily isolated from others.
Mara Bos [Sun, 8 Nov 2020 12:36:25 +0000 (13:36 +0100)]
Rollup merge of #78842 - shepmaster:bootstrap-rustfmt, r=Mark-Simulacrum
Honor the rustfmt setting in config.toml
Prior to this, setting the rustfmt configuration was ignored:
```
% mkdir example
% cd example
% ../configure --set build.rustfmt=/usr/bin/true
% ../x.py fmt
./x.py fmt is not supported on this channel
failed to run: /Users/shep/Projects/rust/example/build/bootstrap/debug/bootstrap fmt
Build completed unsuccessfully in 0:00:01
```
And after:
```
% ../x.py fmt
Build completed successfully in 0:00:11
```
Mara Bos [Sun, 8 Nov 2020 12:36:18 +0000 (13:36 +0100)]
Rollup merge of #78788 - jhpratt:isize-impl-fix, r=m-ou-se
Correct unsigned equivalent of isize to be usize
See [#74913 (comment)](https://github.com/rust-lang/rust/issues/74913#issuecomment-722334456) for why this matters. Apparently it hasn't been used anywhere else, though CI will tell for sure.
Mara Bos [Sun, 8 Nov 2020 12:36:12 +0000 (13:36 +0100)]
Rollup merge of #78706 - bjorn3:fix_run_make_without_llvm, r=Mark-Simulacrum
Fix run-make tests running when LLVM is disabled
The `--cc`, `--cxx`, `--cflags` and `--ar` flags were only passed to compiletest when `builder.config.llvm_enabled()` returned true. This is preventing me from running the tests on cg_clif.
Mara Bos [Sun, 8 Nov 2020 12:36:09 +0000 (13:36 +0100)]
Rollup merge of #78658 - casey:x, r=Mark-Simulacrum
Add a tool to run `x.py` from any subdirectory
This adds a binary called `x` in `src/tools/x`. All it does is check the current directory and its ancestors for a file called `x.py`, and if it finds one, runs it.
By installing x, you can easily run `x.py` from any subdirectory, and only need to type `x`.
It can be installed with `cargo install --path src/tools/x`
This is a copy of a [binary I've been using myself when working on rust](https://github.com/casey/bootstrap), currently published to crates.io as `bootstrap`.
It could be changed to avoid indirecting through `x.py`, and instead call the bootstrap module directly. However, this seemed like the simplest thing possible, and won't break if the details of how the bootstrap module is invoked change.
Mara Bos [Sun, 8 Nov 2020 12:36:07 +0000 (13:36 +0100)]
Rollup merge of #78572 - de-vri-es:bsd-cloexec, r=m-ou-se
Use SOCK_CLOEXEC and accept4() on more platforms.
This PR enables the use of `SOCK_CLOEXEC` and `accept4` on more platforms.
-----
Android uses the linux kernel, so it should also support it.
DragonflyBSD introduced them in 4.4 (December 2015):
https://www.dragonflybsd.org/release44/
FreeBSD introduced them in 10.0 (January 2014):
https://wiki.freebsd.org/AtomicCloseOnExec
Illumos introduced them in a commit in April 2013, not sure when it was released. It is quite possible that is has always been in Illumos:
https://github.com/illumos/illumos-gate/commit/5dbfd19ad5fcc2b779f40f80fa05c1bd28fd0b4e
https://illumos.org/man/3socket/socket
https://illumos.org/man/3socket/accept4
NetBSD introduced them in 6.0 (Oktober 2012) and 8.0 (July 2018):
https://man.netbsd.org/NetBSD-6.0/socket.2
https://man.netbsd.org/NetBSD-8.0/accept.2
OpenBSD introduced them in 5.7 (May 2015):
https://man.openbsd.org/socket https://man.openbsd.org/accept
Some tests like `multiple_types.rs` are passed even if using `check-pass`. But tests should be agnostic to when the actual layout is computed. The `build-pass` is intentionally used for them. I remove FIXME comments.
Mara Bos [Sun, 8 Nov 2020 12:35:58 +0000 (13:35 +0100)]
Rollup merge of #76227 - CDirkx:const-poll, r=KodrAus
Stabilize `Poll::is_ready` and `is_pending` as const
Insta-stabilize the methods `is_ready` and `is_pending` of `std::task::Poll` as const, in the same way as [PR#76198](https://github.com/rust-lang/rust/pull/76198).
Possible because of the recent stabilization of const control flow.
bors [Sun, 8 Nov 2020 11:27:06 +0000 (11:27 +0000)]
Auto merge of #78410 - lcnr:revert75443, r=nikomatsakis
revert #75443, update mir validator
This PR reverts rust-lang#75443 to fix rust-lang#75992 and instead uses rust-lang#75419 to fix rust-lang#75313.
Adapts rust-lang#75419 to correctly deal with unevaluated constants as otherwise some `feature(const_evaluatable_checked)` tests would ICE.
Note that rust-lang#72793 was also fixed by rust-lang#75443, but as that issue only concerns `feature(type_alias_impl_trait)` I deleted that test case for now and would reopen that issue.
rust-lang#75443 may have also allowed some other code to now successfully compile which would make this revert a breaking change after 2 stable versions, but I hope that this is a purely theoretical concern.
See https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/generator.20upvars/near/214617274 for more reasoning about this.
bors [Sun, 8 Nov 2020 02:21:55 +0000 (02:21 +0000)]
Auto merge of #77729 - petrochenkov:mergetarg, r=Mark-Simulacrum
rustc_target: Move some target options from `Target` to `TargetOptions`
The only reason for `Target` to `TargetOptions` to be separate structures is that options in `TargetOptions` have reasonable defaults and options in `Target` don't.
(Otherwise all the options logically belong to a single `Target` struct.)
This PR moves a number of options with reasonable defaults from `Target` to `TargetOptions`, so they no longer needs to be specified explicitly for majority of the targets.
The move also allows to inherit the options from `rustc_target/src/spec/*_base.rs` files in a nicer way.
I didn't change any specific option values here.
The moved options are `target_c_int_width` (defaults to `"32"`), `target_endian` (defaults to `"little"`), `target_os` (defaults to `"none"`), `target_env` (defaults to `""`), `target_vendor` (defaults to `"unknown"`) and `linker_flavor` (defaults to `LinkerFlavor::Gcc`).
Next steps (in later PRs):
- Find a way to merge `TargetOptions` into `Target`
- If not, always access `TargetOptions` fields through `Deref` making it a part of `Target` at least logically (`session.target.target.options.foo` -> `session.target.target.foo`)
- ~Eliminate `session::config::Config` and use `Target` instead (`session.target.target.foo` -> `session.target.foo`)~ Done in https://github.com/rust-lang/rust/pull/77943.
- Avoid tautologies in option names (`target.target_os` -> `target.os`)
- Resolve _ https://github.com/rust-lang/rust/issues/77730 (rustc_target: The differences between `target_os = "none"` and `target_os = "unknown"`, and `target_vendor = "unknown"` and `target_vendor = ""` are unclear) noticed during implementation of this PR.
Aaron Hill [Sun, 8 Nov 2020 01:11:53 +0000 (20:11 -0500)]
Don't fire `CONST_ITEM_MUTATION` lint when borrowing a deref
Fixes #78819
This extends the check for dereferences added in PR #77324
to cover mutable borrows, as well as direct writes. If we're operating
on a dereference of a `const` item, we shouldn't be firing the lint.