Joshua Nelson [Sun, 27 Sep 2020 01:27:55 +0000 (21:27 -0400)]
Separate `private_intra_doc_links` and `broken_intra_doc_links` into separate lints
This is not ideal because it means `deny(broken_intra_doc_links)` will
no longer `deny(private_intra_doc_links)`. However, it can't be fixed
with a new lint group, because `broken` is already in the `rustdoc` lint
group; there would need to be a way to nest groups somehow.
This also removes the early `return` so that the link will be generated
even though it gives a warning.
Auto merge of #71274 - RalfJung:raw-init-check-aggregate, r=petrochenkov
might_permit_raw_init: also check aggregate fields
This is the next step for https://github.com/rust-lang/rust/issues/66151: when doing `mem::zeroed`/`mem::uninitialized`, also recursively check fields of aggregates (except for arrays) for whether they permit zero/uninit initialization.
Originally I only meant to fix #76925. But the hack with `has_primitive` was so bad it was easier to fix the primitive issues than to try and work around it.
Note that this still has one bug: `std::primitive::i32::MAX` does not resolve. However, this fixes the ICE so I'm fine with fixing the link in a later PR.
This is part of a series of refactors to make #76467 possible.
This is best reviewed commit-by-commit; it has detailed commit messages.
Auto merge of #77154 - fusion-engineering-forks:lazy-stdio, r=dtolnay
Remove std::io::lazy::Lazy in favour of SyncOnceCell
The (internal) std::io::lazy::Lazy was used to lazily initialize the stdout and stdin buffers (and mutexes). It uses atexit() to register a destructor to flush the streams on exit, and mark the streams as 'closed'. Using the stream afterwards would result in a panic.
Stdout uses a LineWriter which contains a BufWriter that will flush the buffer on drop. This one is important to be executed during shutdown, to make sure no buffered output is lost. It also forbids access to stdout afterwards, since the buffer is already flushed and gone.
Stdin uses a BufReader, which does not implement Drop. It simply forgets any previously read data that was not read from the buffer yet. This means that in the case of stdin, the atexit() function's only effect is making stdin inaccessible to the program, such that later accesses result in a panic. This is uncessary, as it'd have been safe to access stdin during shutdown of the program.
---
This change removes the entire io::lazy module in favour of SyncOnceCell. SyncOnceCell's fast path is much faster (a single atomic operation) than locking a sys_common::Mutex on every access like Lazy did.
However, SyncOnceCell does not use atexit() to drop the contained object during shutdown.
As noted above, this is not a problem for stdin. It simply means stdin is now usable during shutdown.
The atexit() call for stdout is moved to the stdio module. Unlike the now-removed Lazy struct, SyncOnceCell does not have a 'gone and unusable' state that panics. Instead of adding this again, this simply replaces the buffer with one with zero capacity. This effectively flushes the old buffer *and* makes any writes afterwards pass through directly without touching a buffer, making print!() available during shutdown without panicking.
---
In addition, because the contents of the SyncOnceCell are no longer dropped, we can now use `&'static` instead of `Arc` in `Stdout` and `Stdin`. This also saves two levels of indirection in `stdin()` and `stdout()`, since Lazy effectively stored a `Box<Arc<T>>`, and SyncOnceCell stores the `T` directly.
Auto merge of #76986 - jonas-schievink:ret-in-reg, r=nagisa
Return values up to 128 bits in registers
This fixes https://github.com/rust-lang/rust/issues/26494#issuecomment-619506345 by making Rust's default ABI pass return values up to 128 bits in size in registers, just like the System V ABI.
The result is that these methods from the comment linked above now generate the same code, making the Rust ABI as efficient as the `"C"` ABI:
Auto merge of #77247 - jonas-schievink:rollup-r6ehh8h, r=jonas-schievink
Rollup of 10 pull requests
Successful merges:
- #76917 (Add missing code examples on HashMap types)
- #77107 (Enable const propagation into operands at mir_opt_level=2)
- #77129 (Update cargo)
- #77167 (Fix FIXME in core::num test: Check sign of zero in min/max tests.)
- #77184 (Rust vec bench import specific rand::RngCore)
- #77208 (Late link args order)
- #77209 (Fix documentation highlighting in ty::BorrowKind)
- #77231 (Move helper function for `missing_const_for_fn` out of rustc to clippy)
- #77235 (pretty-print-reparse hack: Rename some variables for clarity)
- #77243 (Test more attributes in test issue-75930-derive-cfg.rs)
Jonas Schievink [Sat, 26 Sep 2020 23:53:23 +0000 (01:53 +0200)]
Rollup merge of #77208 - mati865:late-link-args-order, r=petrochenkov
Late link args order
MSYS2 changed how winpthreads is built and as the result it now depends on more mingw-w64 libraries.
This PR affects only MinGW targets since nobody else is using `late_link_args_{dynamic,static}`. Now the order is similar to how it used to be before https://github.com/rust-lang/rust/pull/67502.
Jonas Schievink [Sat, 26 Sep 2020 23:53:18 +0000 (01:53 +0200)]
Rollup merge of #77129 - ehuss:update-cargo, r=ehuss
Update cargo
7 commits in 8777a6b1e8834899f51b7e09cc9b8d85b2417110..05c611ae3c4255b7a2bcf4fcfa65b20286a07839
2020-09-15 19:11:03 +0000 to 2020-09-23 23:10:38 +0000
- --workspace flag for locate-project to find the workspace root (rust-lang/cargo#8712)
- Remove some badges documentation. (rust-lang/cargo#8727)
- Add plain message format for locate-project (rust-lang/cargo#8707)
- Add a term option to configure the progress bar (rust-lang/cargo#8165)
- Replace d_as_f64 with as_secs_f64 (rust-lang/cargo#8721)
- Add cross check to filters_target test. (rust-lang/cargo#8713)
- Add test for whitespace behavior in env flags. (rust-lang/cargo#8706)
Jonas Schievink [Sat, 26 Sep 2020 23:53:16 +0000 (01:53 +0200)]
Rollup merge of #77107 - bugadani:perf, r=oli-obk
Enable const propagation into operands at mir_opt_level=2
Feature was added in #74507 but gated with `mir_opt_level>=3` because of compile time regressions. Let's see whether the LLVM 11 update solves that.
As the [perf results](https://github.com/rust-lang/rust/pull/77107#issuecomment-697668154) show, enabling this optimization results in a lot less regression as before.
Auto merge of #76897 - Aaron1011:feature/min-proc-macro-metadata, r=petrochenkov
Encode less metadata for proc-macro crates
Currently, we serialize the same crate metadata for proc-macro crates as
we do for normal crates. This is quite wasteful - almost none of this
metadata is ever used, and much of it can't even be deserialized (if it
contains a foreign `CrateNum`).
This PR changes metadata encoding to skip encoding the majority of crate
metadata for proc-macro crates. Most of the `Lazy<[T]>` fields are left
completetly empty, while the non-lazy fields are left as-is.
Additionally, proc-macros now have a def span that does not include
their body. This was done for normal functions in #75465, but was missed
for proc-macros.
As a result of this PR, we should only ever encode local `CrateNum`s
when encoding proc-macro crates. I've added a specialized serialization
impl for `CrateNum` to assert this.
Aaron Hill [Fri, 18 Sep 2020 20:18:10 +0000 (16:18 -0400)]
Encode less metadata for proc-macro crates
Currently, we serialize the same crate metadata for proc-macro crates as
we do for normal crates. This is quite wasteful - almost none of this
metadata is ever used, and much of it can't even be deserialized (if it
contains a foreign `CrateNum`).
This PR changes metadata encoding to skip encoding the majority of crate
metadata for proc-macro crates. Most of the `Lazy<[T]>` fields are left
completetly empty, while the non-lazy fields are left as-is.
Additionally, proc-macros now have a def span that does not include
their body. This was done for normal functions in #75465, but was missed
for proc-macros.
As a result of this PR, we should only ever encode local `CrateNum`s
when encoding proc-macro crates. I've added a specialized serialization
impl for `CrateNum` to assert this.
Rollup merge of #77161 - est31:swich_len_already_trusted, r=petrochenkov
Remove TrustedLen requirement from BuilderMethods::switch
The main use case of TrustedLen is allowing APIs to specialize on it,
but no use of it uses that specialization. Instead, only the .len()
function provided by ExactSizeIterator is used, which is already
required to be accurate.
Thus, the TrustedLen requirement on BuilderMethods::switch is redundant.
This is a template for splitting up `const_fn` into granular feature gates. I think this will make it easier, both for us and for users, to track stabilization of each individual feature. We don't *have* to do this, however. We could also keep stabilizing things out from under `const_fn`.
Rollup merge of #76631 - jyn514:x.py-setup, r=Mark-Simulacrum
Add `x.py setup`
Closes #76503.
- Suggest `x.py setup` if config.toml doesn't exist yet
- Prompt for a profile if not given on the command line
- Print the configuration that will be used
- Print helpful starting commands after setup
- Link to the dev-guide after finishing
Auto merge of #76176 - marmeladema:fix-closure-path-printing, r=eddyb
Move from {{closure}}#0 syntax to {closure#0} for (def) path components
Part of #70334
I followed the approach described by `@eddyb` and introduced a `DefPathDataName` enum.
To preserve compatibility, in various places, I had to rely on formatting manually by calling `format!("{{{{{}}}}}", namespace)`.
My questions are:
* Do we want to convert for places to use the new naming scheme? Or shall I re-add `DefPathData::as_symbol` but renamed as `DefPathData::as_legacy_symbol` to avoid manually allocating the legacy symbols?
* Do we want to `impl Display for DisambiguatedDefPathData` to avoid manually calling `write!(s, "{{{}#{}}}", namespace, component.disambiguator)`?
* We might also want to improve naming for `DefPathDataName` and `DefPathData::get_name`
Auto merge of #77198 - jonas-schievink:rollup-i59i41h, r=jonas-schievink
Rollup of 15 pull requests
Successful merges:
- #76932 (Relax promises about condition variable.)
- #76973 (Unstably allow assume intrinsic in const contexts)
- #77005 (BtreeMap: refactoring around edges)
- #77066 (Fix dest prop miscompilation around references)
- #77073 (dead_code: look at trait impls even if they don't contain items)
- #77086 (Include libunwind in the rust-src component.)
- #77097 (Make [].as_[mut_]ptr_range() (unstably) const.)
- #77106 (clarify that `changelog-seen = 1` goes to the beginning of config.toml)
- #77120 (Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts)
- #77126 (Invalidate local LLVM cache less often)
- #77146 (Install std for non-host targets)
- #77155 (remove enum name from ImplSource variants)
- #77176 (Removing erroneous semicolon in transmute documentation)
- #77183 (Allow multiple allow_internal_unstable attributes)
- #77189 (Remove extra space from vec drawing)
Matthew Jasper [Fri, 25 Sep 2020 18:48:24 +0000 (19:48 +0100)]
Rename Iterator::get_unchecked
It's possible for method resolution to pick this method over a lower
priority stable method, causing compilation errors. Since this method
is permanently unstable, give it a name that is very unlikely to be used
in user code.
Jonas Schievink [Fri, 25 Sep 2020 17:42:46 +0000 (19:42 +0200)]
Rollup merge of #77146 - Mark-Simulacrum:xpyinstall, r=alexcrichton
Install std for non-host targets
It seems reasonable that when configuring various targets you'd expect all of them to get std installed, even if you're not building compiler toolchains for each of those.
Jonas Schievink [Fri, 25 Sep 2020 17:42:44 +0000 (19:42 +0200)]
Rollup merge of #77126 - Mark-Simulacrum:llvm-less-often, r=alexcrichton
Invalidate local LLVM cache less often
This avoids a download of LLVM after every rebase. The downside to this is that if we land some patch affecting LLVM built in CI that breaks this option, but that PR does not update the LLVM submodule, we'll likely not notice until the next update -- but this seems unlikely to happen in practice and I am not personally worried about it.
Jonas Schievink [Fri, 25 Sep 2020 17:42:43 +0000 (19:42 +0200)]
Rollup merge of #77120 - ecstatic-morse:keep-stage-std, r=Mark-Simulacrum
Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts
Unlike `--keep-stage 0`, `--keep-stage-std 0` will allow the stage 0 compiler artifacts (i.e., stage1/bin/rustc) to be rebuilt if it has changed. This allows contributors to iterate on later stages of the compiler in tandem with the standard library without needing to to rebuild the entire compiler. I often run into this when working on const-checking, since I may need to add a feature gate or make a small tweak to the standard library.
Jonas Schievink [Fri, 25 Sep 2020 17:42:39 +0000 (19:42 +0200)]
Rollup merge of #77097 - fusion-engineering-forks:slice-ptr-range-const-fn, r=oli-obk
Make [].as_[mut_]ptr_range() (unstably) const.
Gated behind `const_ptr_offset`, as suggested by https://github.com/rust-lang/rust/issues/65807#issuecomment-697229404
This also marks `[].as_mut_ptr()` as const, because it's used by `as_mut_ptr_range`. I gated it behind the same feature, because I figured it's not worth adding a separate tracking issue for const `as_mut_ptr`.
Jonas Schievink [Fri, 25 Sep 2020 17:42:37 +0000 (19:42 +0200)]
Rollup merge of #77086 - ehuss:src-libunwind, r=Mark-Simulacrum
Include libunwind in the rust-src component.
Some targets, such as musl, need the libunwind source to build the unwind crate (referenced [here](https://github.com/rust-lang/rust/blob/0da58007451a154da2480160429e1604a1f5f0ec/library/unwind/build.rs#L142)).
Jonas Schievink [Fri, 25 Sep 2020 17:42:29 +0000 (19:42 +0200)]
Rollup merge of #76973 - lzutao:unstably-const-assume, r=oli-obk
Unstably allow assume intrinsic in const contexts
Not sure much about this usage because there are concerns
about [blocking optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic
in inline functions.
But since Oli suggested in https://github.com/rust-lang/rust/issues/76960#issuecomment-695772221,
here we are.
Jonas Schievink [Fri, 25 Sep 2020 17:42:28 +0000 (19:42 +0200)]
Rollup merge of #76932 - fusion-engineering-forks:condvar-promise, r=sfackler
Relax promises about condition variable.
For quite a while now, there have been plans to at some point use parking_lot or some other more efficient implementation of mutexes and condition variables. Right now, Mutex and CondVar both Box the 'real' mutex/condvar inside, to give it a stable address. This was done because implementations like pthread and Windows critical sections may not be moved. More efficient implementations based on futexes, WaitOnAddress, Windows SRW locks, parking_lot, etc. may be moved (while not borrowed), so wouldn't need boxing.
However, not boxing them (which would be great goal to achieve), breaks a promise std currently makes about CondVar. CondVar promises to panic when used with different mutexes, to ensure consistent behaviour on all platforms. To this check, a mutex is considered 'the same' if the address of the 'real mutex' in the Box is the same. This address doesn't change when moving a `std::mutex::Mutex` object, effectively giving it an identity that survives moves of the Mutex object. If we ever switch to a non-boxed version, they no longer carry such an identity, and this check can no longer be made.
Four options:
1. Always box mutexes.
2. Add a `MutexId` similar to `ThreadId`. Making mutexes bigger, and making it hard to ever have a `const fn new` for them.
3. Making the requirement of CondVar stricter: panic if the Mutex object itself moved.
4. Making the promise of CondVar weaker: don't promise to panic.
1, 2, and 3 seem like bad options. This PR updates the documentation for 4.
Put floating point arithmetic behind its own feature gate
This refactors handling of `Rvalue::{Unary,Binary}Op` in the
const-checker. Now we `span_bug` if there's an unexpected type in a
primitive operation. This also allows unary negation on
`char` values through the const-checker because it makes the code a bit
cleaner. `char` does not actually support these operations, and if it
did, we could evaluate them at compile-time.
Auto merge of #73453 - erikdesjardins:tuplayout, r=eddyb
Ignore ZST offsets when deciding whether to use Scalar/ScalarPair layout
This is important because Scalar/ScalarPair layout previously would not be used if any ZST had nonzero offset.
For example, before this change, only `((), u128)` would be laid out like `u128`, not `(u128, ())`.
projects / rust.git / log