This release v1.9.0 of go.uber.org/atomic. The list of changes in this releases
is [v1.8.0...997edd6][1].
[1]: https://github.com/uber-go/atomic/compare/v1.8.0...997edd6
In updating the changelog, I moved the reference links around so that each
reference link was in its own section rather than piled at the bottom of the
file where it gets pretty ungainly.
The list of reference links at the bottom gets pretty ungainly. Move
references to the section for each version.
This should have no effect on the actual Markdown output.
Fixes#99
The current uintptr test assumes that pointers are 64-bit, so the test
fails to compile on architectures with 32-bit pointers. Instead, cast
-1 to uintptr, which matches math.MaxUint64 on 64-bit architectures, and
math.MaxUint32 on 32-bit architectures.
Verified by using GOARCH=386
* Add atomic.Time
* fix the arg variable name in the generated code from x to t
* fix build err
* lint
* add changelog entry
* add more tests to show we preserve the whole time.Time struct
* removing add/sub/round
* code review feedback
This change is a renaming with no functional changes.
It includes the following renames:
* `val` for arguments that replace the atomic value (e.g., `Store`).
* `delta` for arguments that offset the atomic value (e.g., `Add`).
* `old`, `new` for arguments to `CAS`.
* `old` named return from `Swap`.
* `swapped` for named return from `CAS`.
This also matches the names used in the stdlib atomic interface:
https://golang.org/pkg/sync/atomic/
Float64 wraps a Uint64, and since Uint64 supports Swap, Float64 can also
support Swap. Enable the Swap method in the generated code, and add
tests.
This also adds a note for why String doesn't support Swap (though it
will be possible after Go 1.17+).
NaN != NaN when using Go's inbuilt operator, but the same is not true
when used with Float64.CAS. Add a note calling this out.
Changing this would be a behaviour change (requires a major version
bump), and is likely unsafe as it could lead to typical CAS loops
blocking forever.
To add the note, we copy the generated CAS method and extend the
documentation as the generator does not support per-method
customizations on the doc comments.
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.
