Exclude compiler generated args

[forki]

This addresses #3705

Let's see what else we break ;-)

[forki]

but this fails at wrong position ;-)

[forki]

ok the "fix" is clearly wrong. It's matching the _ already because the nameres sees it as _arg1. It also matches the _arg1 in function body, but there is no way for me to see if we are in function definition or function body.

[forki]

@dsyme do you think #3705 is a bug? If so I could try to pass down context info like we do in TypeChecker

[dsyme]

Yes, it's a bug

[forki]

the fix would be breaking...

[dsyme]

the fix would be breaking...

I wouldn't mind that - it is obviously a bug and any code relying on this shouldn't compile - but we can explore ways to make it a warning if necessary

[drvink]

Since I was tricked by @forki ;) into #3706, I asked about solving this too, and he said that it's trickier than it seemed at first blush: not only does more state need to be threaded down to the point at which it would be most convenient to make the check as to whether the identifier was compiler-generated, but also, that state is replicated in other places, which means we would need to invalidate it everywhere else it exists.

I don't know enough about the compiler to know whether this is a stupid suggestion, but an easy (though somewhat a hack) solution would be to simply regard _argn as an invalid/reserved name within the parser--the idea being that we do not want users to be able to use it as an identifier, so it should cause a failure if we see it as user input, but post-parsing, the compiler would be able to introduce identifiers with such names for internal use.

Rationale:

1. As long as this would not interfere with e.g. quotations or TPs, it seems like an OK solution for the time being
2. We want to prevent this ASAP so that "clever" users cannot write code that uses it
3. We want to do this ASAP to minimize the amount of breakage to existing code that does use it (if there is any)
4. There are no (obvious) upsides to permitting the existing behavior

Anti-rationale:

1. Parser seems like the "wrong" place to put it, since it's a valid token and (currently) a valid identifier, though I don't know if there's necessarily a better place, and we can still provide useful diagnostics if we make it a parse error

[forki]

@drvink I think i found the "correct" way. now we need tons of samples ;-)

[KevinRansom]

@forki,

Hi mate, what is the status of this?

Thanks

Kevin

[forki]

Need to revisit

[KevinRansom]

thx

[KevinRansom]

@forki, do you intend getting back to this, or can this be closed?

[KevinRansom]

@forki,

we like this work, however, in order to reduce the number of abandoned, but open PR's we are closing it. Feel free to reopen this PR or resubmit the change when believe you are able to complete it.

Kevin