cuishuang
Repos
399
Followers
86
Following
89

some useful tool for developer

17
5

Events

Site updated: 2022-12-04 22:10:10

Created at 4 days ago

Site updated: 2022-12-04 21:24:08

Created at 4 days ago

Site updated: 2022-12-04 16:41:16

Created at 4 days ago

Site updated: 2022-12-03 16:57:29

Created at 5 days ago

Site updated: 2022-11-30 22:13:46

Created at 1 week ago

Site updated: 2022-11-24 12:04:13

Created at 2 weeks ago

Site updated: 2022-11-21 12:06:38

Created at 2 weeks ago

Site updated: 2022-11-14 15:45:58

Created at 3 weeks ago

Site updated: 2022-11-13 16:52:30

Created at 3 weeks ago
pull request opened
fix some typos in comments
Created at 3 weeks ago

fix some typos in comments

Signed-off-by: cui fliter imcusg@gmail.com

Created at 3 weeks ago

Site updated: 2022-11-13 15:11:49

Created at 3 weeks ago
Created at 3 weeks ago
pull request opened
fix typo
Created at 3 weeks ago

fix typo

Signed-off-by: cui fliter imcusg@gmail.com

Created at 3 weeks ago
pull request opened
fix typo
Created at 3 weeks ago

fix typo

Signed-off-by: cui fliter imcusg@gmail.com

Created at 3 weeks ago

Site updated: 2022-11-13 13:45:50

Created at 3 weeks ago

Site updated: 2022-11-13 00:18:20

Created at 3 weeks ago

Site updated: 2022-11-10 19:34:09

Created at 4 weeks ago
Created at 4 weeks ago
Created at 4 weeks ago
started
Created at 4 weeks ago
issue comment
fix a few function names on comments

It seems that there is no new submission

Please confirm if it is possible to merge now

Created at 4 weeks ago

fix a few function names on comments

Signed-off-by: cui fliter imcusg@gmail.com

Created at 4 weeks ago
issue comment
fix a few function names on comments

Please resolve the conflict

done

Created at 4 weeks ago

