Joshua Nelson [Sun, 8 Nov 2020 16:45:13 +0000 (11:45 -0500)]
Don't reuse bindings for `ref mut`
Reusing bindings causes errors later in lowering:
```
error[E0596]: cannot borrow `vec` as mutable, as it is not declared as mutable
--> /checkout/src/test/ui/async-await/argument-patterns.rs:12:20
|
LL | async fn b(n: u32, ref mut vec: A) {
| ^^^^^^^^^^^
| |
| cannot borrow as mutable
| help: consider changing this to be mutable: `mut vec`
```
Guillaume Gomez [Thu, 12 Nov 2020 10:31:51 +0000 (11:31 +0100)]
Rollup merge of #78960 - ethanboxx:const-gen-test-default-error, r=lcnr
Test default values for const parameters.
The last topic on #78433
I originally intended to place these tests in a single file, however, due to them being parser errors that are fatal, they must be in separate files to be detected.
Guillaume Gomez [Thu, 12 Nov 2020 10:31:47 +0000 (11:31 +0100)]
Rollup merge of #78921 - GuillaumeGomez:search-result-title, r=jyn514
Improve the page title switch handling between search and doc
The current behavior often "forgets" to update the page title when discarding/putting back the search results. This isn't optimal which is why I wrote this fix.
Guillaume Gomez [Thu, 12 Nov 2020 10:31:45 +0000 (11:31 +0100)]
Rollup merge of #78916 - lcnr:const-generics-tests, r=varkor
extend const generics test suite
should implement most of #78433, especially all parts of [the hackmd](https://hackmd.io/WnFmN4MjRCqAjGmYfYcu2A?view) which I did not explicitly mention in that issue.
bors [Thu, 12 Nov 2020 10:28:15 +0000 (10:28 +0000)]
Auto merge of #78773 - GuillaumeGomez:theme-picker-shortcut, r=jyn514
Add shortcut for theme picker menu
Follow-up of #78584
Just like you can focus the search input by pressing "S", you can now access the theme picker menu by pressing "T" and navigate through the options only using the keyboard.
bors [Thu, 12 Nov 2020 05:52:17 +0000 (05:52 +0000)]
Auto merge of #78965 - jryans:emscripten-threads-libc, r=kennytm
Update thread and futex APIs to work with Emscripten
This updates the thread and futex APIs in `std` to match the APIs exposed by
Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the
thread parker to compile without errors related to the missing `futex` module.
To make use of this, Rust code must be compiled with `-C target-feature=atomics`
and Emscripten must link with `-pthread`.
I have confirmed this works well locally when building multithreaded crates.
Attempting to enable `std` thread tests currently fails for seemingly obscure
reasons and Emscripten is currently disabled in CI, so further work is needed to
have proper test coverage here.
J. Ryan Stinnett [Wed, 11 Nov 2020 22:25:48 +0000 (22:25 +0000)]
Update thread and futex APIs to work with Emscripten
This updates the thread and futex APIs in `std` to match the APIs exposed by
Emscripten. This allows threads to run on `wasm32-unknown-emscripten` and the
thread parker to compile without errors related to the missing `futex` module.
To make use of this, Rust code must be compiled with `-C target-feature=atomics`
and Emscripten must link with `-pthread`.
I have confirmed this works well locally when building multithreaded crates.
Attempting to enable `std` thread tests currently fails for seemingly obscure
reasons and Emscripten is currently disabled in CI, so further work is needed to
have proper test coverage here.
bors [Thu, 12 Nov 2020 00:33:55 +0000 (00:33 +0000)]
Auto merge of #78782 - petrochenkov:nodoctok, r=Aaron1011
Do not collect tokens for doc comments
Doc comment is a single token and AST has all the information to re-create it precisely.
Doc comments are also responsible for majority of calls to `collect_tokens` (with `num_calls == 1` and `num_calls == 0`, cc https://github.com/rust-lang/rust/pull/78736).
(I also moved token collection into `fn parse_attribute` to deduplicate code a bit.)
bors [Wed, 11 Nov 2020 22:20:07 +0000 (22:20 +0000)]
Auto merge of #78956 - jonas-schievink:rollup-r53giob, r=jonas-schievink
Rollup of 11 pull requests
Successful merges:
- #78216 (Duration::zero() -> Duration::ZERO)
- #78354 (Support enable/disable sanitizers/profiler per target)
- #78417 (BTreeMap: split off most code of append)
- #78832 (look at assoc ct, check the type of nodes)
- #78873 (Add flags customizing behaviour of MIR inlining)
- #78899 (Support inlining diverging function calls)
- #78923 (Cleanup and comment intra-doc link pass)
- #78929 (rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base`)
- #78930 (rustc_taret: Remove `TargetOptions::is_like_android`)
- #78942 (Fix typo in comment)
- #78947 (Ship llvm-cov through llvm-tools)
Jonas Schievink [Wed, 11 Nov 2020 19:59:14 +0000 (20:59 +0100)]
Rollup merge of #78947 - dalance:llvm_cov, r=Mark-Simulacrum
Ship llvm-cov through llvm-tools
`llvm-cov` is used to generate coverage report with LLVM InstrProf-based code coverage #34701.
So if `llvm-cov` is shipped through llvm-tools, users can try it easily accorging to the instruction of [The Rust Unstable Book](https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/source-based-code-coverage.html).
Jonas Schievink [Wed, 11 Nov 2020 19:59:09 +0000 (20:59 +0100)]
Rollup merge of #78929 - petrochenkov:linuxbase, r=joshtriplett
rustc_target: Move target env "gnu" from `linux_base` to `linux_gnu_base`
Follow up to https://github.com/rust-lang/rust/pull/77729.
Changes the target spec hierarchy for Linux from
```
linux_base
├── linux_musl_base
└── linux_uclibc_base
```
where `linux_base` is really `linux_gnu_base` and the inheriting targets replace target env "gnu" with "musl"/"uclibc" to
```
linux_base
├── linux_gnu_base
├── linux_musl_base
└── linux_uclibc_base
```
which is slightly less confusing (I think).
Jonas Schievink [Wed, 11 Nov 2020 19:59:05 +0000 (20:59 +0100)]
Rollup merge of #78899 - tmiasko:inline-diverging, r=oli-obk
Support inlining diverging function calls
The existing heuristic does penalize diverging calls to some degree, but since
it never inlined them previously it might need some further modifications.
Additionally introduce storage markers for all temporaries created by
the inliner. The temporary introduced for destination rebrorrow, didn't
use them previously.
Jonas Schievink [Wed, 11 Nov 2020 19:59:03 +0000 (20:59 +0100)]
Rollup merge of #78873 - tmiasko:inline-opts, r=oli-obk
Add flags customizing behaviour of MIR inlining
* `-Zinline-mir-threshold` to change the default threshold.
* `-Zinline-mir-hint-threshold` to change the threshold used by
functions with inline hint.
Having those as configurable flags makes it possible to experiment with with
different inlining thresholds and substantially increase test coverage of MIR
inlining when used with increased thresholds (for example, necessary to test
#78844).
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.
Tomasz Miąsko [Tue, 10 Nov 2020 00:00:00 +0000 (00:00 +0000)]
Add flags customizing behaviour of MIR inlining
* `-Zinline-mir-threshold` to change the default threshold.
* `-Zinline-mir-hint-threshold` to change the threshold used by
functions with inline hint.
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)
projects / rust.git / log