Skip to content

merge-queue: embarking main (62017b0) and #375 together#408

Closed
mergify[bot] wants to merge 9 commits intomainfrom
mergify/merge-queue/main/375
Closed

merge-queue: embarking main (62017b0) and #375 together#408
mergify[bot] wants to merge 9 commits intomainfrom
mergify/merge-queue/main/375

Conversation

@mergify
Copy link
Copy Markdown

@mergify mergify Bot commented Apr 25, 2022

🎉 This combination of pull requests has been checked successfully 🎉

Branch main (62017b0) and #375 are embarked together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #375.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue default for merge:

  • base=main
  • check-success="buildkite/primer/pr/required"

More informations about Mergify merge queue can be found in the documentation.

Mergify commands

You can also trigger Mergify actions by commenting on this pull request:

  • @Mergifyio refresh will re-evaluate the queue rules

Additionally, on Mergify dashboard you can:

  • look at your merge queues
  • generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.com

brprice and others added 9 commits April 25, 2022 13:25
This is in preperation for adding module names, which will require some
renaming of primitives.  We will export some identifiers for these names
instead of writing them as literal strings, to make any future renames
easier.
This is in preperation for adding module names, which will require some
renaming of primitives.
This is not yet needed, as currently primitive types are always in scope
-- the '...WithPrims' just adds primitive terms. But this will change
shortly.
Instead of using 'defaultTypeDefs', define and use 'builtinModule' and
'primitiveModule'. This is in preparation for adding module names and
taking modules more seriously.

There is one theoretical drawback: in Tests.EvalFull we lose the ability
to generate definitions for global variables. However, we never actually
used this ability, so there is no loss in practice. (However, we may
want to re-instate this ability in the future so we can generate an
arbitrary context in these tests.)
This is a large commit, but most of it is pretty mechanical.

NB: we remove the test 'unit_rename_def_capture'. It tested that we
could not rename a definition in such a way that a reference would be
captured by a local binding. However, now that global variables have
module-qualified names, this is no longer possible: a local binding is
not considered to shadow any globals.

BREAKING CHANGE: this change requires a database migration, as it
changes the representation of `Prog`. However, since this is just
serialised to json and stored as a blob in the DB, it requires no schema
changes. Since we have no programs we need to preserve, we decided not
to bother with a migration. This means that DBs created before this
commit will not load with a primer containing this commit.
@mergify
Copy link
Copy Markdown
Author

mergify Bot commented Apr 25, 2022

The pull request #375 is mergeable

@mergify mergify Bot closed this Apr 25, 2022
@mergify mergify Bot deleted the mergify/merge-queue/main/375 branch April 25, 2022 16:53
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.

1 participant