CI: Run against Go 1.17 and 1.18 (#1068)

We support the two most recent Go minor relases with Zap. With 1.18 newly released, we can transition to only 1.17 and 1.18.

I took this opportunity to also bump the Go version specified in the go.mod files since there is a change in behavior between when we generated these and now.

staticcheck had to be upgraded to master to run successfully.

Replace 'Interface' usage with correct zerolog api (#1069)

Handle structures as documented in zerolog, similar to how zap does in it's test case.

Add Objects field constructor for array of objects

Add a new Zap field constructor that encodes an array of zero or more Zap-marshalable objects into a Zap array.

Usage:

// Given,
//
// func (*User) MarshalLogObject(zapcore.ObjectEncoder) error

zap.Objects("foo", []*User{u1, u2, u3})

Before this, users would have to resort to constructing a []*User wrapper, and use Zap's Array constructor:

// Before:

type users []*User

func (uu users) MarshalLogArray(enc zapcore.ArrayEncoder) error a
    for _, u := range uu {
        if err := enc.AppendObject(u); err != nil {
            return err
        }
    }
    return nil
}

zap.Array("foo", users{u1, u2, u3})

Credit to ztstewart for the suggestion.

Refs GO-618

Reviewed-At: D7294727 Reviewed-By: ztstewart

Add ObjectValues field constructor

In the previous change, we added a Objects field constructor to support logging arrays of any object supported by zap.Object.

func (*User) MarshalLogObject(...) error { ... }
var users []*User = ...
zap.Object("users", users)

That solution is incomplete because it does not cover the case when, instead of a []*User, we have a []User despite the method being on *User.

This change adds a similar ObjectValues field constructor that handles the case where we have a []T but the MarshalLogObject is on *T.

This works by declaring a new type constraint objectMarshalerPtr. objectMarshalerPtr[T] is true for a type that is a pointer to T, and implements zapcore.ObjectMarshaler.

Note that we still do not cover the case where the method is on the value receiver (func (User) MarshalLogObject(..) error) and we have a []*User. We can add that when it becomes necessary.

Reviewed-At: D7295739 Reviewed-By: ztstewart

ObjectValues: Avoid copying

Minor optimization to avoid copying the struct to a variable.

Refs GO-618

Reviewed-At: D7297933 Reviewed-By: abhinav

CI: Temporarily disable staticcheck

staticcheck is expected to have support for generics-based code in a few weeks. Disable it until then.

Add Objects and ObjectValues field constructors (#1071)

This pull request adds two new field constructors for slices, parameterized over the types of the values in the slices:

func Objects[T zapcore.ObjectMarshaler](key string, value []T) Field

This turns a slice of any Zap marshalable object into a Zap field.

func ObjectValues[T any, P objectMarshalerPtr[T]](key string, values []T) Field

This is a variant of Objects for the case where *T implements zapcore.ObjectMarshaler but we have a []T.

Together, these two field constructors obviate the need for writing ArrayMarshaler implementations for slices of objects:

// Before //////////////

type userArray []*User

func (uu userArray) MarshalLogArray(enc zapcore.ArrayEncoder) error {
    for _, u := range uu {
        if err := enc.AppendObject(u); err != nil {
            return err
        }
    }
    return nil
}

var users []*User = ..
zap.Array("users", userArray(users))

// Now /////////////////

var users []*User = ..
zap.Objects("users", users)

Backwards compatibility

Both new field constructors are hidden behind a build tag, but use of type parameters requires us to bump the go directive in the go.mod file to 1.18.

Note that this does not break Zap on Go 1.17. Per the documentation for the go directive,

If an older Go version builds one of the module’s packages and encounters a compile error, the error notes that the module was written for a newer Go version.

It only breaks our ability to run go mod tidy inside Zap from Go 1.17, which is okay because with the go directive, we're stating that we're developing Zap while on Go 1.18.

Linting

staticcheck support for type parameters is expected in a few weeks. Meanwhile, this disables staticcheck for the make lint target. (I considered switching linting to Go 1.17 until then, but that isn't enough because the formatting linter expects valid Go code--which type parameters aren't in 1.17.)

Upgrade staticcheck and re-enable (#1074)

staticcheck 0.3 was just released with support for type parameters. Upgrade to it and re-enable the check we disabled in a prior commit.

zapcore/encoder_test: Use yaml.v3 (#1075)

encoder_test decodes YAML to verify the behavior of EncoderConfig. This behavior is the same between yaml.v2 and yaml.v3. Since dependencies that use YAML have already moved on to yaml.v3, we should as well.

Note that this drops yaml.v2 from our go.mod entirely.

SugaredLogger: Add WithOptions (#1079)

Add a WithOptions method to SugaredLogger that allows specifying building a copy of the logger with the specified options applied.

This allows turning,

slog.Desugar().WithOptions(...).Sugar()

Into,

slog.WithOptions(...)

Closes #1072

SugaredLogger: Add *ln variants (#1080)

The existing SugaredLogger.${Level}(..) methods use fmt.Print-style formatting. Add ${Level}ln variants for Println-stye formatting.

Refs #889

Tests pass regardless of codebase directory (#1087)

Support arbitrary hook for fatal logs (#1088)

This adds a new WithFatalHook option that allows specifying arbitrary behavior overrides messages logged with FatalLevel.

This supersedes the previous OnFatal option that relied on a CheckWriteAction enum.

The enum is replaced by a CheckWriteHook--a hook that runs after write.

Refs #1086

Co-authored-by: Sung Yoon Whang sungyoon@uber.com Co-authored-by: Abhinav Gupta abg@uber.com

CheckWriteHook: Don't allow Noop action (#1089)

In #1088, we deprecated the CheckWriteAction enum in favor of the new fully customizable CheckWriteHook. Unfortunately, this introduced a minor regression: it's now possible to set log.Fatal to no-op with WriteThenNoop.

Such a configuration will break code that looks like the following:

f, err := os.Open(..)
if err != nil {
    log.Fatal("Cannot open file", zap.Error(err))
}

// Control flow expects that if we get here,
// f is valid and non-nil.
// That's not the case if Fatal no-ops.

fmt.Println(f.Name())

This change fixes the regression by turning Noops into WriteThenFatal when logging Fatal log messages. This matches the old behavior.

It further clarifies the documentation for CheckWriteHook so that users know to call runtime.Goexit or os.Exit in them. It's still possible to write a custom hook that no-ops the log.Fatal, but it requires a little extra effort from the user to do so.

Create issue templates (#1100)

Upgrade to yaml.v3 3.0.1 (#1102)

Addresses CVE-2022-28948 Supersedes #1101

Replace deprecated ioutil usage (#1103)

Add Must(*Logger, error) *Logger function (#1105)

Fix typo in Must docs (#1108)

CONTRIBUTING: Remove mention of LINTABLE_MINOR_VERSIONS (#1109)

This was removed in #751.

Created at 4 weeks ago
pull request opened
fix typo
Created at 4 weeks ago

fix typo

Signed-off-by: cui fliter imcusg@gmail.com

Created at 4 weeks ago