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

[WIP] exportable pragmas #13016

Closed

Conversation

timotheecour
Copy link
Member

@timotheecour timotheecour commented Jan 3, 2020

see tests

small example:

# foo.nim:
template myfoo0* = {.exportc: "myfoo0_in_c".}
# main.nim
import foo
proc bar() {.myfoo0, discardable.} = 12

caveats (help welcome)

right now this has some limitations:

  • can't use a classical user defined pragma pragma inside a template pragma EDIT: actually it's possible for local pragma pragma, see tests; for non-loacl pragma pragmas, would require also exportable pragmas (v2) #13030
  • can't use non exported template pragma inside exported template pragma EDIT: works, see tests
  • [EDIT] ideally the pragmas would be evaluated at definition time and bind to symbols, not identifiers; see example myfooHijacked illustrating how a locally defined template pragma affects an imported pragma because it hijacks the identifier
    EDIT: this now works, no hijacking happens, see tests

note

see also #13030 for an alternative implementation

@timotheecour timotheecour changed the title [WIP] first class pragmas that can be exported [WIP] exportable pragmas Jan 3, 2020
@timotheecour timotheecour mentioned this pull request Jan 4, 2020
3 tasks
@timotheecour timotheecour reopened this Jan 5, 2020
@Araq
Copy link
Member

Araq commented Jan 5, 2020

For some reason I missed this PR, I like it much better than #13030. Definitely how we should do things IMO, the pragma pragma always was weird.

@timotheecour timotheecour marked this pull request as ready for review January 6, 2020 20:00
@timotheecour
Copy link
Member Author

  • added more tests illustrating hijacking caveat
  • this PR is actually complementary to exportable pragmas (v2) #13030 if we want to also support exported pragma pragma's, otherwise these template pragmas can use local pragma pragmas but can't be exported themselves.

The root cause of all this is we're binding identifiers, not symbols; if you can think of a way to bind symbols, that would improve things.
Hopefully doesn't block this PR

@timotheecour
Copy link
Member Author

PTAL, I've resolved the main issues:

  • template pragmas now try to resolve identifiers as symbols (unless template is {.dirty.})
  • this removes hijacking (ditto, unless {.dirty.})
  • also we now doesn't need to export foo if we have template bar = {.foo.}
  • also we can now use pragma pragma's inside template pragmas

@timotheecour
Copy link
Member Author

timotheecour commented Jan 7, 2020

note

one question is how to handle this:

@Araq
Copy link
Member

Araq commented Jan 7, 2020

I doubt this answers your question directly but effectively builtin pragmas are in their own namespace and only unknown pragmas are mapped to templates or pragma pragmas. I doubt too much can be done about this design without breaking too much code out there. This implies that bulitin pragmas inside templates should get the same special handing as e.g. the if keyword gets since effectively the builtin pragmas are keywords, albeit only enabled in a {. .} environment.

@timotheecour
Copy link
Member Author

I believe this PR, once finished, will allow since to work with templates; right now you can't write:

template lenTuple*(t: tuple): int {.since: (1, 1).} =
  ## Return number of elements of `t`
  lenTuple(type(t))

because it gives: Error: cannot attach a custom pragma to 'lenTuple'

but once pragma's use PSym that bind locally, this should work

@Araq
Copy link
Member

Araq commented Apr 22, 2020

The CIs are all red but the feature is decent, please continue to work on it.

@stale
Copy link

stale bot commented May 1, 2021

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.

@stale stale bot added the stale Staled PR/issues; remove the label after fixing them label May 1, 2021
@timotheecour timotheecour removed the stale Staled PR/issues; remove the label after fixing them label May 1, 2021
@timotheecour timotheecour marked this pull request as draft May 1, 2021 20:02
@stale
Copy link

stale bot commented May 2, 2022

This pull request has been automatically marked as stale because it has not had recent activity. If you think it is still a valid PR, please rebase it on the latest devel; otherwise it will be closed. Thank you for your contributions.

@stale stale bot added the stale Staled PR/issues; remove the label after fixing them label May 2, 2022
@stale stale bot closed this Jun 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Staled PR/issues; remove the label after fixing them
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants