Joshua Nelson [Sat, 2 Jul 2022 05:54:05 +0000 (00:54 -0500)]
Fix bug in `rustdoc -Whelp`
Previously, this printed the debugging options, not the lint options,
and only handled `-Whelp`, not `-A/-D/-F`.
This also fixes a few other misc issues:
- Fix `// check-stdout` for UI tests; previously it only worked for run-fail and compile-fail tests
- Add lint headers for tool lints, not just builtin lints
- Remove duplicate run-make test
Rollup merge of #98766 - lcnr:mir-visit-pass_by_value, r=oli-obk
cleanup mir visitor for `rustc::pass_by_value`
by changing `& $($mutability)?` to `$(& $mutability)?`
I also did some formatting changes because I started doing them for the visit methods I changed and then couldn't get myself to stop xx, I hope that's still fairly easy to review.
Rollup merge of #98497 - compiler-errors:span-inference-note, r=lcnr
Improve some inference diagnostics
- Properly point out point location where "type must be known at this point", or else omit the note if it's not associated with a useful span.
- Fix up some type ambiguity diagnostics, errors shouldn't say "cannot infer type for reference `&'a ()`" when the given type has no inference variables.
Rollup merge of #98418 - topjohnwu:macos-dylib, r=jyn514
Allow macOS to build LLVM as shared library
Inspired by how [homebrew](https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/llvm.rb) builds and distributes llvm, here we manually create a symlink with a versioned dylib path to make `llvm-config` work properly. Note, the resulting `rustc` executable and `librustc_driver-<hash>.dylib` still links to the un-versioned `libLLVM.dylib` as expected when distributed in the final output. I have confirmed this by checking `otool -L` on both binaries.
After the change, enabling `llvm.link-shared` and `llvm.thin-lto` will be possible on macOS.
Auto merge of #93967 - cjgillot:short-struct-span, r=petrochenkov
Shorten def_span for more items.
The `def_span` query only returns the signature span for functions.
Struct/enum/union definitions can also have a very long body.
This PR shortens the associated span.
Michael Howell [Fri, 1 Jul 2022 17:33:06 +0000 (10:33 -0700)]
rustdoc: use <details> tag for the source code sidebar
This fixes the extremely poor accessibility of the old system, making it
possible to navigate the sidebar by keyboard, and also implicitly gives the
sidebar items the correct ARIA roles.
Auto merge of #98767 - Dylan-DPC:rollup-j1gq5sr, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #97488 (Suggest blanket impl to the local traits)
- #98585 (Make `ThinBox<T>` covariant in `T`)
- #98644 (fix ICE with -Wrust-2021-incompatible-closure-captures)
- #98739 (fix grammar in useless doc comment lint)
- #98741 (Many small deriving cleanups)
- #98756 (Use const instead of function and make it private)
Rollup merge of #98585 - cuviper:covariant-thinbox, r=thomcc
Make `ThinBox<T>` covariant in `T`
Just like `Box<T>`, we want `ThinBox<T>` to be covariant in `T`, but the
projection in `WithHeader<<T as Pointee>::Metadata>` was making it
invariant. This is now hidden as `WithOpaqueHeader`, which we type-cast
whenever the real `WithHeader<H>` type is needed.
Fixes the problem noted in <https://github.com/rust-lang/rust/issues/92791#issuecomment-1104636249>.
Andy Fiddaman [Fri, 1 Jul 2022 13:21:18 +0000 (13:21 +0000)]
bootstrap: illumos platform flags for split-debuginfo
Bootstrap currently provides `-Zunstable-options` for platforms
when using split debuginfo - this commit adds it for the illumos
target too.
Auto merge of #98730 - matthiaskrgr:rollup-2c4d4x5, r=matthiaskrgr
Rollup of 10 pull requests
Successful merges:
- #97629 ([core] add `Exclusive` to sync)
- #98503 (fix data race in thread::scope)
- #98670 (llvm-wrapper: adapt for LLVMConstExtractValue removal)
- #98671 (Fix source sidebar bugs)
- #98677 (For diagnostic information of Boolean, remind it as use the type: 'bool')
- #98684 (add test for 72793)
- #98688 (interpret: add From<&MplaceTy> for PlaceTy)
- #98695 (use "or pattern")
- #98709 (Remove unneeded methods declaration for old web browsers)
- #98717 (get rid of tidy 'unnecessarily ignored' warnings)
Auto merge of #98752 - matthiaskrgr:rollup-uwimznc, r=matthiaskrgr
Rollup of 9 pull requests
Successful merges:
- #98610 (fix `emit_inference_failure_err` ICE)
- #98640 (Let rust-analyzer ship on stable, non-preview)
- #98686 (add ice test for 46511)
- #98727 (rustdoc: filter '_ lifetimes from ty::PolyTraitRef)
- #98729 (clarify that ExactSizeIterator::len returns the remaining length)
- #98733 (Request to be notified of MIR changes)
- #98734 (Update RELEASES.md)
- #98745 (Add a `--build-dir` flag to rustbuild)
- #98749 (Add macro_rules! rustdoc change to 1.62 relnotes)
The existing derive code allows for various possibilities that aren't
needed in practice, which complicates the code. There are only a few
auto-derived traits and new ones are unlikely, so this commit simplifies
things.
- `PtrTy` has been eliminated. The `Raw` variant was never used, and the
lifetime for the `Borrowed` variant was always `None`. That left just
the mutability field, which has been inlined as necessary.
- `MethodDef::explicit_self` was a confusing `Option<Option<PtrTy>>`.
Indicating either `&self` or nothing. It's now a `bool`.
- `borrowed_self` is renamed as `self_ref`.
- `Ty::Ptr` is renamed to `Ty::Ref`.
#96630 was tagged <kbd>relnotes</kbd> but didn't make it into the notes. Given this is a compatibility issue (https://github.com/rust-lang/rust/issues/97030, https://github.com/rust-lang/rust/issues/98735, https://github.com/rust-lang/rust/issues/98743), it probably *should* be retroactively added.
Rollup merge of #98745 - thomcc:build-dir-arg, r=jyn514
Add a `--build-dir` flag to rustbuild
This adds an optional `--build-dir <path>` flag to rustbuild (to both the python and rust code in src/bootstrap). If provided, it overrides build directory from the config file (if any was provided).
My reason for wanting this is that I often will make a change, save, and then go run `x.py check` or `x.py test` (or something). Because I've saved, vscode will start doing its thing in the background, but this will take the file lock, preventing `x.py` from running until vscode finishes whatever it's doing (since the manually invoked x.py won't be able to acquire said file lock). This is annoying, because I'd rather the command I explicitly invoke *not* wait for r-a to complete, as r-a's check is conceptually a background task (and one which can take quite some time to complete).
Anyway, while there are likely other ways this could be handled, if you have the disk space an easy way is to just have vscode be configured to use a different build directory, and then they never have to block each-other.
This can currently be arranged without this patch, by maintaining two `config.toml`s, one of which has a different build dir, and just exists to be passed into the overridden check command in vscode.
Unfortunately, this has the downside of requiring I maintain two `config.toml`s and keep them (at least somewhat) in sync, aside from the build dir. I dislike for several reasons, not the least of which because I know myself well enough to know that these will inevitably get out of sync and confuse me in the future (perhaps this case would be different since I've thought about it enough to write this patch? Who knows, I'd rather not find out).
Either way, it would be much easier for me to have a way for *only* the build directory to differ, which this patch provides by way of a new flag. I suggested this to `@jyn514` who indicated it sounded reasonable so long as it didn't add too much complexity, which I think I've achieved, but he can be the judge.
Anyway, with this patch I can just use something like `["python3", "x.py", "check", "--build-dir", "build-vscode", "--json-output"]` as the overridden check command to rust-analyzer, and do not need to futz with any additional `config.toml`s. Which is very nice!
I've tested this manually, and can confirm that it works. I'm not sure if it needs automated tests, or where I should add them if so.
r? `@jyn514` (who has had to put up with my complaints about this... many times. <3)
Rollup merge of #98640 - cuviper:stable-rust-analyzer, r=Mark-Simulacrum
Let rust-analyzer ship on stable, non-preview
The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method, e.g. the VS Code extension will probably still independently update to its weekly releases, but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component, and removes the "-preview" suffix as well by the usual renaming mechanism.
Optimize `Vec::insert` for the case where `index == len`.
By skipping the call to `copy` with a zero length. This makes it closer
to `push`.
I did this recently for `SmallVec`
(https://github.com/servo/rust-smallvec/pull/282) and it was a big perf win in
one case. Although I don't have a specific use case in mind, it seems
worth doing it for `Vec` as well.
Things to note:
- In the `index < len` case, the number of conditions checked is
unchanged.
- In the `index == len` case, the number of conditions checked increases
by one, but the more expensive zero-length copy is avoided.
- In the `index > len` case the code now reserves space for the extra
element before panicking. This seems like an unimportant change.
Wesley Wiser [Fri, 1 Oct 2021 01:58:49 +0000 (21:58 -0400)]
Don't assert polymorphization has taken effect in const eval
Const eval no longer runs MIR optimizations so unless this is getting
run as part of a MIR optimization like const-prop, there can be unused
type parameters even if polymorphization is enabled.
InfRandomness [Thu, 30 Jun 2022 18:14:46 +0000 (20:14 +0200)]
Revert #95993 fix
This reverts the temporary fix implemented by https://github.com/rust-lang/rust/pull/95993 since a permanent fix has been implemented by https://github.com/rust-lang/cargo/pull/10594
Matthias Krüger [Thu, 30 Jun 2022 17:55:57 +0000 (19:55 +0200)]
Rollup merge of #98717 - RalfJung:make-tidy-less-annoying, r=jyn514
get rid of tidy 'unnecessarily ignored' warnings
I think these warnings are quite pointless: when I say `allow(foo)` in my code, that doesn't necessarily mean that I expect `foo` to happen -- it just means that I am okay with `foo` happening.
For example, having to add and remove `ignore-tidy-linelength` as the longest line in the file keeps growing and shrinking is just annoying and doesn't benefit anyone, IMO. This usually incurs *two* CI roundtrips: first CI tells you that line lengths in your test file are ignored unnecessarily, so you go and remove that attribute; then CI tells you that now your line numbers changed, so you re-bless your tests (often takes >5min if parts of rustc need rebuilding because `./x.py fmt` changed something somewhere). That's just a lot of wasted effort and time and patience.
This adapts llvm-wrapper to use the new alternative where available, following https://rust-lang.zulipchat.com/#narrow/stream/187780-t-compiler.2Fwg-llvm/topic/LLVMConstExtractValue.20removal.
Matthias Krüger [Thu, 30 Jun 2022 17:55:51 +0000 (19:55 +0200)]
Rollup merge of #98503 - RalfJung:scope-race, r=m-ou-se
fix data race in thread::scope
Puts the `ScopeData` into an `Arc` so it sticks around as long as we need it.
This means one extra `Arc::clone` per spawned scoped thread, which I hope is fine.
`Exclusive` is a wrapper that exclusively allows mutable access to the inner value if you have exclusive access to the wrapper. It acts like a compile time mutex, and hold an unconditional `Sync` implementation.
## Justification for inclusion into std
- This wrapper unblocks actual problems:
- The example that I hit was a vector of `futures::future::BoxFuture`'s causing a central struct in a script to be non-`Sync`. To work around it, you either write really difficult code, or wrap the futures in a needless mutex.
- Easy to maintain: this struct is as simple as a wrapper can get, and its `Sync` implementation has very clear reasoning
- Fills a gap: `&/&mut` are to `RwLock` as `Exclusive` is to `Mutex`
## Public Api
```rust
// core::sync
#[derive(Default)]
struct Exclusive<T: ?Sized> { ... }
impl<T> From<T> for Exclusive<T> { ... }
impl<T: ?Sized> Debug for Exclusive { ... }
```
## Naming
This is a big bikeshed, but I felt that `Exclusive` captured its general purpose quite well.
## Stability and location
As this is so simple, it can be in `core`. I feel that it can be stabilized quite soon after it is merged, if the libs teams feels its reasonable to add. Also, I don't really know how unstable feature work in std/core's codebases, so I might need help fixing them
## Tips for review
The docs probably are the thing that needs to be reviewed! I tried my best, but I'm sure people have more experience than me writing docs for `Core`
### Implementation:
The API is mostly pulled from https://docs.rs/sync_wrapper/latest/sync_wrapper/struct.SyncWrapper.html (which is apache 2.0 licenesed), and the implementation is trivial:
- its an unsafe justification for pinning
- its an unsafe justification for the `Sync` impl (mostly reasoned about by ````@danielhenrymantilla```` here: https://github.com/Actyx/sync_wrapper/pull/2)
- and forwarding impls, starting with derivable ones and `Future`