bors [Wed, 3 Mar 2021 18:01:29 +0000 (18:01 +0000)]
Auto merge of #82553 - tmiasko:update-tracing, r=Mark-Simulacrum
Update tracing to 0.1.25
* Update tracing from 0.1.18 to 0.1.25
* Update tracing-subscriber from 0.2.13 to 0.2.16
* Update tracing-tree from 0.1.6 to 0.1.8
* Add pin-project-lite to the list of allowed dependencies (it is now a direct dependency of tracing).
Yuki Okushi [Wed, 3 Mar 2021 07:27:48 +0000 (16:27 +0900)]
Rollup merge of #82713 - ehuss:update-cargo, r=ehuss
Update cargo
12 commits in 572e201536dc2e4920346e28037b63c0f4d88b3c..c68432f1e5cbbc09833699a951b1b5b059651dff
2021-02-24 16:51:20 +0000 to 2021-03-02 18:26:29 +0000
- Don't panic when printing JSON with non-utf8 paths (rust-lang/cargo#9226)
- Detect changes for JSON spec targets. (rust-lang/cargo#9223)
- Fix `cargo_target_empty_cfg` test with env var. (rust-lang/cargo#9225)
- Correct default cargo new edition (rust-lang/cargo#9202)
- Update split-debuginfo docs around the default. (rust-lang/cargo#9224)
- Minor update to registry API error messages. (rust-lang/cargo#9213)
- Some minor code cleanup. (rust-lang/cargo#9214)
- doc: Fix spelling worksapce->workspace (rust-lang/cargo#9212)
- Update SPDX version in docs. (rust-lang/cargo#9209)
- Throw error if CARGO_TARGET_DIR is an empty string (rust-lang/cargo#8939)
- testsuite: Use split debuginfo on macos. (rust-lang/cargo#9207)
- testsuite: Improve performance when using rustup. (rust-lang/cargo#9206)
Yuki Okushi [Wed, 3 Mar 2021 07:27:42 +0000 (16:27 +0900)]
Rollup merge of #82689 - camelid:rustdoc-nominated, r=Manishearth
meta: Notify Zulip for rustdoc nominated issues
The rustdoc team does not currently use the `I-nominated` label, unlike
the libs and compiler teams (and maybe others). One reason for this is
that the other teams discuss their nominated issues in meetings, while
rustdoc is an async-only team.
However, it might be helpful to start using the `I-nominated` label for
rustdoc. The team currently uses a `cc ``@rust-lang/rustdoc``` ping as the
equivalent, but it's easier to track issues when they use `I-nominated`.
Also we'd be more consistent with the other teams' procedures.
Since rustdoc doesn't have meetings, I propose we instead use the
triagebot notify Zulip functionality to create a topic in `#rustdoc` on
Zulip and ping the team. So it would look a bit like the procedure for
WG-prioritization when an issue acquires the `I-prioritize` label.
cc ``@rust-lang/rustdoc`` for approval of the change
r? ``@Mark-Simulacrum`` to make sure I configured triagebot correctly
Yuki Okushi [Wed, 3 Mar 2021 07:27:41 +0000 (16:27 +0900)]
Rollup merge of #82589 - LinkTed:master, r=joshtriplett
unix: Non-mutable bufs in send_vectored_with_ancillary_to
This is the same PR as [#79753](https://github.com/rust-lang/rust/pull/79753). It was closed because of inactivity. Therefore, I create a new one. ````@lukaslihotzki````
This adds overflow checking to `is_enclave_range` and `is_user_range` in `sgx::os::fortanix_sgx::mem` in order to mitigate possible security issues with enclave code. It also accounts for an edge case where the memory range provided ends exactly at the end of the address space, where calculating `p + len` would overflow back to zero despite the range potentially being valid.
bors [Tue, 2 Mar 2021 21:01:47 +0000 (21:01 +0000)]
Auto merge of #82562 - llogiq:one-up-82248, r=oli-obk
Optimize counting digits in line numbers during error reporting further
This one-ups #82248 by switching the strategy: Instead of dividing the value by 10 repeatedly, we compare with a limit that we multiply by 10 repeatedly. In my benchmarks, this took between 50% and 25% of the original time. The reasons for being faster are:
1. While LLVM is able to replace a division by constant with a multiply + shift, a plain multiplication is still faster. However, this doesn't even factor, because
2. Multiplication, unlike division, is const. We also use a simple for-loop instead of a more complex loop + break, which allows
3. rustc to const-fold the whole loop, and indeed the assembly output simply shows a series of comparisons.
bors [Tue, 2 Mar 2021 16:08:32 +0000 (16:08 +0000)]
Auto merge of #82043 - tmiasko:may-have-side-effect, r=kennytm
Turn may_have_side_effect into an associated constant
The `may_have_side_effect` is an implementation detail of `TrustedRandomAccess`
trait. It describes if obtaining an iterator element may have side effects. It
is currently implemented as an associated function.
Turn `may_have_side_effect` into an associated constant. This makes the
value immediately available to the optimizer.
bors [Tue, 2 Mar 2021 12:57:06 +0000 (12:57 +0000)]
Auto merge of #82698 - JohnTitor:rollup-htd533c, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #80189 (Convert primitives in the standard library to intra-doc links)
- #80874 (Update intra-doc link documentation to match the implementation)
- #82376 (Add option to enable MIR inlining independently of mir-opt-level)
- #82516 (Add incomplete feature gate for inherent associate types.)
- #82579 (Fix turbofish recovery with multiple generic args)
- #82593 (Teach rustdoc how to display WASI.)
- #82597 (Get TyCtxt from self instead of passing as argument in AutoTraitFinder)
- #82627 (Erase late bound regions to avoid ICE)
- #82661 (:arrow_up: rust-analyzer)
- #82691 (Update books)
Yuki Okushi [Tue, 2 Mar 2021 12:23:22 +0000 (21:23 +0900)]
Rollup merge of #82691 - ehuss:update-books, r=ehuss
Update books
## reference
2 commits in 361367c126290ac17cb4089f8d38fd8b2ac43f98..3b6fe80c205d2a2b5dc8a276192bbce9eeb9e9cf
2021-02-15 09:58:13 -0800 to 2021-02-22 22:09:17 -0800
- Add an extra fn() entry to the variance table in the subtyping chapter (rust-lang-nursery/reference#874)
- Turbofish: Explain what the example is of. (rust-lang-nursery/reference#966)
## book
28 commits in db5e8a5105aa22979490dce30e33b68d8645761d..0f87daf683ae3de3cb725faecb11b7e7e89f0e5a
2021-02-12 16:58:20 -0500 to 2021-03-01 08:54:04 -0500
- Ohhh the should_panic was for mdbook test. Oops
- Fix bad regex in the update rustc script and regenerate broken output
- Clarify that we only mentioned unwrap_or_else, but haven't explained it
- Add ferris to some listings that don't compile. Fixes rust-lang/book#2598
- Remove fancy quote from a code comment
- Panic now points at our code, not stdlib slice code
- Disable playground on thread::sleep examples
- Disable playground button on listings in ch 12 that use CLI args
- Reword ambiguous sentence. Fixes rust-lang/book#2317.
- Rename shoes_in_my_size to shoes_in_size to be a better example
- Fix visible "ANCHOR: here" in listing 13-21 (rust-lang/book#2628)
- minor clarification about deriving Copy and Clone (rust-lang/book#2627)
- Clarify relationship of trait to mock object
- Fix "message" that should be "method"
- Fix rust-lang/book#2625 (rust-lang/book#2626)
- fix misleading hash claim (rust-lang/book#2621)
- Make link syntax consistent and word wrap
- Added hyperlinks to Appendices
- Use console syntax highlighting in some more places
- Merge remote-tracking branch 'origin/pr/2615'
- Fix broken blockquote
- Update one more bit of output caught by the update rust script
- Update and clarify some text affected by the rand update
- Update lock files and output
- Update error output for changes to chapter 10 listings
- Merge remote-tracking branch 'origin/pr/2542'
- Tweak wording in for loop explanation
- Merge remote-tracking branch 'origin/pr/2460'
Yuki Okushi [Tue, 2 Mar 2021 12:23:15 +0000 (21:23 +0900)]
Rollup merge of #82516 - PoignardAzur:inherent-impl-ty, r=oli-obk
Add incomplete feature gate for inherent associate types.
Mentored by ``````@oli-obk``````
So far the only change is that instead of giving an automatic error, the following code compiles:
```rust
struct Foo;
impl Foo {
type Bar = isize;
}
```
The backend work to make it actually usable isn't there yet. In particular, this:
```rust
let x : Foo::Bar;
```
will give you:
```sh
error[E0223]: ambiguous associated type
--> /$RUSTC_DIR/src/test/ui/assoc-inherent.rs:15:13
|
LL | let x : Foo::Bar;
| ^^^^^^^^ help: use fully-qualified syntax: `<Foo as Trait>::Bar`
```
Yuki Okushi [Tue, 2 Mar 2021 12:23:14 +0000 (21:23 +0900)]
Rollup merge of #82376 - tmiasko:inline-options, r=oli-obk
Add option to enable MIR inlining independently of mir-opt-level
Add `-Zinline-mir` option that enables MIR inlining independently of the
current MIR opt level. The primary use-case is enabling MIR inlining on the
default MIR opt level.
Turn inlining thresholds into optional values to make it possible to configure
different defaults depending on the current mir-opt-level (although thresholds
are yet to be used in such a manner).
I haven't documented things that I consider 'just bugs', like https://github.com/rust-lang/rust/issues/77732, but I have documented features that aren't implemented, like https://github.com/rust-lang/rust/issues/78800.
Yuki Okushi [Tue, 2 Mar 2021 12:23:12 +0000 (21:23 +0900)]
Rollup merge of #80189 - jyn514:convert-primitives, r=poliorcetics
Convert primitives in the standard library to intra-doc links
Blocked on https://github.com/rust-lang/rust/pull/80181. I forgot that this needs to wait for the beta bump so the standard library can be documented with `doc --stage 0`.
Notably I didn't convert `core::slice` because it's like 50 links and I got scared :fearful:
bors [Tue, 2 Mar 2021 05:21:25 +0000 (05:21 +0000)]
Auto merge of #82688 - GuillaumeGomez:rollup-b754t11, r=GuillaumeGomez
Rollup of 7 pull requests
Successful merges:
- #80734 (check that first arg to `panic!()` in const is `&str`)
- #81932 (Always compile rustdoc with debug logging enabled when `download-rustc` is set)
- #82018 (Remove the dummy cache in `DocContext`; delete RenderInfo)
- #82598 (Check stability and feature attributes in rustdoc)
- #82655 (Highlight identifier span instead of whole pattern span in `unused` lint)
- #82662 (Warn about unknown doc attributes)
- #82676 (Change twice used large const table to static)
Camelid [Tue, 2 Mar 2021 00:33:47 +0000 (16:33 -0800)]
meta: Notify Zulip for rustdoc nominated issues
The rustdoc team does not currently use the `I-nominated` label, unlike
the libs and compiler teams (and maybe others). One reason for this is
that the other teams discuss their nominated issues in meetings, while
rustdoc is an async-only team.
However, it might be helpful to start using the `I-nominated` label for
rustdoc. The team currently uses a `cc @rust-lang/rustdoc` ping as the
equivalent, but it's easier to track issues when they use `I-nominated`.
Also we'd be more consistent with the other teams' procedures.
Since rustdoc doesn't have meetings, I propose we instead use the
triagebot notify Zulip functionality to create a topic in `#rustdoc` on
Zulip and ping the team. So it would look a bit like the procedure for
WG-prioritization when an issue acquires the `I-prioritize` label.
Guillaume Gomez [Mon, 1 Mar 2021 23:50:11 +0000 (00:50 +0100)]
Rollup merge of #82676 - dtolnay:powers, r=Mark-Simulacrum
Change twice used large const table to static
This table is used twice in core::num::dec2flt::algorithm::power_of_ten. According to the semantics of const, a separate huge definition of the table is inlined at both places.
Theoretically this gets cleaned up by optimization passes, but in practice I am experiencing a miscompile from LTO on this code. Making the table a static, which would only be defined a single time and not require attention from LTO, eliminates the miscompile and seems semantically more appropriate anyway. A separate bug report on the LTO bug is forthcoming.
Guillaume Gomez [Mon, 1 Mar 2021 23:50:09 +0000 (00:50 +0100)]
Rollup merge of #82655 - SkiFire13:fix-issue-81314, r=estebank
Highlight identifier span instead of whole pattern span in `unused` lint
Fixes #81314
This pretty much just changes the span highlighted in the lint from `pat_sp` to `ident.span`. There's however an exception, which is in patterns with shorthands like `Point { y, ref mut x }`, where a suggestion to change just `x` would be invalid; in those cases I had to keep the pattern span. Another option would be suggesting something like `Point { y, x: ref mut _x }`.
I also added a new test since there weren't any test that checked the `unused` lint with optional patterns.
Guillaume Gomez [Mon, 1 Mar 2021 23:50:07 +0000 (00:50 +0100)]
Rollup merge of #82018 - jyn514:no-dummy-cache, r=camelid,GuillaumeGomez
Remove the dummy cache in `DocContext`; delete RenderInfo
The same information is available everywhere; the only reason the dummy
cache was needed is because it was previously stored in three different
places. This consolidates the info a bit so the cache in `DocContext` is
used throughout. As a bonus, it also completely removes `RenderInfo`.
- Return a `Cache` from `run_global_ctxt`, not `RenderInfo`
- Remove the unused `render_info` from `run_renderer`
- Remove RenderInfo altogether
Helps with https://github.com/rust-lang/rust/pull/82014. The next step is to move the `populate()` call before the `collect_intra_doc_links` pass, which currently breaks because a) lots of the cache is populated in early passes, and b) intra_doc_links itself sets some info with `register_res`. I'm working on separate PR for that to avoid making too many big changes at once.
Guillaume Gomez [Mon, 1 Mar 2021 23:50:06 +0000 (00:50 +0100)]
Rollup merge of #81932 - jyn514:rustdoc-logging, r=Mark-Simulacrum
Always compile rustdoc with debug logging enabled when `download-rustc` is set
Previously, logging at DEBUG or below would always be silenced, because
rustc compiles tracing with the `static_max_level_info` feature. That
makes sense for release artifacts, but not for developing rustdoc.
Instead, this compiles two different versions of tracing: one in the
release artifacts, distributed in the sysroot, and a new version
compiled by rustdoc. Since `rustc_driver` is always linked to the
version of sysroot, this copy/pastes `init_env_logging` into rustdoc.
To avoid compiling an unnecessary version of tracing when
`download-rustc` isn't set, this adds a new `using-ci-artifacts`
feature for rustdoc and passes that feature in bootstrap.
Addresses https://github.com/rust-lang/rust/issues/81930. This builds on https://github.com/rust-lang/rust/pull/79540.
David Tolnay [Mon, 1 Mar 2021 07:51:30 +0000 (23:51 -0800)]
Change twice used large const table to static
This table is used twice in core::num::dec2flt::algorithm::power_of_ten.
According to the semantics of const, a separate huge definition of the
table is inlined at both places.
fn power_of_ten(e: i16) -> Fp {
assert!(e >= table::MIN_E);
let i = e - table::MIN_E;
let sig = table::POWERS.0[i as usize];
let exp = table::POWERS.1[i as usize];
Fp { f: sig, e: exp }
}
Theoretically this gets cleaned up by optimization passes, but in
practice I am experiencing a miscompile from LTO on this code. Making
the table a static, which would only be defined a single time and not
require attention from LTO, eliminates the miscompile and seems
semantically more appropriate anyway. A separate bug report on the LTO
bug is forthcoming.
bors [Mon, 1 Mar 2021 18:10:38 +0000 (18:10 +0000)]
Auto merge of #82587 - taiki-e:unaligned_references, r=oli-obk
Enable report_in_external_macro in unaligned_references
Fixes an issue where `unaligned_references` is not triggered in external macros, unlike `safe_packed_borrows`.
Also, given that this lint is planned to eventually change to hard error (#82525), it would make sense for this lint to be triggered for external macros as well.
See https://github.com/taiki-e/pin-project-lite/pull/55#issuecomment-787038676 and https://github.com/taiki-e/pin-project-lite/pull/55#issuecomment-787052874 for more.
Joshua Nelson [Mon, 1 Mar 2021 16:25:11 +0000 (11:25 -0500)]
Rollup merge of #82645 - rkjnsn:patch-3, r=Mark-Simulacrum
Clarify that SyncOnceCell::set blocks.
Reading the discussion of this feature, I gained the mistaken impression that neither `set` nor `get` blocked, and thus calling `get` immediately after `set` was not guaranteed to succeed. It turns out that `set` *does* block, guaranteeing that the cell contains a value once `set` returns. This change updates the documentation to state that explicitly.
Joshua Nelson [Mon, 1 Mar 2021 16:25:08 +0000 (11:25 -0500)]
Rollup merge of #82620 - jyn514:apply-renamed-lints, r=Manishearth
Apply lint restrictions from renamed lints
Previously, if you denied the old name of a renamed lint, it would warn
about using the new name, but otherwise do nothing. Now, it will behave
the same as if you'd used the new name.
Joshua Nelson [Mon, 1 Mar 2021 16:25:06 +0000 (11:25 -0500)]
Rollup merge of #82480 - jyn514:no-enable-constant, r=Mark-Simulacrum
Remove `ENABLE_DOWNLOAD_RUSTC` constant
`ENABLE_DOWNLOAD_RUSTC` was introduced as part of the MVP for `download-rustc` as a way not to rebuild artifacts that have already been downloaded. Unfortunately, it doesn't work very well:
- Steps are ignored by default, which makes it easy to leave out a step
that should be built. For example, the MVP forgot to enable any tests,
so it was only possible to *build* locally.
- It didn't work correctly even when it was enabled: calling
`builder.ensure()` would completely ignore the constant and rebuild the
step anyway. This has no obvious fix since `ensure()` has to return a
`Step::Output`.
Instead, this handles `download-rustc` in `impl Step for Rustc` and
`impl Step for Std`, which to my knowledge are the only build steps that
don't first go through `impl Step for Sysroot` (`Rustc` is used for
the `rustc-dev` component).
See https://github.com/rust-lang/rust/pull/79540#discussion_r563350075 and https://github.com/rust-lang/rust/issues/81930 for further context.
Here are some example runs with these changes and `download-rustc`
enabled:
```
$ x.py build src/tools/clippy
Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 1m 09s
Building stage1 tool cargo-clippy (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.11s
$ x.py test src/tools/clippy
Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Building stage1 tool clippy-driver (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.09s
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.28s
Finished release [optimized] target(s) in 15.26s
Running build/x86_64-unknown-linux-gnu/stage1-tools/x86_64-unknown-linux-gnu/release/deps/clippy_driver-8b407b140e0aa91c
test result: ok. 592 passed; 0 failed; 3 ignored; 0 measured; 0 filtered out
$ x.py build src/tools/rustdoc
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 41.28s
Build completed successfully in 0:00:41
$ x.py test src/test/rustdoc-ui
Building stage0 tool compiletest (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.12s
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
Finished release [optimized] target(s) in 0.10s
test result: ok. 105 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 8.15s
$ x.py build compiler/rustc
Finished dev [unoptimized + debuginfo] target(s) in 0.09s
Build completed successfully in 0:00:00
```
Note a few things:
- Clippy depends on stage1 rustc-dev artifacts, but rustc didn't have to
be recompiled. Instead, the artifacts were copied automatically.
- All steps are always enabled. There is no danger of forgetting a step,
since only the entrypoints have to handle `download-rustc`.
- Building the compiler (`compiler/rustc`) automatically does no work.
Helps with https://github.com/rust-lang/rust/issues/81930.
Joshua Nelson [Mon, 1 Mar 2021 16:25:03 +0000 (11:25 -0500)]
Rollup merge of #82360 - osa1:issue82317, r=Mark-Simulacrum
config.toml parsing error improvements
Improve error messages for musl-libdir and wasi-root keys. Previously
the parser would panic with `unwrap()`. Now it prints
Target "wasm32-wasi" does not have a "wasi-root" key
(and similar for the `musl-libdir` field, which is used in target that
use musl)
Also update comments around wasi-root field to make it clear that the
field is only valid in wasm32-wasi target and needs to be moved to a
`[target.wasm32-wasi]` section to be valid.
bors [Mon, 1 Mar 2021 14:34:19 +0000 (14:34 +0000)]
Auto merge of #82216 - kulikjak:fix-solaris-target, r=nagisa,Mark-Simulacrum
make x86_64-pc-solaris the default target for x86-64 Solaris
This change makes `x86_64-pc-solaris` the default compilation target for x86-64 Solaris/Illumos (based on [this exchange](https://github.com/rust-lang/rust/issues/68214#issuecomment-748042054) with `@varkor).`
I tried several ways of doing this (leveraging the alias support added with #61761 and improved/fixed with #80073) and found out that cross-compilation to the new one is by far the simplest way of doing this. It can be achieved by adding the following arguments: `--build x86_64-sun-solaris --host x86_64-pc-solaris --target x86_64-pc-solaris` and enabling the cross compilation with `PKG_CONFIG_ALLOW_CROSS=1` environment variable.
I also removed alias support altogether - `x86_64-pc-solaris` and `x86_64-sun-solaris` are now two separate targets. The problem with aliases is that even if rust internally knows that two are the same, other tools building with rust don't know that, resulting in build issues like the one with firefox mentioned [here](https://github.com/rust-lang/rust/issues/68214#issuecomment-746144229). I think that once the dust settles and `x86_64-pc-solaris` becomes the default, `x86_64-sun-solaris` can be removed.
If you agree with the above, I have two subsequent questions:
1. Is there a preferred way to display deprecation warnings when `x86_64-sun-solaris` is passed into the compiler as an argument? I am not sure whether target deprecation was done before.
2. Where would be the best way to document this change for those using rust on Solaris? Without the cross-compilation arguments (used once to build a new version), the build won't work. Should I add it into [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md)?
bors [Mon, 1 Mar 2021 11:53:24 +0000 (11:53 +0000)]
Auto merge of #78360 - tmiasko:storage-markers, r=wesleywiser,oli-obk
Remove storage markers if they won't be used during code generation
The storage markers constitute a substantial portion of all MIR
statements. At the same time, for builds without any optimizations,
the storage markers have no further use during and after MIR
optimization phase.
If storage markers are not necessary for code generation, remove them.
bors [Mon, 1 Mar 2021 08:22:06 +0000 (08:22 +0000)]
Auto merge of #82654 - JohnTitor:rollup-nkcdkzp, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #82309 (Propagate RUSTDOCFLAGS in the environment when documenting)
- #82403 (rustbuild: print out env vars on verbose rustc invocations)
- #82507 (Rename the `tidy` binary to `rust-tidy`)
- #82531 (Add GUI tests)
- #82532 (Add `build.print_step_rusage` to config.toml)
- #82543 (fix env var name in CI)
- #82622 (Propagate `--test-args` for `x.py test src/tools/cargo`)
- #82628 (Try to clarify GlobalAlloc::realloc documentation comment.)
- #82630 (Fix a typo in the `find_anon_type` doc)
- #82643 (Add more proc-macro attribute tests)
Improve error messages for musl-libdir and wasi-root keys. Previously
the parser would panic with `unwrap()`. Now it prints
Target "wasm32-wasi" does not have a "wasi-root" key
(and similar for the `musl-libdir` field, which is used in target that
use musl)
Also update comments around wasi-root field to make it clear that the
field is only valid in wasm32-wasi target and needs to be moved to a
`[target.wasm32-wasi]` section to be valid.
Yuki Okushi [Mon, 1 Mar 2021 06:07:38 +0000 (15:07 +0900)]
Rollup merge of #82628 - vakaras:realloc-doc, r=Mark-Simulacrum
Try to clarify GlobalAlloc::realloc documentation comment.
This PR tries to improve the documentation of [GlobalAlloc::realloc](https://doc.rust-lang.org/alloc/alloc/trait.GlobalAlloc.html#method.realloc) with two aspects:
1. Explicitly mention that `realloc` preserves the contents of the original memory block.
2. Explicitly mention which layout should be used to deallocate the reallocated block.
Yuki Okushi [Mon, 1 Mar 2021 06:07:35 +0000 (15:07 +0900)]
Rollup merge of #82532 - pnkfelix:rustbuild-print-step-rusage, r=Mark-Simulacrum
Add `build.print_step_rusage` to config.toml
Adds `build.print_step_rusage` to config.toml, which is meant to be an easy way to let compiler developers get feedback on the terminal during bootstrap about resource usage during each step.
The output is piggy-backed on `[PRINT-STEP-TIMINGS]`, mostly because the functionality seemed to naturally fit there in the overall control-flow and output structure (even if very little is shared between the implementations themselves).
Some sample output (from my Linux box, where I believe the `max rss` output to be somewhat trust-worthy...):
Yuki Okushi [Mon, 1 Mar 2021 06:07:34 +0000 (15:07 +0900)]
Rollup merge of #82531 - GuillaumeGomez:gui-tests-start, r=jyn514
Add GUI tests
The start of a lot more of GUI tests! \o/
One test is to ensure that the search input can always be selected in all rustdoc "modes" (mobile, tablet mostly) whereas the second checks the shortcuts.
Yuki Okushi [Mon, 1 Mar 2021 06:07:33 +0000 (15:07 +0900)]
Rollup merge of #82507 - jyn514:tidy-windows, r=Mark-Simulacrum
Rename the `tidy` binary to `rust-tidy`
This avoids naming collisions, particularly on Windows where the
dynamic library variable is PATH and setting it causes the in-tree
`tidy` to take precedence over the HTML tidy used by compiletest.
This doesn't change the x.py interface in any way, it still accepts `x.py test tidy` and prints error messages about `tidy`. It only changes the name of the file on disk.
Yuki Okushi [Mon, 1 Mar 2021 06:07:32 +0000 (15:07 +0900)]
Rollup merge of #82403 - pnkfelix:rustbuild-emit-env-vars-on-verbose-verbose, r=Mark-Simulacrum
rustbuild: print out env vars on verbose rustc invocations
Print out environment variables related to Rust on sufficiently verbose rustc invocations.
Output is filtered via heuristic of only printing environment variables whose keys start with "RUST" or "CARGO." This filtering is mostly motivated by my not caring to see e.g. "PATH" in my own output, though it is also motivated as a way to try to avoid printing out personal secrets like github keys that people might have stored in their environments for better or for worse, especially since build output is often pasted into bug reports or gists.
Fix #38686.
<details>
<summary>Click here to see sample output</summary>
Yuki Okushi [Mon, 1 Mar 2021 06:07:31 +0000 (15:07 +0900)]
Rollup merge of #82309 - jyn514:rustdocflags, r=Mark-Simulacrum
Propagate RUSTDOCFLAGS in the environment when documenting
Previously, RUSTDOCFLAGS would get overriden when bootstrap set
`RUSTDOCFLAGS` itself. Propagate the flag manually, using the same logic
as `RUSTFLAGS`.
Joshua Nelson [Thu, 25 Feb 2021 05:16:47 +0000 (00:16 -0500)]
Remove `krate.version`; fix `crate_version` in JSON
Previously, `JsonRenderer::after_krate` called `krate.version.clone()`.
The problem was it did that after the version was already moved into the
cache, so it would always be None. The fix was to get the version from
the cache instead.
Joshua Nelson [Fri, 12 Feb 2021 02:29:22 +0000 (21:29 -0500)]
Remove the dummy cache in `DocContext`
The same information is available everywhere; the only reason the dummy
cache was needed is because it waas previously stored in three different
places. This consolidates the info a bit so the cache in `DocContext` is
used throughout. As a bonus, it means `renderinfo` is used much much
less.
- Return a `Cache` from `run_global_ctxt`, not `RenderInfo`
- Remove the unused `render_info` from `run_renderer`
- Remove RefCell around `inlined`
- Add intra-doc links
Joshua Nelson [Mon, 1 Mar 2021 02:59:43 +0000 (21:59 -0500)]
Remove deleted pass from rustdoc test suite
`src/test/rustdoc-ui/deprecated-attrs.rs`
tells rustdoc to run the `collapse-docs` pass, which no longer exists
(it was removed in https://github.com/rust-lang/rust/pull/80261).
Rustdoc doesn't actually give a proper diagnostic here; instead it
prints an `error!` log. Now that tracing is compiled unconditionally,
the log is now being emitted by default, because it's at the error
level.
rustdoc shouldn't be using `error!` logging for diagnostics in the first
place, but in the meantime this change gets the testsuite to pass.
Joshua Nelson [Mon, 28 Dec 2020 18:28:29 +0000 (13:28 -0500)]
Always compile rustdoc with debug logging enabled when `download-rustc` is set
Previously, logging at DEBUG or below would always be silenced, because
rustc compiles tracing with the `static_max_level_info` feature. That
makes sense for release artifacts, but not for developing rustdoc.
Instead, this compiles two different versions of tracing: one in the
release artifacts, distributed in the sysroot, and a new version
compiled by rustdoc. Since `rustc_driver` is always linked to the
version of sysroot, this copy/pastes `init_env_logging` into rustdoc.
The builds the second version of tracing unconditionally; see the code
for details on why.
bors [Mon, 1 Mar 2021 02:48:29 +0000 (02:48 +0000)]
Auto merge of #81094 - ssomers:btree_drainy_refactor_3, r=Mark-Simulacrum
BTreeMap: split up range_search into two stages
`range_search` expects the caller to pass the same root twice and starts searching a node for both bounds of a range. It's not very clear that in the early iterations, it searches twice in the same node. This PR splits that search up in an initial `find_leaf_edges_spanning_range` that postpones aliasing until the last second, and a second phase for continuing the search for the range in the each subtree independently (`find_lower_bound_edge` & `find_upper_bound_edge`), which greatly helps for use in #81075. It also moves those functions over to the search module.
bors [Mon, 1 Mar 2021 00:07:29 +0000 (00:07 +0000)]
Auto merge of #82601 - terhechte:catalyst-support-m1-fix, r=petrochenkov
Fixed support for macOS Catalyst on ARM64
When I initially added Arm64 Catalyst support in https://github.com/rust-lang/rust/pull/77484 I had access to a DTK. However, while waiting to merge the PR some other changes were merged which caused conflicts in the branch. When fixing those conflicts I had no access to the DTK anymore and didn't try out if the resulting binaries did indeed work on Apple Silicon. I finally have a M1 and I realized that some small changes were necessary to support Apple Silicon. This PR adds the required changes. I've been running binaries generated with this branch for some time now and they work without issues.