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

capi: Import inspection functions #683

Merged
merged 1 commit into from
Jan 26, 2021
Merged

capi: Import inspection functions #683

merged 1 commit into from
Jan 26, 2021

Conversation

gumb0
Copy link
Collaborator

@gumb0 gumb0 commented Jan 7, 2021

Split from #675

@gumb0 gumb0 changed the title capi: Add functions to access import definitions in module capi: Import inspection functions Jan 7, 2021
@codecov
Copy link

codecov bot commented Jan 7, 2021

Codecov Report

Merging #683 (87a195d) into master (3c1c6ce) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           master     #683    +/-   ##
========================================
  Coverage   99.30%   99.30%            
========================================
  Files          72       72            
  Lines       10312    10420   +108     
========================================
+ Hits        10240    10348   +108     
  Misses         72       72            
Flag Coverage Δ
spectests 91.50% <ø> (ø)
unittests 99.30% <100.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
lib/fizzy/capi.cpp 98.84% <100.00%> (+0.12%) ⬆️
test/unittests/capi_test.cpp 100.00% <100.00%> (ø)

@gumb0 gumb0 mentioned this pull request Jan 7, 2021
49 tasks
@gumb0 gumb0 force-pushed the capi-import-inspection branch 2 times, most recently from 4c1101c to f8e37a7 Compare January 12, 2021 15:35
@@ -133,6 +133,33 @@ typedef struct FizzyExternalGlobal
FizzyGlobalType type;
} FizzyExternalGlobal;

/// External kind.
typedef enum FizzyExternalKind
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? They're quite similar except that I use full word for "function" and list them in the order of the spec.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They use uint8_t storage type. So it could be used in C++ directly. Or wrap it in C++ for better control.

typedef uint8_t wasm_externkind_t;
enum wasm_externkind_enum {
  WASM_EXTERN_FUNC,
  WASM_EXTERN_GLOBAL,
  WASM_EXTERN_TABLE,
  WASM_EXTERN_MEMORY,
};

// C++

enum class ExternalKind : wasm_externkind_t {
  func = WASM_EXTERN_FUNC,
  global = WASM_EXTERN_GLOBAL,
  table = WASM_EXTERN_TABLE,
  memory = WASM_EXTERN_MEMORY,
};

This may be done other day, but I'm suggesting exploring the design where some declarations are imported from C to C++ instead of only declaring C equivalents of C++ ones.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this could have been done for FizzyValueType, too 🤔

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. We may go old-school in this PR and then consider conversion. This probably requires off-site discussion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I use full word for "function"

I like this better.

list them in the order of the spec.

So is the wasm-c-api not in order with the spec?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

list them in the order of the spec.

So is the wasm-c-api not in order with the spec?

Yeah, there it's func-global-table-memory.

///
/// @note Only one member of FizzyImportDescription::desc union corresponding to
/// FizzyImportDescription::kind is defined for each import.
typedef struct FizzyImportDescription
Copy link
Member

@axic axic Jan 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to mention the lifetime of module/name here? It is explained in fizzy_get_import_description.

Perhaps what we could note here is that the user should refer to the documentation from the function returning this value about lifetimes:

Suggested change
typedef struct FizzyImportDescription
//// For the lifetime of the #module and #kind fields, please refer to the description provided by the function used to obtain this structure.
typedef struct FizzyImportDescription

Is #module the correct way?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, #module and #name worked, but I needed to add individual documentation to the members.

fizzy_free_module(module);
}

TEST(capi, import_name_after_instantiate)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this testing the lifetime of the name/namespace pointers?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, checks that it's alive after instantiation, as the documentation claims.

{
/* wat2wasm
(func (import "m" "f1") (result i32))
(func (import "m" "f2") (param i64))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make any difference in coverage having a case with multiple params and a result at the same time? Don't want to overcomplicate tests either.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add it for completeness.

Copy link
Member

@axic axic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good in general, but please squash the renaming commit. Added some smaller remarks.

/// FizzyImportDescription::kind is defined for each import.
typedef struct FizzyImportDescription
{
const char* module;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These fields are documented in #686. It should be consistent, either document here too, or not in #686.

@gumb0 gumb0 force-pushed the capi-import-inspection branch 2 times, most recently from 993c5a7 to b4aa0e9 Compare January 26, 2021 18:59
c_import_description.desc.memory_limits = wrap(import.desc.memory.limits);
break;
case FizzyExternalKindGlobal:
c_import_description.desc.global_type = wrap(import.desc.global);
Copy link
Member

@axic axic Jan 26, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, shouldn't this be wrap(import.desc.global.type)?

Never mind I see it includes both type and mutability.

@gumb0 gumb0 merged commit 43dcc2b into master Jan 26, 2021
@gumb0 gumb0 deleted the capi-import-inspection branch January 26, 2021 19:47
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.

3 participants