| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
The tag name subsection currently has the speculative ID of 10.
However, the extended-name-section proposal has now been updated to
use an ID of 11 for the tag name section. This updates the
NameSectionSubsection enum accordingly, as well as adding a field
name section with the ID of 10.
|
| |
|
| |
This makes things easier for users and packagers of libwabt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies clang-format to the whole codebase.
I noticed we have .clang-format in wabt but the codebase is not very
well formatted. This kind of mass-formatting PR has fans and skeptics
because it can mess with `git blame`, but we did a similar thing in
Binaryen a few years ago (WebAssembly/binaryen#2048, which was merged in
WebAssembly/binaryen#2059) and it was not very confusing after all.
If we are ever going to format the codebase, I think it is easier to do
it in a single big PR than dozens of smaller PRs.
This is using the existing .clang-format file in this repo, which
follows the style of Chromium. If we think this does not suit the
current formatting style, we can potentially tweak .clang-format too.
For example, I noticed the current codebase puts many `case` statements
within a single line when they are short, but the current .clang-format
does not allow that.
This does not include files in src/prebuilt, because they are generated.
This also manually fixes some comment lines, because mechanically
applying clang-format to long inline comments can look weird.
I also added a clang-format check hook in the Github CI in #1683, which
I think can be less controversial, given that it only checks the diff.
---
After discussions, we ended up reverting many changes, especially
one-liner functions and switch-cases, which are too many to wrap in
`// clang-format off` and `// clang-format on`. I also considered fixing
`.clang-format` to allow those one-liners but it caused a larger churn
in other parts. So currently the codebase does not conform to
`.clang-format` 100%, but we decided it's fine.
|
| |
|
|
|
|
|
|
|
| |
Tag names are not officially part of the extended-name-section proposal
(because it only deals with naming things that are in the spec already).
However, I think its reasonable (and useful) to include these names
under a speculative subsection ID, on the basis that tags can only exist
when exceptions are enabled and that engines should ignore unknown name
types.
|
| |
|
|
|
|
|
|
| |
See: https://github.com/WebAssembly/extended-name-section
Although this is only a phase 1 proposal its seems pretty
straight forward, and is already being implemented in
binaryen.
|
| | |
|
| |
|
| |
This way the names won't conflict with other headers with the same name.
|
| | |
|
|
|
Mostly this involves adding additional casts. Though there are a few
more substantial changes:
* The default method for relocating parser stacks no longer works
because Bison assumes that C++ values can't be memcpy'd. Ours can, but
there's no easy way to make the generated code do the right thing, so
we do it manually
* Removed all uses of WabtBool and replaced with bool
* Renamed all uses of export and mutable -> export_ and mutable_
* Casting an invalid value to an enum triggers ubsan, so we have to be a
little more careful about when we do it (see binary-reader.c:read_sections())
* It's illegal to forward-declare enums, so we just #include instead.
* Designated initializers are not allowed in g++, so we have to switch
them to lazily initialized structures instead. Pretty horrible, so it
will be nice to have a better solution for C++.
|
