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)
#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.
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`
Yiming Lei [Wed, 29 Jun 2022 16:09:34 +0000 (09:09 -0700)]
For diagnostic information of Boolean, remind it as use the type: 'bool'
It helps programmers coming from other languages
modified: compiler/rustc_resolve/src/late/diagnostics.rs
bors [Thu, 30 Jun 2022 09:20:52 +0000 (09:20 +0000)]
Auto merge of #98377 - davidv1992:add-lifetimes-to-argument-temporaries, r=oli-obk
Added llvm lifetime annotations to function call argument temporaries.
The goal of this change is to ensure that llvm will do stack slot
optimization on these temporaries. This ensures that in code like:
```rust
const A: [u8; 1024] = [0; 1024];
fn copy_const() {
f(A);
f(A);
}
```
we only use 1024 bytes of stack space, instead of 2048 bytes.
I am new to developing for the rust compiler, and as such not entirely sure, but I believe this should be sufficient to close #98156.
Also, this does not contain a test case to ensure this keeps working, primarily because I am not sure how to go about testing this. I would love some suggestions as to how that could be approached.
bors [Thu, 30 Jun 2022 04:04:08 +0000 (04:04 +0000)]
Auto merge of #8666 - Jarcho:while_let_loop_7913, r=dswij
Don't lint `while_let_loop` when significant drop order would change
fixes #7226
fixes #7913
fixes #5717
For #5717 it may not stay fully fixed. This is only completely fixed right now due to all the allowed drop impls have `#[may_dangle]` on their drop impls. This may get changed in the future based on how significant drops are determined, but the example listed with `RefCell` shouldn't break.
changelog: Don't lint `while_let_loop` when the order of significant drops would change
bors [Thu, 30 Jun 2022 03:50:35 +0000 (03:50 +0000)]
Auto merge of #98649 - RalfJung:guardians-of-mir, r=oli-obk
move MIR syntax into a dedicated file and ping some people whenever it changes
Adding or changing MIR operations/statements/whatever should be under significant scrutiny wrt their wider impact, specified semantics, and so on. So let's start by putting all that into a dedicated file and pinging some people whenever that file changes.
This PR only moves definitions around, and then fiddles with imports until it all works again.
bors [Thu, 30 Jun 2022 01:02:24 +0000 (01:02 +0000)]
Auto merge of #98691 - matthiaskrgr:rollup-ymsa64p, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #96727 (Make TAIT behave exactly like RPIT)
- #98681 (rustdoc-json: Make default value of blanket impl assoc types work)
- #98682 (add tests for ICE 94432)
- #98683 (add test for ice 68875)
- #98685 (Replace `sort_modules_alphabetically` boolean with enum)
- #98687 (add test for 47814)
Matthias Krüger [Wed, 29 Jun 2022 22:23:54 +0000 (00:23 +0200)]
Rollup merge of #98685 - camelid:sorting-flag, r=GuillaumeGomez
Replace `sort_modules_alphabetically` boolean with enum
This fixes the long-standing FIXME there and makes the code easier to
understand. The reference to modules in both the old and new names seems
potentially wrong since I believe it applies to all items.
This makes type-alias-impl-trait behave like return-position-impl-trait. Unfortunately it also causes some cases to stop compiling due to "needing type annotations" and makes panicking cause fallback for the hidden type to `()`.
All of these are addressable, but we should probably address them for RPIT and TAIT together
Noah Lev [Wed, 29 Jun 2022 20:04:43 +0000 (13:04 -0700)]
Replace `sort_modules_alphabetically` boolean with enum
This fixes the long-standing FIXME there and makes the code easier to
understand. The reference to modules in both the old and new names seems
potentially wrong since I believe it applies to all items.
bors [Wed, 29 Jun 2022 18:42:19 +0000 (18:42 +0000)]
Auto merge of #98680 - matthiaskrgr:rollup-1bkrrn9, r=matthiaskrgr
Rollup of 10 pull requests
Successful merges:
- #98434 (Ensure that `static_crt` is set in the bootstrapper whenever using `cc-rs` to get a compiler command line.)
- #98636 (Triagebot: Fix mentions word wrapping.)
- #98642 (Fix #98260)
- #98643 (Improve pretty printing of valtrees for references)
- #98646 (rustdoc: fix bugs in main.js popover help and settings)
- #98647 (Update cargo)
- #98652 (`alloc`: clean and ensure `no_global_oom_handling` builds are warning-free)
- #98660 (Unbreak stage1 tests via ignore-stage1 in `proc-macro/invalid-punct-ident-1.rs`.)
- #98665 (Use verbose help for deprecation suggestion)
- #98668 (Avoid some `&str` to `String` conversions with `MultiSpan::push_span_label`)
Matthias Krüger [Wed, 29 Jun 2022 18:35:05 +0000 (20:35 +0200)]
Rollup merge of #98660 - eddyb:invalid-punct-stage1, r=lqd
Unbreak stage1 tests via ignore-stage1 in `proc-macro/invalid-punct-ident-1.rs`.
#98188 broke `./x.py test --stage 1` (which I thought we ran in PR CI, cc `@rust-lang/infra)` i.e. the default `./x.py test` in dev checkouts, as the panic in `src/test/ui/proc-macro/invalid-punct-ident-1.rs` moved from the server (`rustc`) to the client (proc macro), and that means it's now affected by #59998.
I made the test look like `src/test/ui-fulldeps/issue-76270-panic-in-libproc-macro.rs` tho I'm a bit confused why that one is in `src/test/ui-fulldeps`, it should still work in `src/test/ui`, no? (cc `@Aaron1011)`
warning: associated function `shrink` is never used
--> library/alloc/src/raw_vec.rs:424:8
|
424 | fn shrink(&mut self, cap: usize) -> Result<(), TryReserveError> {
| ^^^^^^
|
= note: `#[warn(dead_code)]` on by default
warning: associated function `forget_remaining_elements` is never used
--> library/alloc/src/vec/into_iter.rs:126:19
|
126 | pub(crate) fn forget_remaining_elements(&mut self) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^
```
</details>
This PR cleans them and ensures no new ones are introduced
so that projects compiling `alloc` without infallible allocations
do not see them (and may want to enable `-Dwarnings`).
The couple `dead_code` ones may be reverted when some fallible
allocation support starts using them.
Matthias Krüger [Wed, 29 Jun 2022 18:34:59 +0000 (20:34 +0200)]
Rollup merge of #98636 - ehuss:mentions-wrapping, r=Mark-Simulacrum
Triagebot: Fix mentions word wrapping.
I forgot that GitHub's markdown treats newlines as hard breaks. This was causing some ugly-looking word wrapping in the triagebot mention messages. This fixes it so that the lines are not hard-wrapped.
Dylan DPC [Wed, 29 Jun 2022 12:29:37 +0000 (17:59 +0530)]
Rollup merge of #98625 - RalfJung:retag, r=oli-obk
emit Retag for compound types with reference fields
I want to add an option to Miri to do retagging inside reference fields. But that means we first have to even emit `Retag` for types that *contain* references (rather than being of reference types). :)
Stacked Borrows originally did that, but we stopped doing it when hitting bunch of issues in the standard library. However I have since realized that we actually do emit `noalias` for newtypes references, which means for soundness we should recurse into fields. Also it'd probably be bad news if newtypes lose out on optimizations (and they don't, for anything else). I want to add an option for that to Miri so that we can start experimenting with those semantics.
Dylan DPC [Wed, 29 Jun 2022 12:29:36 +0000 (17:59 +0530)]
Rollup merge of #98607 - compiler-errors:tuple-wrap-suggestion, r=oli-obk
Clean up arg mismatch diagnostic, generalize tuple wrap suggestion
This is based on top of #97542, so just look at the last commit which contains the relevant changes.
1. Remove `final_arg_types` which was one of the last places we were using raw (`usize`) indices instead of typed indices in the arg mismatch suggestion code.
2. Improve the tuple wrap suggestion, now we suggest things like `call(a, b, c, d)` -> `call(a, (b, c), d)` :smiley_cat:
3. Folded in fix #98645
projects / rust.git / log