Age | Commit message (Collapse) | Author |
|
Previously, go-marshal only allowed literals for array
lengths. However, it's very common for ABI structs to have a fix-sized
array whose length is defined by a constant; for example PATH_MAX.
Having to convert all such arrays to have literal lengths is too
awkward.
PiperOrigin-RevId: 304289345
|
|
Previously, the import statement collision detection mechanism aborted
go-marshal whenever it detected two imports in any package that has
the same local name. Consider this trivial package, defined by the the
following two source files:
file1.go:
package example
import (
path/a/to/foo
)
...
file2.go:
package example
import (
another/package/with/final/component/foo
)
...
Go-marshal previously couldn't handle generating code for the the
above package, even if none of the types marked for marshalling used
either of the imported foo packages. This turns out to be too
restrictive as we run into this a lot in practice. Examples include
"encoding/binary" vs "gvisor/pkg/binary/binary", and "sync" vs
"gvisor/pkg/sync/sync".
This change allows go-marshal to proceed with marshalling, and only
abort if the code generated by go-marshal references any such
ambiguous import names.
PiperOrigin-RevId: 304131190
|
|
PiperOrigin-RevId: 304119255
|
|
There is a canonical naming convention for Examples, which are checked
by analyzers. This must be fixed since adding exceptions for generated
code will be more challenging.
|
|
PiperOrigin-RevId: 297693838
|
|
PiperOrigin-RevId: 296322954
|
|
Users of the API only care about whether the copy in/out succeeds in
their entirety, which is already signalled by the returned error.
PiperOrigin-RevId: 296297843
|
|
This can happen due to conditional compilation, where a subset of the
source files contain no marshallable types. go-marshal is still
required to write an output file in these cases, since bazel defines
the output package before calling go-marshal.
PiperOrigin-RevId: 296074321
|
|
Since we tag entire packages as marshallable, due to conditional
compiling for different architectures we can end up with sets of
source files that don't contain any marshallable types. It's safe to
silently ignore this scenario.
PiperOrigin-RevId: 295831871
|
|
This lets go-marshal replace various calls to binary.Size() throughout
the sentry without requiring concrete objects.
PiperOrigin-RevId: 295299965
|
|
PiperOrigin-RevId: 295269654
|
|
Note that this is not an automated test.
PiperOrigin-RevId: 295238672
|
|
- Add missing build tags to files in the abi package.
- Add the marshal package as a sentry dependency, allowed by deps_test.
- Fix an issue with our top-level go_library BUILD rule, which
incorrectly shadows the variable containing the input set of source
files. This caused the expansion for the go_marshal clause to
silently omit input files.
- Fix formatting when copying build tags to gomarshal-generated files.
- Fix a bug with import statement collision detection in go-marshal.
PiperOrigin-RevId: 295112284
|
|
Add new Marshallable interface methods CopyIn/CopyOut, which can be directly
called on the marshalled object, avoiding an interface indirection. Such
indirections are problematic because they always cause the marshalled object to
escape.
PiperOrigin-RevId: 295028010
|
|
Note that files will need to be appropriately segmented in order for the
mechanism to work, in suffixes implying special tags. This only needs to happen
for cases where marshal or state structures are defined, which should be rare
and mostly architecture specific.
PiperOrigin-RevId: 293231579
|
|
Because the abi will depend on the core types for marshalling (usermem,
context, safemem, safecopy), these need to be flattened from the sentry
directory. These packages contain no sentry-specific details.
PiperOrigin-RevId: 291811289
|
|
The preferred Copyright holder is "The gVisor Authors".
PiperOrigin-RevId: 291786657
|
|
PiperOrigin-RevId: 291745021
|
|
PiperOrigin-RevId: 281795269
|
|
They are no-ops, so the standard rule works fine.
PiperOrigin-RevId: 268776264
|
|
This CL implements go_marshal, a code generation utility for
automatically serializing and deserializing ABI structs.
The go_marshal tool automatically generates implementations of the new
marshal interface. Unlike binary.Marshal/Unmarshal, the generated
interface implementations use no runtime reflection, and translates to
a single memcpy for most structs. See go_marshal/README.md for
details.
PiperOrigin-RevId: 268065475
|