-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
Format missing module errors in upgrade errors #20541
Format missing module errors in upgrade errors #20541
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
3 Skipped Deployments
|
870cc60
to
a35cfa0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty happy with this change, modulo the question about trying to avoid returning an Err(...)
instead of the diagnostic. It would be good to get @tnowacki's take on things, because he's more the expert in this area than me, but after that, I think this is good to go!
let toml_path = package_path.join("Move.toml"); | ||
let toml_str = fs::read_to_string(&toml_path).context("Unable to read Move.toml")?; | ||
let hash = FileHash::new(&toml_str); | ||
|
||
let start: usize = toml_str | ||
.find(PACKAGE_TABLE) | ||
.context("Malformed Move.toml")?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like if we fail to read the Move.toml
we may end up hiding all the other diagnostics. Do you think it would be possible for us to always produce some kind of Diagnostics
value, even if we failed to read the Move.toml
to avoid that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking this more as a "critical" error since a build shouldn't be possible however I think it could be good to just let this return a diagnostic for byte ranges 0,0
as a fallback. Some errors I'd guess will just fall in that "critical" category and should be errored out but we could potentially discuss follow up work to prevent errors from stopping execution by converting Errors -> Diags
. Or alternatively just maintain a list of errors and print them last / concatenate them into a single error that is thrown last.
cec243e
to
a1bd394
Compare
a1bd394
to
ae1dbf7
Compare
ae1dbf7
to
3a63f78
Compare
...ests/snapshots/sui__upgrade_compatibility__upgrade_compatibility_tests__addresses_first.snap
Show resolved
Hide resolved
...snapshots/sui__upgrade_compatibility__upgrade_compatibility_tests__declarations_missing.snap
Show resolved
Hide resolved
...src/unit_tests/snapshots/sui__upgrade_compatibility__upgrade_compatibility_tests__emoji.snap
Outdated
Show resolved
Hide resolved
3a63f78
to
75782c9
Compare
b492ced
to
783feae
Compare
783feae
to
5400241
Compare
f321519
into
MystenLabs:main
Description
Missing modules errors do not have a file to point to since their file has been removed during upgrade or otherwise unknown since the declaration is gone from its previous file if the file still exists. Align missing modules errors with the behavior of other errors by using Move.toml as the reference point for these errors and pointing to the "package" instead.
Test plan
snapshots
Release notes
Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required.
For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates.