https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=master 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-10-23T23:11:25+00:00 Jack Huey 31162821+jackh726@users.noreply.github.com 2022-10-23T23:11:25+00:00 urn:sha1:de78c32b854d6f76167bb6fcf76fc2760c8b7d2a 2022-10-23T22:46:16+00:00 Soveu marx.tomasz@gmail.com 2022-08-08T13:31:32+00:00 urn:sha1:ba847cad6d1403feed2bba8b501c69d0a749f6de This patch makes it possible to use varargs for calling conventions, which are either based on C (like efiapi) or C is based on them (for example sysv64 and win64). 2022-09-03T05:54:13+00:00 Michael Goulet michael@errs.io 2022-09-02T02:17:44+00:00 urn:sha1:b0f3a551f2974eccf65b4477c9d7b2e42036d52f 2022-06-19T22:10:42+00:00 Michael Goulet michael@errs.io 2022-06-19T22:10:42+00:00 urn:sha1:4400a26e31363acd7427d47f7dff33da18419fcf 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. 2021-07-06T10:12:15+00:00 Simonas Kazlauskas git@kazlauskas.me 2021-06-11T11:22:13+00:00 urn:sha1:8240e7aa101815e2009c7d03b33dd2566d843e73 It makes very little sense to maintain denylists of ABIs when, as far as non-generic ABIs are concerned, targets usually only support a small subset of the available ABIs. This has historically been a cause of bugs such as us allowing use of the platform-specific ABIs on x86 targets – these in turn would cause LLVM errors or assertions to fire. Fixes #57182 Sponsored by: standard.ai 2020-10-15T14:22:39+00:00 Andy Russell arussell123@gmail.com 2020-09-24T02:43:32+00:00 urn:sha1:14b2d16c5c014de994c46eb17e52773ee01864c5 2020-06-04T14:59:59+00:00 Tom Eccles tom.eccles@codethink.co.uk 2020-05-20T16:35:47+00:00 urn:sha1:8edb05c2a0dbb6bee7c71c664e216c0d863411a6 2020-02-11T20:42:00+00:00 Esteban Küber esteban@kuber.com.ar 2020-02-06T05:08:07+00:00 urn:sha1:683ebc2dec0a5b88eb3eaf146e6855ea299d17b8