Add support for atomic `uintptr` and `unsafe.Pointer` types.
For `unsafe.Pointer`, name the atomic variant `atomic.UnsafePointer` to
maintain the "unsafe" portion of the name in usage.
Resolves#88
The generators gen-atomicint and gen-atomicwrapper hard-coded the year
into the licenses of the generated files.
Update to generate year ranges for the licenses, starting at 2020, going
to whatever today's year is.
FOSSA analysis currently blocks CI on pull requests because they are
denied access to secrets.
Run FOSSA as a separate job only when we push to a branch of the
project.
Use GitHub Actions because we're deprecating use of Travis for our OSS
projects.
This change ran into some issues with the `generatenodirty` check so
we changed it to print `git status`. We ran into an issue where
`go mod download` was changing the go.sum and `go mod tidy` was alone.
As a workaround for this, the CI job doesn't `go mod download` by
default; we'll let the actual `test` or `build` commands do that.
After some more digging into #83, the issue was actually lack of HOME.
We need to specify GOPATH and GOCACHE because we haven't specified a
HOME.
Given the setup,
```
cd $(mktemp -d)
echo "module example.com/demo" > go.mod
echo "package demo" > demo.go
eval $(gimme 1.16rc1)
GO=$(which go)
```
If we run `go build` with an empty environment, it fails as expected.
```
$ env -i $GO build
missing $GOPATH
```
Setting HOME gives it a good default place for GOPATH, GOCACHE, and
friends.
```
$ env -i HOME=$(pwd)/home $GO build # succeeds
```
The nocmp integration test creates a temporary directory with a copy of
nocmp.go and a Go file that should not compile if our implementation of
nocmp is correct.
This worked fine without a GOPATH set previously, but with Go 1.16, it
seems that we need to have the GOPATH environment variable set (ref
https://github.com/golang/go/commit/cdbd4d49d8b).
Change the nocmp integration test to rely on Go modules for the test.
We can point GOPATH to an arbitrary temporary directory because we don't
rely on anything in it.
Fixes#82
The embedded `nocmp` field and other similar fields are unused in tests
and the rest of our code.
We can get the effect of `nocmp` without embedding the fields by using
`_ nocmp` as a field.
`staticcheck` caught the following issue.
nocmp_test.go:84:7: type y is unused (U1000)
Test was intended to evaluate the size of the new `type y` but due to a
typo, we were testing with `x`.
Renaming tools.go to tools_test.go isn't enough. These constraints are
still carried over to consumers. Renaming only drops them from
`go mod vendor`.
This moves tools dependencies to a `tools` submodule which we will never
publish.
Ref uber-go/multierr#38
`gen-valuewrapper` is specialized to generating type-safe atomic
wrappers around `atomic.Value`. This limitation is unnecessary. Given
functions to convert an exposed type to the underlying type (referred to
as "packing" here) and back ("unpacking"), we can generate wrappers
around any backing atomic type.
This generalizes `valuewrapper` into an `atomicwrapper` implementing
said functionality, and adding opt-in support for generating CAS, Swap,
and JSON methods.
With this, we can automatically generate bool, float64, and
time.Duration atomic wrappers on top of Uint32, Uint64, and Int64
respectively, as well as their core functionality.
Generate atomic.Float64 with gen-valuewrapper by wrapping atomic.Uint64,
using math.Float64bits and math.Float64frombits to pack and unpack
float64 to uint64.
As in #73, separate each atomic type into its own file to ease review of
transition to generated code.
After moving every atomic to its own file, the atomic.go file serves
only as documentation, so rename it to doc.go.
valuewrapper can be used only to generate atomic wrapper types for
types which are stored as atomic.Value. This isn't necessary because the
same logic can be applied to atomic wrappers built on other types like
Duration and Bool.
Generalize valuewrapper into atomicwrapper with support for optional
pack/unpack functions which handle conversion to/from `interface{}`.
This lets Error hook in and install the `storedError` struct (now called
`packedError`) to avoid panics from nil storage or value type change.
Add safe `String()` methods for atomic types that replicate the same
behavior as `fmt.Sprintf("%v", x.Load())` without the allocations.
As with json.Marshaler/Unmarshaler, we've omitted the `atomic.Value`
type for now.
Resolves#50
It is currently possible to make non-atomic comparisons of atomic
values:
x := atomic.NewInt32(1)
y := atomic.NewInt32(1)
fmt.Println(*x == *y)
This is undesirable because it loads the value in a non-atomic way. The
correct method is,
x := atomic.NewInt32(1)
y := atomic.NewInt32(1)
fmt.Println(x.Load() == y.Load())
To prevent this, disallow comparison of atomic values by embedding an
uncomparable array into atomics. The empty array adds no runtime cost,
and does not increase the in-memory size of the structs. Inspired by
[go4.org/mem#RO][1].
[1]: 3dbcd07079/mem.go (L42)
Note that the Value struct, which embeds `"sync/atomic".Value` was also
changed. This will break usages in the following form, but that's
acceptable because unkeyed struct literals are among the exceptions
stated in the [Go 1 compatibility expectations][2].
import (
syncatomic "sync/atomic"
"go.uber.org/atomic"
)
atomic.Value{syncatomic.Value{..}}
[2]: https://golang.org/doc/go1compat#expectationsResolves#72
Generated files should contain the following comment in the first few
lines for them to be considered generated by GitHub.
Code generated by <executable>
The additional `@generated` tag does the same for Phabricator.
Rather than hand-writing the atomic wrappers for integers and types
which wrap `atomic.Value`, generate them automatically from shared
templates. The generators are placed under `internal/gen-*` to avoid
external usage.
A new `make` target verifies that the code checked into the repository
is always up-to-date.
Rather than hand-writing wrappers around atomic.Value, generate them
automatically from the same template. The generator is at
internal/gen-valuewrapper. The generator correctly handles generating
wrapper structs for nillable types.
Rather than hand-writing the atomic integers, generate them
automatically from the same template. The generator is at
internal/gen-atomicint.
To ensure these are never out of date, add another `make` target which
verifies that the working tree is left unchanged after regenerating
code.
In anticipation of automatically generating these definitions, pull the
definitions of the various integer types into their own files as well as
their tests.
This will make it easier to review the changes when each of these files
is generated independently and automatically.
Since String holds textual information, instead of implementing
json.Marshaler and json.Unmarshaler, we should implement
encoding.TextMarshaler and encoding.TextUnmarshaler on String.
This makes it encodable and decodable using a variety of formats
including JSON, XML, YAML, and TOML.
Support serializing and deserializing atomic objects to/from JSON using
the JSON representation of the underlying types. Without this,
marshaling returns `{}`.
Per discussion in #68, `atomic.Value` does not yet implement support
because there's an open question as to whether it should implement it
even if the underlying type doesn't support JSON marshaling/
unmarshaling.
Resolves#49
We use `golang.org/x/{tools,lint}` for dev-time tooling only. We don't
need to declare it as a library dependency. This causes issues like
https://github.com/uber-go/multierr/issues/35.
This change drops these depnedencies by renaming the tools.go so that
these are considered test dependencies only. `go mod vendor` does not
consider test dependencies.
Most methods of Bool currently rely on the last bit, but `CAS`
generates the int value to match `old` based on the user's input
and so it assumes the value is either `1` or `0`.
The only reason we relid on the last bit is that `Toggle` was
implemented using an atomic add. We can instead implement
`Toggle` using a loop around `CAS`.
Fixes#61.
In migrating to Go modules, we had to decide between the import paths
github.com/uber-go/atomic and go.uber.org/atomic. We chose the latter.
As a result of this, users of the legacy import path would get an error
message similar to the following:
github.com/uber-go/atomic: github.com/uber-go/atomic@v1.5.0: parsing go.mod:
module declares its path as: go.uber.org/atomic
but was required as: github.com/uber-go/atomic
We suggested that users of the legacy import path add the following to
their go.mod.
replace github.com/uber-go/atomic => go.uber.org/atomic v1.5.0
This is inaccurate and will result in the following error message:
go.uber.org/atomic@v1.5.0 used for two different module paths
(github.com/uber-go/atomic and go.uber.org/atomic)
This was not detected before because `go mod tidy` works fine with this
`replace` directive. It fails only when it gets to `go build`.
After digging into this more, per section 4.4 of the resolution section
of [How can I resolve "parsing go.mod: unexpected module path" (..)][1],
the correct method of resolving this is to downgrade the legacy import
path to a version prior to the use of Go modules.
[1]: https://github.com/golang/go/wiki/Modules#how-can-i-resolve-parsing-gomod-unexpected-module-path-and-error-loading-module-requirements-errors-caused-by-a-mismatch-between-import-paths-vs-declared-module-identity
So the correct `replace` directive here would be,
replace github.com/uber-go/atomic => github.com/uber-go/atomic v1.4.0
This fix was verified both, locally and by @atibhav21 who first ran into
this.
This switches atomic to Go modules. This has the effect of simplifying
the Makefile and the Travis build, as well as getting rid of the overly
complicated coverage script we copied here.
Tools dependencies (currently only golint) were added to the tools.go.
As a result of this change, we no longer support the non-vanity import path
github.com/uber-go/atomic. Users must use the vanity import path, or add a
`replace` directive.
Supersedes #40
Clean up the Makefile to use ./... instead of a packages variable.
Golint checks vendor when used with "./..." so use `go list ./...`.
This lint check was previously not even running (PKGS was undefined).
