bors [Mon, 9 Jan 2023 18:20:00 +0000 (18:20 +0000)]
Auto merge of #106637 - fee1-dead-contrib:rollup-ticvmsd, r=fee1-dead
Rollup of 10 pull requests
Successful merges:
- #105292 (Change a commit_if_ok call to probe)
- #105655 (Remove invalid case for mutable borrow suggestion)
- #106047 (Fix ui constant tests for big-endian platforms)
- #106061 (Enable Shadow Call Stack for Fuchsia on AArch64)
- #106164 (Move `check_region_obligations_and_report_errors` to `TypeErrCtxt`)
- #106291 (Fix incorrect suggestion for extra `&` in pattern)
- #106389 (Simplify some canonical type alias names)
- #106468 (Use FxIndexSet when updating obligation causes in `adjust_fulfillment_errors_for_expr_obligation`)
- #106549 (Use fmt named parameters in rustc_borrowck)
- #106614 (error-code docs improvements (No. 2))
David Koloski [Mon, 9 Jan 2023 15:22:08 +0000 (10:22 -0500)]
Accept old spelling of Fuchsia target triples
Because the old spelling is widely used, some projects may need time to
migrate their uses to the new triple spelling. The old spelling may
eventually be removed altogether.
Use ANSI control characters to display text decorations matching the VScode terminal theme, and strip them out when providing text content for rustc diagnostics.
This adds the small [`anser`](https://www.npmjs.com/package/anser) library (MIT license, no dependencies) to parse the control codes, and it also supports HTML output so it should be fairly easy to switch to a rendered HTML/webview implementation in the future
I also updated the default `cargo check` command to use the rendered ANSI diagnostics, although I'm not sure if it makes sense to put this kind of thing behind a feature flag, or whether it might have any issues on Windows (as I believe ANSI codes are not used for colorization there)?
Ian Chamberlain [Tue, 3 Jan 2023 15:16:16 +0000 (10:16 -0500)]
Parse + decorate rendered ANSI cargo output
Use ANSI control characters to display text decorations matching the
VScode terminal theme, and strip them out when providing text content
for rustc diagnostics.
This adds the small `anser` library to parse the control codes, and it
also supports HTML output so it should be fairly easy to switch to a
rendered HTML/webview implementation if desired.
bors [Mon, 9 Jan 2023 15:36:18 +0000 (15:36 +0000)]
Auto merge of #2755 - RalfJung:dtors_in_dtors_in_dtors, r=RalfJung
add dtors_in_dtors_in_dtors
That's a pretty neat test from the standard library. Sadly not enough to check for https://github.com/rust-lang/miri/issues/2754, but still worth having here.
bors [Mon, 9 Jan 2023 15:35:38 +0000 (15:35 +0000)]
Auto merge of #13799 - Veykril:flycheck, r=Veykril
Rename `checkOnSave` settings to `check`
Now that flychecks can be triggered without saving the setting name doesn't make that much sense anymore. This PR renames it to just `check`, but keeps `checkOnSave` as the enabling setting.
fee1-dead [Mon, 9 Jan 2023 15:35:32 +0000 (23:35 +0800)]
Rollup merge of #106614 - Ezrashaw:ui-test-fixups-2, r=GuillaumeGomez
error-code docs improvements (No. 2)
- Added empty error-code docs for `E0208`, `E0640` and `E0717` with the "internal" header as discussed on Discord.
- Wrote docs and UI test for `E0711`, again with the header.
- `tidy` changes are common-sense and make everything pass, `style.rs` hack is annoying though.
fee1-dead [Mon, 9 Jan 2023 15:35:30 +0000 (23:35 +0800)]
Rollup merge of #106389 - compiler-errors:no-canonicalized, r=lcnr
Simplify some canonical type alias names
* delete the `Canonicalized<'tcx>` type alias in favor for `Canonical<'tcx>`
* `CanonicalizedQueryResponse` -> `CanonicalQueryResponse`
I don't particularly care about the latter, but it should be consistent. We could alternatively delete the first alias and rename the struct to `Canonicalized`, and then keep the name of `CanonicalizedQueryResponse` untouched.
fee1-dead [Mon, 9 Jan 2023 15:35:27 +0000 (23:35 +0800)]
Rollup merge of #106047 - uweigand:s390x-test-bigendian-ui, r=oli-obk
Fix ui constant tests for big-endian platforms
A number of tests under ui/const-ptr and ui/consts are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the stderr test files.
Fix this by a combination of two types of changes:
- Where possible (i.e. where the particular value of a constant does not affect the purpose of the test), choose constant values that have the same encoding on big- and little-endian platforms.
- Where this is not possible, provide a normalize-stderr-test rule that transforms the printed big-endian encoding of such constants into the corresponding little-endian form.
Fixes part of https://github.com/rust-lang/rust/issues/105383.
fee1-dead [Mon, 9 Jan 2023 15:35:27 +0000 (23:35 +0800)]
Rollup merge of #105655 - RedDocMD:bug-105645, r=oli-obk
Remove invalid case for mutable borrow suggestion
If we have a call such as `foo(&mut buf)` and after reference
collapsing the type is inferred as `&T` where-as the required type is
`&mut T`, don't suggest `foo(&mut mut buf)`. This is wrong syntactically
and the issue lies elsewhere, not in the borrow.
fee1-dead [Mon, 9 Jan 2023 15:35:26 +0000 (23:35 +0800)]
Rollup merge of #105292 - JulianKnodt:no_eager_commit, r=BoxyUwU
Change a commit_if_ok call to probe
Removes an over-eager `commit_if_ok` which makes inference worse.
I'm not entirely sure whether it's ok to remove the check that types are the same, because casting seems to cause equality checks with incorrect types?
bors [Mon, 9 Jan 2023 14:24:41 +0000 (14:24 +0000)]
Auto merge of #13810 - tfpk:tfpk/macro-inline, r=Veykril
Add action to expand a declarative macro once, inline. Fixes #13598
This commit adds a new r-a method, `expandMacroInline`, which expands the macro that's currently selected. See #13598 for the most applicable issue; though I suspect it'll resolve part of #5949 and make #11888 significantly easier).
1. **Should we rustfmt the output?** The advantage of doing this is neater code. The disadvantages are we'd have to format the whole expr/stmt/block (since there's no point just formatting one part, especially over multiple lines), and maybe it moves the code around more in weird ways. My suggestion here is to start off by not doing any formatting; and if it appears useful we can decide to do formatting in a later release.
2. **Is it worth solving the `$crate` hygiene issue now?** -- I think this PR is usable as of right now for some use-cases; but it is annoying that many common macros (i.e. `println!()`, `format!()`) can't be expanded further unless the user guesses the correct `$crate` value. The trouble with solving that issue is that I think it's complicated and imperfect. If we do solve it; we'd also need to either change the existing `expandMacro`/`expandMacroInline` commands; provide some option to allow/disallow `$crate` expanding; or come to some other compromise.
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:
![2022-12-21_19-27](https://user-images.githubusercontent.com/38225716/208941721-d48d316f-a918-408a-9757-8d4e2b402a66.png)
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.