fix: endow with original unstructured assert
#2323
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Reviewers, if you see a way to refactor this change so there is less redundancy and fewer sites that need to be coordinated, please let me know. I do not like the maintenance burden produced by this PR. Or rather, produced by any naive solution to Agoric/agoric-sdk#9515. |
erights
changed the title
assert
kriskowal
approved these changes
Jun 17, 2024
kriskowal
approved these changes
Jun 17, 2024
erights
added a commit
that referenced
this pull request
Jun 17, 2024
Staged on #2323 Closes: #XXXX Refs: Agoric/agoric-sdk#5672 Agoric/agoric-sdk#9513 ## Description Does for endo what Agoric/agoric-sdk#9513 does for agoric-sdk --- importing `assert` from @endo/errors --- when it can do so without causing dependency cycles. For the remaining packages that would cause dependency cycles, just move them towards more modern assert conventions while still using the unstructured global `assert` ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations We should document `assert` only as imported from @endo/errors, since our users will not generally contribute code within endo's internal dependency cycles. ### Testing Considerations The CI run on this PR also serves to test #2323, since that one, by itself, does not cause a behavioral change. It's purpose is to enable this PR not to hit the problem described at Agoric/agoric-sdk#9515 ### Compatibility Considerations none ### Upgrade Considerations none
mergify bot
pushed a commit
to Agoric/agoric-sdk
that referenced
this pull request
Jun 17, 2024
closes: #9515 refs: #5672 #8332 #9513 endojs/endo#2323 ## Description To address #5672 , we should change all uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so (#8332 #9513) ran into the symptoms reported at #9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to #5672 by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to #5672 , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #9513 still passes CI once rebased on this PR. ***Update***: #9513 is now passing CI well enough to consider this PR (#9514) to be adequately tested. ### Upgrade Considerations This PR by itself does not have any dependence on @endo/errors existing, and so should be compatible even when linked against fairly ancient versions of endo.
mhofman
pushed a commit
to Agoric/agoric-sdk
that referenced
this pull request
Jun 20, 2024
closes: #9515 refs: #5672 #8332 #9513 endojs/endo#2323 ## Description To address #5672 , we should change all uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so (#8332 #9513) ran into the symptoms reported at #9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to #5672 by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to #5672 , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #9513 still passes CI once rebased on this PR. ***Update***: #9513 is now passing CI well enough to consider this PR (#9514) to be adequately tested. ### Upgrade Considerations This PR by itself does not have any dependence on @endo/errors existing, and so should be compatible even when linked against fairly ancient versions of endo.
mhofman
pushed a commit
to Agoric/agoric-sdk
that referenced
this pull request
Jun 22, 2024
closes: #9515 refs: #5672 #8332 #9513 endojs/endo#2323 ## Description To address #5672 , we should change all uses of `assert` to obtain `assert` by importing it from the `@endo/errors` package. However, attempts to do so (#8332 #9513) ran into the symptoms reported at #9515 for the reasons reported there -- accidentally using the imported `assert` as the endowment for the global `assert` of new Compartments. This PR prepares the ground for these fixes to #5672 by unambiguously endowing with the original unstructured `globalThis.assert`, which will remain the correct endowment even when other uses of `assert` have migrated to the one imported from `@endo/errors`. By itself, this PR, preceding those fixes to #5672 , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use `globalThis.assert` as the `assert` endowment. Fortunately, this will only be of concern to advanced developers. ### Testing Considerations Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #9513 still passes CI once rebased on this PR. ***Update***: #9513 is now passing CI well enough to consider this PR (#9514) to be adequately tested. ### Upgrade Considerations This PR by itself does not have any dependence on @endo/errors existing, and so should be compatible even when linked against fairly ancient versions of endo.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes: #XXXX
Refs: Agoric/agoric-sdk#9515 Agoric/agoric-sdk#9514
Description
Addresses Agoric/agoric-sdk#9515 as applied to endo, by doing for endo what Agoric/agoric-sdk#9514 does for agoric-sdk
To address Agoric/agoric-sdk#5672 for endo , we should change all applicable uses of
assertto obtainassertby importing it from the@endo/errorspackage. However, attempts to do so ran into the symptoms reported at Agoric/agoric-sdk#9515 for the reasons reported there -- accidentally using the importedassertas the endowment for the globalassertof new Compartments.This PR prepares the ground for these fixes to Agoric/agoric-sdk#5672 for endo by unambiguously endowing with the original unstructured
globalThis.assert, which will remain the correct endowment even when other uses ofasserthave migrated to the one imported from@endo/errors. By itself, this PR, preceding those fixes to Agoric/agoric-sdk#5672 for endo , is not actually fixing a bug in the sense of a behavioral change. Reviewers, let me know if you think this PR should be labeled a "refactor" because of this.Security Considerations
none
Scaling Considerations
none
Documentation Considerations
anyone gathering endowments for a new compartment should be aware of this issue, and be sure to use
globalThis.assertas theassertendowment. Fortunately, this will only be of concern to advanced developers.Testing Considerations
Since this PR doesn't actually cause any behavioral change, it cannot be tested in place. Rather, its test will be whether #2324 still passes CI once rebased on this PR.
Update: #2324 is now passing CI well enough to consider this PR (#2323) to be adequately tested.
Compatibility Considerations
The point. This PR itself only prepares the ground for the equivalent of Agoric/agoric-sdk#9513 for endo. By itself it has no other effect, and so no other compat issues.
Upgrade Considerations
none