bors [Mon, 9 Jan 2023 13:47:46 +0000 (13:47 +0000)]
Auto merge of #13816 - WaffleLapkin:postfix_adjustment_hints, r=Veykril
Postfix adjustment hints
# Basic Description
This PR implements "postfix" adjustment hints:
They are identical to normal adjustment hints, but are rendered _after_ the expression. E.g. `expr.*` instead of `*expr`. ~~This mirrors "postfix deref" feature that I'm planning to eventually propose to the compiler.~~
# Motivation
The advantage of being postfix is that you need to add parentheses less often:
This is because a lot of "reborrow" hints are caused by field access or method calls, both of which are postfix and have higher "precedence" than prefix `&` and `*`.
Also IMHO it just looks nicer and it's more clear what is happening (order of operations).
# Modes
However, there are some cases where postfix hints need parentheses but prefix don't (for example `&x` being turned into `(&x).*.*.&` or `&**&x`).
This PR allows users to choose which look they like more. There are 4 options (`rust-analyzer.inlayHints.expressionAdjustmentHints.mode` setting):
- `prefix` — always use prefix hints (default, what was used before that PR)
- `postfix` — always use postfix hints
- `prefer_prefix` — try to minimize number of parentheses, breaking ties in favor of prefix
- `prefer_postfix` — try to minimize number of parentheses, breaking ties in favor of postfix
Here `.&` is a hint and `?` is written in the source code. It looks like `?` is part of the hint because `?.` is ligature in my font. IMO this is a bug in vscode, but still worth mentioning (I'm also too lazy to report it there...).
# Fixed bugs
I've used the "needs parens" API and this accidentally fixed a bug with parens around `as`, see the test diff:
```diff,rust
let _: *const u32 = &mut 0u32 as *mut u32;
//^^^^^^^^^^^^^^^^^^^^^<mut-ptr-to-const-ptr>
+ //^^^^^^^^^^^^^^^^^^^^^(
+ //^^^^^^^^^^^^^^^^^^^^^)
...
let _: *const u32 = &mut 0u32 as *mut u32;
//^^^^^^^^^^^^^^^^^^^^^<mut-ptr-to-const-ptr>
+ //^^^^^^^^^^^^^^^^^^^^^(
+ //^^^^^^^^^^^^^^^^^^^^^)
```
# Changelog
changelog feature Add an option to make adjustment hints (aka reborrow hints) postfix
changelog fix Fix placement of parentheses around `as` casts for adjustment hints
bors [Mon, 9 Jan 2023 13:34:51 +0000 (13:34 +0000)]
Auto merge of #13843 - Overpeek:master, r=Veykril
fix: generate async delegate methods
Fixes a bug where the generated async method doesn't await the result before returning it.
This is an example of what the output looked like:
```rust
struct Age<T>(T);
impl<T> Age<T> {
pub(crate) async fn age<J, 'a>(&'a mut self, ty: T, arg: J) -> T {
self.0
}
}
struct Person<T> {
age: Age<T>,
}
impl<T> Person<T> {
pub(crate) async fn age<J, 'a>(&'a mut self, ty: T, arg: J) -> T {
self.age.age(ty, arg) // .await is missing
}
}
```
The `.await` is missing, so the return type is `impl Future<Output = T>` instead of `T`
Initially, I thought I would need to enable operand propagation then do something else, but actually https://github.com/rust-lang/rust/pull/74491 already has the fix for the issue in question! It looks like this optimization was put under MIR opt level 3 due to possible soundness/stability implications, then demoted further to MIR opt level 4 when MIR opt level 2 became associated with `--release`.
Perhaps in the past we were doing CTFE on optimized MIR? We aren't anymore, so this optimization has no stability implications.
bors [Mon, 9 Jan 2023 11:53:23 +0000 (11:53 +0000)]
Auto merge of #13744 - vtta:numthreads, r=Veykril
feat: add the ability to limit the number of threads launched by `main_loop`
## Motivation
`main_loop` defaults to launch as many threads as cpus in one machine. When developing on multi-core remote servers on multiple projects, this will lead to thousands of idle threads being created. This is very annoying when one wants check whether his program under developing is running correctly via `htop`.
## Contribution
This patch introduce the configuration option `rust-analyzer.numThreads` to set the desired thread number used by the main thread pool.
This should have no effects on the performance as not all threads are actually used.
<img width="1325" alt="image" src="https://user-images.githubusercontent.com/41831480/206656834-fe625c4c-b993-4771-8a82-7427c297fd41.png">
## Demonstration
The following is a snippet of `lunarvim` configuration using my own build.
```lua
vim.list_extend(lvim.lsp.automatic_configuration.skipped_servers, { "rust_analyzer" })
require("lvim.lsp.manager").setup("rust_analyzer", {
cmd = { "env", "RA_LOG=debug", "RA_LOG_FILE=/tmp/ra-test.log",
"/home/jlhu/Projects/rust-analyzer/target/debug/rust-analyzer",
},
init_options = {
numThreads = 4,
},
settings = {
cachePriming = {
numThreads = 8,
},
},
})
```
## Limitations
The `numThreads` can only be modified via `initializationOptions` in early initialisation because everything has to wait until the thread pool starts including the dynamic settings modification support.
The `numThreads` also does not reflect the end results of how many threads is actually created, because I have not yet tracked down everything that spawns threads.
bors [Mon, 9 Jan 2023 11:40:48 +0000 (11:40 +0000)]
Auto merge of #13684 - unvalley:extract-expressions-from-format-string, r=Veykril
feat: extract_expressions_from_format_string
closes #13640
- rename to `extract_expressions_from_format_string`
- leave identifier from format string
- but this is from rustc version 1.65.0
- Should I add flag or something?
Note: the assist behaves below cases for now. I'll create an issue for these.
```rs
let var = 1 + 1;
// ok
format!("{var} {1+1}"); // → format!("{var} {}", 1+1);
format!("{var:?} {1+1}"); // → format!("{var:?} {}", 1 + 1);
format!("{var} {var} {1+1}"); // → format!("{var} {var} {}", 1 + 1);
bors [Mon, 9 Jan 2023 11:24:44 +0000 (11:24 +0000)]
Auto merge of #13458 - cameron1024:suggest-checked-wrapping-saturating, r=Veykril
add wrapping/checked/saturating assist
This addresses #13452
I'm not sure about the structure of the code. I'm not sure if it needs to be 3 separate assists, and if that means it needs to be in 3 separate files as well.
Most of the logic is in `util.rs`, which feels funny to me, but there seems to be a pattern of 1 assist per file, and this seems better than duplicating the logic.
bors [Mon, 9 Jan 2023 10:37:46 +0000 (10:37 +0000)]
Auto merge of #13905 - rust-lang:dependabot/npm_and_yarn/editors/code/d3-color-and-d3-graphviz-3.1.0, r=Veykril
Bump d3-color and d3-graphviz in /editors/code
Bumps [d3-color](https://github.com/d3/d3-color) to 3.1.0 and updates ancestor dependency [d3-graphviz](https://github.com/magjac/d3-graphviz). These dependencies need to be updated together.
Updates `d3-graphviz` from 4.1.1 to 5.0.2
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/magjac/d3-graphviz/releases">d3-graphviz's releases</a>.</em></p>
<blockquote>
<h2>v5.0.2</h2>
<p>See the <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md#502">CHANGELOG</a> for details.</p>
<h2>v5.0.1</h2>
<p>See the <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md#501">CHANGELOG</a> for details.</p>
<h2>v5.0.0</h2>
<p>See the <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md#500">CHANGELOG</a> for details.</p>
<h2>v4.5.0</h2>
<p>See the <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md#450">CHANGELOG</a> for details.</p>
<h2>v4.4.0</h2>
<p>See the <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md#440">CHANGELOG</a> for details.</p>
<h2>v4.3.0</h2>
<p>See the <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md#430">CHANGELOG</a> for details.</p>
<h2>v4.2.0</h2>
<p>See the <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md#420">CHANGELOG</a> for details.</p>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md">d3-graphviz's changelog</a>.</em></p>
<blockquote>
<h2>[5.0.2] – 2022-12-27</h2>
<h3>Fixed</h3>
<ul>
<li>Failed to resolve entry for package "d3-graphviz" <a href="https://github-redirect.dependabot.com/magjac/d3-graphviz/issues/263">#263</a></li>
</ul>
<h2>[5.0.1] – 2022-12-27</h2>
<h3>Fixed</h3>
<ul>
<li>Failed to resolve entry for package "d3-graphviz" (partial fix) <a href="https://github-redirect.dependabot.com/magjac/d3-graphviz/issues/263">#263</a></li>
</ul>
<h2>[5.0.0] – 2022-12-26</h2>
<p><strong>Note:</strong> This release contains breaking changes compared to version 4.5.0.</p>
<h3>Changed</h3>
<ul>
<li>Like <a href="https://github.com/d3/d3/blob/main/CHANGES.md#changes-in-d3-70">D3
v7</a>,
d3-graphviz now ships as a pure ES module and requires Node.js 14 or
higher. This is a <strong>breaking change</strong>. For more, please read <a href="https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c">Sindre
Sorhus’s
FAQ</a>. For
background and details, see <a href="https://github-redirect.dependabot.com/d3/d3/issues/3469">this D3
issue</a>.</li>
<li>Upgrade to <a href="https://github.com/d3/d3/blob/main/CHANGES.md#changes-in-d3-70">D3 version
7</a>
(version 3 of its
<a href="https://github.com/d3/d3#installing">microlibraries</a>).</li>
<li>Upgrade <code>`@hpcc-js/wasm</code>` to 2.5.0 (Graphviz 7.0.5)</li>
</ul>
<h2>[4.5.0] – 2022-12-11</h2>
<h3>Changed</h3>
<ul>
<li>Upgrade <code>`@hpcc-js/wasm</code>` to 1.16.6 (Graphviz 7.0.1)</li>
</ul>
<h2>[4.4.0] – 2022-09-12</h2>
<h3>Changed</h3>
<ul>
<li>Upgrade <code>`@hpcc-js/wasm</code>` to 1.16.1 (Graphviz 6.0.1)</li>
</ul>
<h2>[4.3.0] – 2022-09-10</h2>
<h3>Changed</h3>
<ul>
<li>Upgrade <code>`@hpcc-js/wasm</code>` to 1.15.7 (Graphviz unchanged at 5.0.1) (thanks <a href="https://github.com/mrdrogdrog"><code>`@mrdrogdrog</code></a>)</li>`
</ul>
<h2>[4.2.0] – 2022-09-06</h2>
<h3>Changed</h3>
<ul>
<li>Upgrade Graphviz to version 5.0.1 through <code>`@hpcc-js/wasm</code>` version 1.15.4 (thanks <a href="https://github.com/mrdrogdrog"><code>`@mrdrogdrog</code></a>)</li>`
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/magjac/d3-graphviz/commit/21a1f57612ec94fde0a37bdd4b23af0cfd257c96"><code>21a1f57</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/magjac/d3-graphviz/issues/268">#268</a> from magjac/release-5.0.2</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/3c96187ad3f50c3b0e90a203fabc708485fdd159"><code>3c96187</code></a> add version 5.0.2 to CHANGELOG</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/82c34adb337cfc278cab0804bac86b8b0e904af6"><code>82c34ad</code></a> update version to 5.0.2</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/493e14927c7a76c1ec80e601b064a21053eb3495"><code>493e149</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/magjac/d3-graphviz/issues/267">#267</a> from magjac/fix-main-module-exports-in-package-json-a...</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/1903eea4e55c3d40edf9f520a528d9a651dd04b4"><code>1903eea</code></a> add simple-default-export-test.js</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/ccd6b90f36f5be92568ccaa2ea2ab96073579e5b"><code>ccd6b90</code></a> correct default export in package.json</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/d32e81cbfb05df87fb0bf72f892fc184482f9775"><code>d32e81c</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/magjac/d3-graphviz/issues/266">#266</a> from magjac/release-5.0.1</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/d0651e56ec668faddacde490758a1c638fe7e495"><code>d0651e5</code></a> add version 5.0.1 to CHANGELOG</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/0c06f6246be1491fc60f75ba4ac82a40bcfeffa2"><code>0c06f62</code></a> update version to 5.0.1</li>
<li><a href="https://github.com/magjac/d3-graphviz/commit/2df0d3a66f421b6c3aaf7f02646b616c518781c9"><code>2df0d3a</code></a> Merge pull request <a href="https://github-redirect.dependabot.com/magjac/d3-graphviz/issues/265">#265</a> from magjac/fix-main-module-exports-in-package-json</li>
<li>Additional commits viewable in <a href="https://github.com/magjac/d3-graphviz/compare/v4.1.1...v5.0.2">compare view</a></li>
</ul>
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting ``@dependabot` rebase`.
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- ``@dependabot` rebase` will rebase this PR
- ``@dependabot` recreate` will recreate this PR, overwriting any edits that have been made to it
- ``@dependabot` merge` will merge this PR after your CI passes on it
- ``@dependabot` squash and merge` will squash and merge this PR after your CI passes on it
- ``@dependabot` cancel merge` will cancel a previously requested merge and block automerging
- ``@dependabot` reopen` will reopen this PR if it is closed
- ``@dependabot` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` use these labels` will set the current labels as the default for future PRs for this repo and language
- ``@dependabot` use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- ``@dependabot` use these assignees` will set the current assignees as the default for future PRs for this repo and language
- ``@dependabot` use this milestone` will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/rust-lang/rust-analyzer/network/alerts).
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting ``@dependabot` rebase`.
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- ``@dependabot` rebase` will rebase this PR
- ``@dependabot` recreate` will recreate this PR, overwriting any edits that have been made to it
- ``@dependabot` merge` will merge this PR after your CI passes on it
- ``@dependabot` squash and merge` will squash and merge this PR after your CI passes on it
- ``@dependabot` cancel merge` will cancel a previously requested merge and block automerging
- ``@dependabot` reopen` will reopen this PR if it is closed
- ``@dependabot` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` use these labels` will set the current labels as the default for future PRs for this repo and language
- ``@dependabot` use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- ``@dependabot` use these assignees` will set the current assignees as the default for future PRs for this repo and language
- ``@dependabot` use this milestone` will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/rust-lang/miri/network/alerts).
kadmin [Wed, 21 Dec 2022 21:53:52 +0000 (21:53 +0000)]
Clean up
Simplify match statement
Add multiple tests
- 1 test for checking `N + 1 + 1` does not unify with `N+1`
- 2 tests for checking that a function that uses two parameters only returns the parameter that
is actually used.
- Check exact repeat predicates
kadmin [Tue, 13 Dec 2022 09:51:13 +0000 (09:51 +0000)]
Change based on comments
Instead of just switching to a probe, check for different matches, and see how many there are.
If one, unify it, otherwise return true and let it be unified later.
bors [Mon, 9 Jan 2023 05:09:45 +0000 (05:09 +0000)]
Auto merge of #106616 - compiler-errors:rollup-emcj0o3, r=compiler-errors
Rollup of 8 pull requests
Successful merges:
- #104163 (Don't derive Debug for `OnceWith` & `RepeatWith`)
- #106131 (Mention "signature" rather than "fn pointer" when impl/trait methods are incompatible)
- #106363 (Structured suggestion for `&mut dyn Iterator` when possible)
- #106497 (Suggest using clone when we have &T and T implemented Clone)
- #106584 (Document that `Vec::from_raw_parts[_in]` must be given a pointer from the correct allocator.)
- #106600 (Suppress type errors that come from private fields)
- #106602 (Add goml scripts to tidy checks)
- #106606 (Do not emit structured suggestion for turbofish with wrong span)
Michael Goulet [Mon, 9 Jan 2023 03:57:55 +0000 (19:57 -0800)]
Rollup merge of #106600 - compiler-errors:no-private-field-ty-err, r=estebank
Suppress type errors that come from private fields
Fixes #57320
There was some discussion here (https://github.com/rust-lang/rust/issues/57320#issuecomment-451308420), but I honestly think the second error is worth suppressing regardless.
I would be open to feedback though -- perhaps we can suppress the `.len()` suggestion if there's type error (since we have access to [`Expectation`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/enum.Expectation.html), we can determine that).
Michael Goulet [Mon, 9 Jan 2023 03:57:54 +0000 (19:57 -0800)]
Rollup merge of #106584 - kpreid:vec-allocator, r=JohnTitor
Document that `Vec::from_raw_parts[_in]` must be given a pointer from the correct allocator.
Currently, the documentation of `Vec::from_raw_parts` and `Vec::from_raw_parts_in` says nothing about what allocator the pointer must come from. This PR adds that missing information explicitly.
Michael Goulet [Mon, 9 Jan 2023 03:57:52 +0000 (19:57 -0800)]
Rollup merge of #104163 - H4x5:once-repeat-with-debug, r=dtolnay
Don't derive Debug for `OnceWith` & `RepeatWith`
Closures don't impl Debug, so the derived impl is kinda useless. The behavior of not debug-printing closures is consistent with the rest of the iterator adapters/sources.
bors [Sun, 8 Jan 2023 22:40:38 +0000 (22:40 +0000)]
Auto merge of #90291 - geeklint:loosen_weak_debug_bound, r=dtolnay
Loosen the bound on the Debug implementation of Weak.
Both `rc::Weak<T>` and `sync::Weak<T>` currently require `T: Debug` in their own `Debug` implementations, but they don't currently use it; they only ever print a fixed string.
A general implementation of Debug for Weak that actually attempts to upgrade and rely on the contents is unlikely in the future because it may have unbounded recursion in the presence of reference cycles, which Weak is commonly used in. (This was the justification for why the current implementation [was implemented the way it is](https://github.com/rust-lang/rust/pull/19388/commits/f0976e2cf3f6b0027f118b791e0888b29fbb41a7)).
When I brought it up [on the forum](https://internals.rust-lang.org/t/could-the-bound-on-weak-debug-be-relaxed/15504), it was suggested that, even if an implementation is specialized in the future that relies on the data stored within the Weak, it would likely rely on specialization anyway, and could therefore easily specialize on the Debug bound as well.
bors [Sun, 8 Jan 2023 17:49:31 +0000 (17:49 +0000)]
Auto merge of #106449 - GuillaumeGomez:rustdoc-gui-retry-mechanism, r=Mark-Simulacrum
Add retry mechanism for rustdoc GUI tests to reduce flakyness
Part of #93784.
I added 3 retries for failing GUI tests. An important note: if more than half of total tests fail, I don't retry because it's very likely not flakyness anymore at this point but a missing update after changes.
bors [Sun, 8 Jan 2023 14:40:52 +0000 (14:40 +0000)]
Auto merge of #106235 - compiler-errors:rework-bounds-collection, r=davidtwco
Rework `Bounds` collection
I think it's weird for the `Bounds` struct in astconv to store its predicates *almost* converted into real predicates... so we do this eagerly, instead of lazily.
Yuki Okushi [Sun, 8 Jan 2023 08:01:49 +0000 (17:01 +0900)]
Rollup merge of #106580 - Ezrashaw:remove-e0313, r=compiler-errors
remove unreachable error code `E0313`
Fixes #103742
Makes #103433 redundant
Implements removal of `E0313`. I agree with the linked issue that this error code is unreachable but if someone could confirm that would be great, are crater runs done for this sort of thing?
Also removed a redundant `// ignore-tidy-filelength` that I found while reading code.
Yuki Okushi [Sun, 8 Jan 2023 08:01:48 +0000 (17:01 +0900)]
Rollup merge of #106557 - Ezrashaw:ui-test-fixups-1, r=GuillaumeGomez
Add some UI tests and reword error-code docs
Added UI tests for `E0013` and `E0015`. Error code docs for `E0015` were a bit unclear (they referred to all non-const errors in const context, when only non-const functions applied), so I touched them up a bit.
I also fixed up some issues in the new `error_codes.rs` tidy check (linked #106341), that I overlooked previously.
Yuki Okushi [Sun, 8 Jan 2023 08:01:46 +0000 (17:01 +0900)]
Rollup merge of #106410 - clubby789:borrow-mut-self-mut-self-diag, r=compiler-errors
Suggest `mut self: &mut Self` for `?Sized` impls
Closes #106325
Closes #93078
The suggestion is _probably_ not what the user wants (hence `MaybeIncorrect`) but at least makes the problem in the above issues clearer. It might be better to add a note explaining why this is the case, but I'm not sure how best to word that so this is a start.
bors [Sun, 8 Jan 2023 01:34:05 +0000 (01:34 +0000)]
Auto merge of #104658 - thomcc:rand-update-and-usable-no_std, r=Mark-Simulacrum
Update `rand` in the stdlib tests, and remove the `getrandom` feature from it.
The main goal is actually removing `getrandom`, so that eventually we can allow running the stdlib test suite on tier3 targets which don't have `getrandom` support. Currently those targets can only run the subset of stdlib tests that exist in uitests, and (generally speaking), we prefer not to test libstd functionality in uitests, which came up recently in https://github.com/rust-lang/rust/pull/104095 and https://github.com/rust-lang/rust/pull/104185. Additionally, the fact that we can't update `rand`/`getrandom` means we're stuck with the old set of tier3 targets, so can't test new ones.
~~Anyway, I haven't checked that this actually does allow use on tier3 targets (I think it does not, as some work is needed in stdlib submodules) but it moves us slightly closer to this, and seems to allow at least finally updating our `rand` dep, which definitely improves the status quo.~~ Checked and works now.
For the most part, our tests and benchmarks are fine using hard-coded seeds. A couple tests seem to fail with this (stuff manipulating the environment expecting no collisions, for example), or become pointless (all inputs to a function become equivalent). In these cases I've done a (gross) dance (ab)using `RandomState` and `Location::caller()` for some extra "entropy".
Trying to share that code seems *way* more painful than it's worth given that the duplication is a 7-line function, even if the lines are quite gross. (Keeping in mind that sharing it would require adding `rand` as a non-dev dep to std, and exposing a type from it publicly, all of which sounds truly awful, even if done behind a perma-unstable feature).
See also some previous attempts:
- https://github.com/rust-lang/rust/pull/86963 (in particular https://github.com/rust-lang/rust/pull/86963#issuecomment-885438936 which explains why this is non-trivial)
- https://github.com/rust-lang/rust/pull/89131
- https://github.com/rust-lang/rust/pull/96626#issuecomment-1114562857 (I tried in that PR at the same time, but settled for just removing the usage of `thread_rng()` from the benchmarks, since that was the main goal).
- https://github.com/rust-lang/rust/pull/104185
- Probably more. It's very tempting of a thing to "just update".
Matthias Krüger [Sat, 7 Jan 2023 19:43:23 +0000 (20:43 +0100)]
Rollup merge of #106556 - notriddle:notriddle/margin-left-content-mobile, r=GuillaumeGomez
rustdoc: remove no-op mobile CSS `.content { margin-left: 0 }`
This rule was added to override non-zero left margin on `.content`, which was removed in 135281ed1525db15edd8ebd092aa10aa40df2386 and the margin-left was put on the docblock.
Matthias Krüger [Sat, 7 Jan 2023 19:43:21 +0000 (20:43 +0100)]
Rollup merge of #105859 - compiler-errors:hr-lifetime-add, r=davidtwco
Point out span where we could introduce higher-ranked lifetime
Somewhat addresses #105422, but not really. We don't have that much useful information here since we're still in resolution :^(
Maybe this suggestion isn't worth it. If the reviewer has an idea how we can get a more succinct binder information for a structured suggestion, it would be appreciated.
Matthias Krüger [Sat, 7 Jan 2023 19:43:20 +0000 (20:43 +0100)]
Rollup merge of #105517 - pcc:process-panic-after-fork, r=davidtwco
Fix process-panic-after-fork.rs to pass on newer versions of Android.
The test process-panic-after-fork.rs was checking that abort() resulted in SIGSEGV on Android. This non-standard behavior was fixed back in 2013, so let's fix the test to also accept the standard behavior on Android.
Matthias Krüger [Sat, 7 Jan 2023 19:43:19 +0000 (20:43 +0100)]
Rollup merge of #104543 - JhonnyBillM:migrate-codegen-ssa-to-diagnostics-structs-pt3, r=davidtwco
Migrate `codegen_ssa` to diagnostics structs - [Part 3]
Completes migrating `codegen_ssa` module except 2 outstanding errors that depend on other crates:
1. [`rustc_middle::mir::interpret::InterpError`](https://github.com/rust-lang/rust/blob/b6097f2e1b2ca62e188ba53cf43bd66b06b36915/compiler/rustc_middle/src/mir/interpret/error.rs#L475): I saw `rustc_middle` is unassigned, I am open to take this work.
2. `codegen_llvm`'s use of `fn span_invalid_monomorphization_error`, which I started to replace in the [last commit](https://github.com/rust-lang/rust/commit/9a31b3cdda78a2c0891828254fe9886e0a1cfd16) of this PR, but would like to know the team's preference on how we should keep replacing the other macros:
2.1. Update macros to expect a `Diagnostic`
2.2. Remove macros and expand the code on each use.
See [some examples of the different options in this experimental commit](https://github.com/JhonnyBillM/rust/commit/64aee83e80857dcfa450f0c6e31d5f29c6d577e6)
Matthias Krüger [Sat, 7 Jan 2023 19:43:18 +0000 (20:43 +0100)]
Rollup merge of #101936 - IntQuant:issue-100717-infer-4, r=compiler-errors
Migrating rustc_infer to session diagnostics (part 3)
``@rustbot`` label +A-translation
r? rust-lang/diagnostics
cc https://github.com/rust-lang/rust/issues/100717
Seems like a part of static_impl_trait.rs emits suggestions in a loop, and note.rs needs to have two instances of the same subdiagnostic, so these will need to wait until we have eager translation/list support.
Other than that, there is only error_reporting/mod.rs left to migrate.
dependabot[bot] [Sat, 7 Jan 2023 19:20:08 +0000 (19:20 +0000)]
Bump d3-color and d3-graphviz in /editors/code
Bumps [d3-color](https://github.com/d3/d3-color) to 3.1.0 and updates ancestor dependency [d3-graphviz](https://github.com/magjac/d3-graphviz). These dependencies need to be updated together.
Updates `d3-color` from 2.0.0 to 3.1.0
- [Release notes](https://github.com/d3/d3-color/releases)
- [Commits](https://github.com/d3/d3-color/compare/v2.0.0...v3.1.0)
Updates `d3-graphviz` from 4.1.1 to 5.0.2
- [Release notes](https://github.com/magjac/d3-graphviz/releases)
- [Changelog](https://github.com/magjac/d3-graphviz/blob/master/CHANGELOG.md)
- [Commits](https://github.com/magjac/d3-graphviz/compare/v4.1.1...v5.0.2)
bors [Sat, 7 Jan 2023 19:19:37 +0000 (19:19 +0000)]
Auto merge of #13876 - lnicola:zip-artifacts, r=lnicola
feat: Package Windows release artifacts as ZIP and add symbols file
Closes #13872
Closes #7747
CC #10371
This allows us to ship a format that's easier to handle on Windows. As a bonus, we can also include the PDB, to get useful stack traces. Unfortunately, it adds a couple of dependencies to `xtask`, increasing the debug build times from 1.28 to 1.58 s (release from 1.60s to 2.20s) on my system.
bors [Sat, 7 Jan 2023 19:03:34 +0000 (19:03 +0000)]
Auto merge of #13894 - lowr:patch/fallback-before-final-obligation-resolution, r=lnicola
Apply fallback before final obligation resolution
Fixes #13249
Fixes #13518
We've been applying fallback to type variables independently even when there are some unresolved obligations that associate them. This PR applies fallback to unresolved scalar type variables before the final attempt of resolving obligations, which enables us to infer more.
Unlike rustc, which has separate storages for each kind of type variables, we currently don't have a way to retrieve only integer/float type variables without folding/visiting every single type we've inferred. I've repurposed `TypeVariableData` as bitflags that also hold the kind of the type variable it's referring to so that we can "reconstruct" scalar type variables from their indices.
This PR increases the number of ??ty for rust-analyzer repo not because we regress and fail to infer the existing code but because we fail to infer the new code. It seems we have problems inferring some functions bitflags produces.
projects / rust.git / log