https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=try 2023-01-11T09:32:08+00:00 2023-01-11T09:32:08+00:00 Albert Larsan 74931857+albertlarsan68@users.noreply.github.com 2023-01-05T08:13:28+00:00 urn:sha1:cf2dff2b1e3fa55fa5415d524200070d0d7aacfe 2022-12-14T09:31:05+00:00 Matthias Krüger matthias.krueger@famsik.de 2022-12-14T09:31:05+00:00 urn:sha1:8ed0384ca4651e914793dd8a05c9cdec9b2089b4 Refine when invalid prefix case error arises Fix cases where the "invalid base prefix for number literal" error arises with suffixes that look erroneously capitalized but which are actually invalid. 2022-12-13T03:32:12+00:00 Cassaundra Smith cass@cassaundra.org 2022-12-02T03:17:03+00:00 urn:sha1:52a9280fb249f2dfbc879ae32b1823203822fbec Fix cases where the "invalid base prefix for number literal" error arises with suffixes that look erroneously capitalized but which are in fact invalid. 2022-12-08T23:30:57+00:00 Esteban Küber esteban@kuber.com.ar 2022-12-02T23:56:37+00:00 urn:sha1:132a140214522246bef5da015f5cfb78da7074be 2022-04-16T06:26:56+00:00 Jack Huey 31162821+jackh726@users.noreply.github.com 2022-01-22T04:50:54+00:00 urn:sha1:b6c87c555f3b664f558d137d5f7696a07488157e This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes. The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other. We then modify that algorithm to detect 4 cases: - A function input is missing - An extra argument was provided - The type of an argument is straight up invalid - Two arguments have been swapped - A subset of the arguments have been shuffled (We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.) It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site. The basic sketch of the algorithm is as follows: - Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input. - If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type". - Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument. - Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input - Swapped / Permuted arguments are identified with a cycle detection algorithm. As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again. Note that there's a lot of extra complexity: - We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix. - Closure arguments are wrapped in a tuple and need to be unwrapped - We need to resolve closure types after the rest, to allow the most specific type constraints - We need to handle imported C functions that might be variadic in their inputs. I tried to document a lot of this in comments in the code and keep the naming clear. 2022-01-31T17:34:10+00:00 5225225 5225225@mailbox.org 2022-01-27T22:22:33+00:00 urn:sha1:ec3b711a4bcc8cb3af34b2cdf1ad110eef5981f9 2021-12-03T01:00:09+00:00 Esteban Kuber esteban@kuber.com.ar 2021-12-03T01:00:09+00:00 urn:sha1:5b5df0fa17a36ab1a182313c2cb4db0799b9249f 2021-11-14T17:38:42+00:00 Caio c410.f3r@gmail.com 2021-11-14T17:38:42+00:00 urn:sha1:ab5434f9b8d3937fe33f813b3f8e1a43a4657781 2021-09-19T08:31:29+00:00 Yuki Okushi jtitor@2k36.org 2021-09-19T08:31:29+00:00 urn:sha1:ebd31f5f1a51099038935e679b0eb92afa3364a5 Suggest replacing an inexisting field for an unmentioned field Fix #87938 This PR adds a suggestion to replace an inexisting field for an unmentioned field. Given the following code: ```rust enum Foo { Bar { alpha: u8, bravo: u8, charlie: u8 }, } fn foo(foo: Foo) { match foo { Foo::Bar { alpha, beta, // `bravo` miswritten as `beta` here. charlie, } => todo!(), } } ``` the compiler now emits the error messages below. ```text error[E0026]: variant `Foo::Bar` does not have a field named `beta` --> src/lib.rs:9:13 | 9 | beta, // `bravo` miswritten as `beta` here. | ^^^^ | | | variant `Foo::Bar` does not have this field | help: `Foo::Bar` has a field named `bravo`: `bravo` ``` Note that this suggestion is available iff the number of inexisting fields and unmentioned fields are both 1. 2021-09-13T16:31:12+00:00 bors bors@rust-lang.org 2021-09-13T16:31:12+00:00 urn:sha1:9bb77da74dac4768489127d21e32db19b59ada5b Use smaller spans for some structured suggestions Use more accurate suggestion spans for * argument parse error * fully qualified path * missing code block type * numeric casts