Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Param match relax #23033

Merged
merged 22 commits into from
Dec 15, 2023
Merged

Param match relax #23033

merged 22 commits into from
Dec 15, 2023

Conversation

Graveflo
Copy link
Contributor

@Graveflo Graveflo commented Dec 5, 2023

@Graveflo
Copy link
Contributor Author

Graveflo commented Dec 12, 2023

paramTypesMatch should only compare operands' type relations to the formal parameter. Currently it calls cmpCandidates which in turn calls checkGeneric and complexDisambiguation on two competing operands. This should not happen because the operands are not a call site and do not have operands of their own, so we cannot preemptively pick the least general, or most complex overload at this time.
That is done during overload resolution because the operand has already been matched to the formal parameters, so the result of checkGeneric and complexDisambiguation are also in relation to the operand. Of course, the parameters to these two procs are formal parameters in this case not operands, thus the isFormal flag.

Scope can still be made useful in paramTypesMatch, so I made that work, but only if the compiler is in need of a resolved symbol (so not for typed and untyped). This is helpful as it allows for simple expressions like:

let x: proc = cmp

If cmp is defined in the same module as x (with no overloads in the module), the user probably wants to select the cmp overload that is in scope. For clarity, this kind of syntax may currently work, but only if the overload that the user wants to select happens to be the least general, or most complex overload globally. In this case it makes more sense to simply be more specific in the let statement.

I disabled datamancer for this PR (again) because after many hours of digging around I cannot fault the compiler for the CI failure. Something is making datamancer's macros pick the wrong type for their df view iterator. This is the problematic code FYI:

import datamancer, seqmath
type
  Foo = object
    fd: float 
let a = [1, 2, 3]
var fm = Foo(fd: 5.2)
let fn = f{ idx("a") > fm.fd }

Now that I am convinced that datamancer is the issue here, I am going to keep investigating, but I'll open this PR for review so that we can start scrutinizing it, as it is now.

@Graveflo Graveflo marked this pull request as ready for review December 12, 2023 02:11
@Graveflo
Copy link
Contributor Author

I think I fixed datamancer, and I'm going to run the CI on one more commit with a couple of changes that I think will be beneficial

@Araq
Copy link
Member

Araq commented Dec 14, 2023

Sorry, you need to rebase already.

@Graveflo
Copy link
Contributor Author

wait a minute... what the?

@Graveflo
Copy link
Contributor Author

Graveflo commented Dec 14, 2023

Seems git didn't like what I did there, but it should all be squashed anyway I guess.

There is an ugly part of my changes at the end of paramTypesMatch:

if best > -1 and result != nil:
  # only one valid interpretation found:
  markUsed(m.c, arg.info, arg[best].sym)
  onUse(arg.info, arg[best].sym)
  result = paramTypesMatchAux(m, f, arg[best].typ, arg[best], argOrig)

(and some related bits). I kept this code path in there because that's how it was when I got there. It doesn't have to be weird like that if tyTyped and tyUntyped parameters have no need to do this. I figure they may not have to but I wasn't sure enough to go ahead and do it.

@Araq Araq merged commit 94f7e96 into nim-lang:devel Dec 15, 2023
19 checks passed
Copy link
Contributor

Thanks for your hard work on this PR!
The lines below are statistics of the Nim compiler built from 94f7e96

Hint: mm: orc; opt: speed; options: -d:release
177411 lines; 7.499s; 766.203MiB peakmem

@Graveflo Graveflo deleted the param_match_relax branch December 15, 2023 12:19
narimiran pushed a commit that referenced this pull request Aug 31, 2024
---------

Co-authored-by: Nikolay Nikolov <nickysn@gmail.com>
Co-authored-by: Pylgos <43234674+Pylgos@users.noreply.github.com>
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Co-authored-by: Jason Beetham <beefers331@gmail.com>
(cherry picked from commit 94f7e96)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants