Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • pypy pypy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 676
    • Issues 676
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

April 05-07 - Mercurial Paris Conference 2023 - One day of workshop dedicated to Heptapod and Mercurial usage and workflow. There are still places available for both workshops and talks!

  • PyPyPyPy
  • pypypypy
  • Merge requests
  • !685

Use CTypeSpace to declare HPy types

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Bitbucket Importer requested to merge branch/hpy-ctypespace into branch/hpy Nov 22, 2019
  • Overview 0
  • Commits 10
  • Pipelines 0
  • Changes 8

Created originally on Bitbucket by antocuni (Antonio Cuni)

As the title says, the point is to avoid declaring lltypes by hand.

I think that the final result is much easier to read and to manage. Currently, the C bits needs to be written by hand, but we can probably hack more until it can read the real universal/hpy.h or an autogen version which is easier to parse. Another plus is that once this is merged, we can think of using C-like declarations inside @apifunc decorators, which will make things even easier to read.

The most tricky bits of this PR are:

  1. the difference between HPy in C and RPython; I don’t think that rffi can handle a real struct to pass around and to be returned, so we need to stick with a primitive. Because of this, I had to play around with typedefs so that the C-idea of HPy and the RPython-idea of HPy are compatible both before and after translation
  2. It seems that cpyext.cparser has a limitation for which it cannot properly digest struct types which are not part of a typedef. For now, I had to tweak a bit the headers and use typedefs everywhere. Ideally, it would be nice if cparser were able to do the correct thing automatically
  3. Another limitation of cparser: struct fields of type HPyMethodDef* are translated into lltype.Ptr(HPyMethodDef): I had to hack it manually to transform it into the CArrayPtr which we need. Not sure if it’s worth extending cparser to support also this case or it’s enough to keep this hack.
  4. As explained by XXX in llapi.py:101, the old lltype.Struct which we declared by hand had the eci hint. The new ones don’t, but things still work correctly. So, why did we need the eci in the first place, and is it the correct thing to just drop it?
  5. I modified the repr of lltype.Ptr to show also the hints, else CCHARP and CONST_CCHARP had the very same textual repr, which leaded to very confusing error messages.

‌

Links to builbod builds for rpython and own tests:

http://buildbot.pypy.org/builders/rpython-linux-x86-64/builds/243

http://buildbot.pypy.org/builders/own-linux-x86-64/builds/7829

Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: branch/hpy-ctypespace