The Go programming language

Overview

The Go Programming Language

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

Gopher image Gopher image by Renee French, licensed under Creative Commons 3.0 Attributions license.

Our canonical Git repository is located at https://go.googlesource.com/go. There is a mirror of the repository at https://github.com/golang/go.

Unless otherwise noted, the Go source files are distributed under the BSD-style license found in the LICENSE file.

Download and Install

Binary Distributions

Official binary distributions are available at https://golang.org/dl/.

After downloading a binary release, visit https://golang.org/doc/install or load doc/install.html in your web browser for installation instructions.

Install From Source

If a binary distribution is not available for your combination of operating system and architecture, visit https://golang.org/doc/install/source or load doc/install-source.html in your web browser for source installation instructions.

Contributing

Go is the work of thousands of contributors. We appreciate your help!

To contribute, please read the contribution guidelines: https://golang.org/doc/contribute.html

Note that the Go project uses the issue tracker for bug reports and proposals only. See https://golang.org/wiki/Questions for a list of places to ask questions about the Go language.

Issues
  • I have already used the name for *MY* programming language

    I have already used the name for *MY* programming language

    by fmccabe:

    I have been working on a programming language, also called Go, for the last 10 years.
    There have 
    been papers published on this and I have a book.
    
    I would appreciate it if google changed the name of this language; as I do not want to
    have to 
    change my language!
    Unfortunate FrozenDueToAge 
    opened by gopherbot 1095
  • proposal: spec: generic programming facilities

    proposal: spec: generic programming facilities

    This issue proposes that Go should support some form of generic programming. It has the Go2 label, since for Go1.x the language is more or less done.

    Accompanying this issue is a general generics proposal by @ianlancetaylor that includes four specific flawed proposals of generic programming mechanisms for Go.

    The intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like. We hope this will be of help to anyone proposing similar language changes in the future.

    LanguageChange Go2 Proposal NeedsInvestigation FrozenDueToAge generics 
    opened by adg 874
  • Proposal: A built-in Go error check function,

    Proposal: A built-in Go error check function, "try"

    Proposal: A built-in Go error check function, try

    This proposal has been closed. Thanks, everybody, for your input.

    Before commenting, please read the detailed design doc and see the discussion summary as of June 6, the summary as of June 10, and most importantly the advice on staying focussed. Your question or suggestion may have already been answered or made. Thanks.

    We propose a new built-in function called try, designed specifically to eliminate the boilerplate if statements typically associated with error handling in Go. No other language changes are suggested. We advocate using the existing defer statement and standard library functions to help with augmenting or wrapping of errors. This minimal approach addresses most common scenarios while adding very little complexity to the language. The try built-in is easy to explain, straightforward to implement, orthogonal to other language constructs, and fully backward-compatible. It also leaves open a path to extending the mechanism, should we wish to do so in the future.

    [The text below has been edited to reflect the design doc more accurately.]

    The try built-in function takes a single expression as argument. The expression must evaluate to n+1 values (where n may be zero) where the last value must be of type error. It returns the first n values (if any) if the (final) error argument is nil, otherwise it returns from the enclosing function with that error. For instance, code such as

    f, err := os.Open(filename)
    if err != nil {
    	return …, err  // zero values for other results, if any
    }
    

    can be simplified to

    f := try(os.Open(filename))
    

    try can only be used in a function which itself returns an error result, and that result must be the last result parameter of the enclosing function.

    This proposal reduces the original draft design presented at last year's GopherCon to its essence. If error augmentation or wrapping is desired there are two approaches: Stick with the tried-and-true if statement, or, alternatively, “declare” an error handler with a defer statement:

    defer func() {
    	if err != nil {	// no error may have occurred - check for it
    		err = …	// wrap/augment error
    	}
    }()
    

    Here, err is the name of the error result of the enclosing function. In practice, suitable helper functions will reduce the declaration of an error handler to a one-liner. For instance

    defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)
    

    (where fmt.HandleErrorf decorates *err) reads well and can be implemented without the need for new language features.

    The main drawback of this approach is that the error result parameter needs to be named, possibly leading to less pretty APIs. Ultimately this is a matter of style, and we believe we will adapt to expecting the new style, much as we adapted to not having semicolons.

    In summary, try may seem unusual at first, but it is simply syntactic sugar tailor-made for one specific task, error handling with less boilerplate, and to handle that task well enough. As such it fits nicely into the philosophy of Go. try is not designed to address all error handling situations; it is designed to handle the most common case well, to keep the design simple and clear.

    Credits

    This proposal is strongly influenced by the feedback we have received so far. Specifically, it borrows ideas from:

    Detailed design doc

    https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md

    tryhard tool for exploring impact of try

    https://github.com/griesemer/tryhard

    LanguageChange Go2 Proposal error-handling 
    opened by griesemer 810
  • proposal: Go 2: simplify error handling with || err suffix

    proposal: Go 2: simplify error handling with || err suffix

    There have been many proposals for how to simplify error handling in Go, all based on the general complaint that too much Go code contains the lines

    if err != nil {
        return err
    }
    

    I'm not sure that there is a problem here to be solved, but since it keeps coming up, I'm going to put out this idea.

    One of the core problems with most suggestions for simplifying error handling is that they only simplify two ways of handling errors, but there are actually three:

    1. ignore the error
    2. return the error unmodified
    3. return the error with additional contextual information

    It is already easy (perhaps too easy) to ignore the error (see #20803). Many existing proposals for error handling make it easier to return the error unmodified (e.g., #16225, #18721, #21146, #21155). Few make it easier to return the error with additional information.

    This proposal is loosely based on the Perl and Bourne shell languages, fertile sources of language ideas. We introduce a new kind of statement, similar to an expression statement: a call expression followed by ||. The grammar is:

    PrimaryExpr Arguments "||" Expression
    

    Similarly we introduce a new kind of assignment statement:

    ExpressionList assign_op PrimaryExpr Arguments "||" Expression
    

    Although the grammar accepts any type after the || in the non-assignment case, the only permitted type is the predeclared type error. The expression following || must have a type assignable to error. It may not be a boolean type, not even a named boolean type assignable to error. (This latter restriction is required to make this proposal backward compatible with the existing language.)

    These new kinds of statement is only permitted in the body of a function that has at least one result parameter, and the type of the last result parameter must be the predeclared type error. The function being called must similarly have at least one result parameter, and the type of the last result parameter must be the predeclared type error.

    When executing these statements, the call expression is evaluated as usual. If it is an assignment statement, the call results are assigned to the left-hand side operands as usual. Then the last call result, which as described above must be of type error, is compared to nil. If the last call result is not nil, a return statement is implicitly executed. If the calling function has multiple results, the zero value is returned for all result but the last one. The expression following the || is returned as the last result. As described above, the last result of the calling function must have type error, and the expression must be assignable to type error.

    In the non-assignment case, the expression is evaluated in a scope in which a new variable err is introduced and set to the value of the last result of the function call. This permits the expression to easily refer to the error returned by the call. In the assignment case, the expression is evaluated in the scope of the results of the call, and thus can refer to the error directly.

    That is the complete proposal.

    For example, the os.Chdir function is currently

    func Chdir(dir string) error {
    	if e := syscall.Chdir(dir); e != nil {
    		return &PathError{"chdir", dir, e}
    	}
    	return nil
    }
    

    Under this proposal, it could be written as

    func Chdir(dir string) error {
    	syscall.Chdir(dir) || &PathError{"chdir", dir, err}
    	return nil
    }
    

    I'm writing this proposal mainly to encourage people who want to simplify Go error handling to think about ways to make it easy to wrap context around errors, not just to return the error unmodified.

    LanguageChange Go2 Proposal NeedsInvestigation FrozenDueToAge error-handling 
    opened by ianlancetaylor 519
  • spec: add generic programming using type parameters

    spec: add generic programming using type parameters

    We propose adding support for type parameters to Go. This will change the Go language to support a form of generic programming.

    A detailed proposal document has been published, with input from many members of the Go community. We are now taking the next step and proposing that this document become a part of the language.

    A very high level overview of the proposed changes:

    • Functions can have an additional type parameter list that uses square brackets but otherwise looks like an ordinary parameter list: func F[T any](p T) { ... }.
    • These type parameters can be used by the regular parameters and in the function body.
    • Types can also have a type parameter list: type MySlice[T any] []T.
    • Each type parameter has a type constraint, just as each ordinary parameter has a type: func F[T Constraint](p T) { ... }.
    • Type constraints are interface types.
    • The new predeclared name any is a type constraint that permits any type.
    • Interface types used as type constraints can have a list of predeclared types; only type arguments that match one of those types satisfy the constraint.
    • Generic functions may only use operations permitted by their type constraints.
    • Using a generic function or type requires passing type arguments.
    • Type inference permits omitting the type arguments of a function call in common cases.

    For more background on this proposal, see the recent blog post.

    In the discussion on this issue, we invite substantive criticisms and comments, but please try to avoid repeating earlier comments, and please try to avoid simple plus-one and minus-one comments. Instead, add thumbs-up/thumbs-down emoji reactions to comments with which you agree or disagree, or to the proposal as a whole.

    If you don't understand parts of the design please consider asking questions in a forum, rather than on this issue, to keep the discussion here more focused. See https://golang.org/wiki/Questions.

    Proposal Proposal-Accepted Proposal-FinalCommentPeriod generics 
    opened by ianlancetaylor 453
  • proposal: Go 2 error values

    proposal: Go 2 error values

    This issue is for discussion of our Go 2 error values proposal, which is based on our draft designs for error information and formatting.

    This proposal will follow the process outlined in the "Go 2, here we come" blog post: we will have everything ready to go and checked in at the start of the Go 1.13 cycle (Feb 1), we will spend the next three months using those features and soliciting feedback based on actual usage, and then at the start of the release freeze (May 1), we will make the "launch decision" about whether to include the work in Go 1.13 or not.

    Update 2019-05-06: See launch decision here: https://github.com/golang/go/issues/29934#issuecomment-489682919

    Go2 Proposal Proposal-Accepted NeedsInvestigation 
    opened by jba 435
  • Proposal: Alias declarations for Go

    Proposal: Alias declarations for Go

    Abstract We propose to add alias declarations to the Go language. An alias declaration introduces an alternative name for an object (type, function, etc.) declared elsewhere. Aliases simplify splitting packages because clients can be updated incrementally, which is crucial for large-scale refactoring.

    Motivation During refactoring, it is often desirable to split an existing package into multiple packages. Exported objects such as types, functions, etc. that move from one package to another will require clients to be updated accordingly. In a continuous build environment, build breakages are the consequence if not all clients can be updated simultaneously.

    This is a real issue in large-scale systems such as we find at Google and other companies because the number of dependencies can grow into the hundreds if not thousands. Client packages may be under control of different teams and evolve at different speeds. Updating a large number of client packages simultaneously may be close to impossible. This is an effective barrier to system evolution and maintenance.

    Go trivially permits constants to refer to other constants, possibly from another package. Similarly, if a function moves from one package to another, a “forwarder” function that simply calls the moved function may be left behind so clients can continue to refer to the old package. These techniques enable incremental update of clients without breaking a continuous build system.

    No such work-around exists for types and variables. To address the issue, we propose the notion of a general alias declaration. An alias declaration introduces an alternative name for an object (constant, type, variable, or function) declared elsewhere, possibly in another package. An alias may be exported, so clients can refer to on object via the package that declares the object, or any package exporting an alias to an object, and get the same object.

    Alias declarations are designed such that they fit seamlessly in the existing language spec without invalidating backward-compatibility or any other aspect of the Go 1 guarantees. Tools that process Go code which will require changes to support alias declarations.

    Alias declarations are a compile-time mechanism and don’t incur any runtime costs.

    The design document (forthcoming) describes alias declarations in detail.

    Added July 25, 2016: Link to design document: https://github.com/golang/proposal/blob/master/design/16339-alias-decls.md

    Proposal 
    opened by griesemer 371
  • spec: generics: use type sets to remove type keyword in constraints

    spec: generics: use type sets to remove type keyword in constraints

    We propose clarifications for the semantics of constraint satisfaction in the generics proposal. We also propose changing the syntax of type lists to remove the type keyword and to explicitly specify when type arguments should match on underlying types.

    The changes this would make to the current generics proposal document can be seen in https://golang.org/cl/306689.

    Background

    The current generics proposal proposes a new syntax for type lists within interfaces. A type list within an interface is the keyword type followed by a list of types separated by commas. Type lists are only permitted in interface types that are used as type constraints. For example:

    // SignedInteger is a type constraint that permits any
    // signed integer type.
    type SignedInteger interface {
    	type int, int8, int16, int32, int64
    }
    

    A type argument matches a constraint with a type list if

    1. The type argument implements the interface ignoring the type list, and
    2. either the type argument or its underlying type is identical to one of the types in the type list.

    This rule was adopted in part to support permitting type lists in ordinary interface types, not only in constraints. However, discussion has made clear that the rule is too subtle. This suggests that it is too subtle not just for use in ordinary interface types, but also for use in constraints.

    The behavior when embedding interfaces with type lists is also subtle.

    We can do better.

    Type sets

    We start by defining a type set for all types. We will define what it means for a type to implement an interface in terms of type sets, resulting in a behavior that is equivalent to the current definition based on method sets.

    Every type has an associated type set. The type set of an ordinary non-interface type T is simply the set {T} which contains just T itself. The type set of an interface type (in this section we only discuss ordinary interface types, without type lists) is the set of all types that declare all the methods of the interface.

    Note that the type set of an interface type is an infinite set. For any given type T and interface type IT it's easy to tell whether T is in the type set of IT (by checking whether all methods of IT are declared by T), but there is no reasonable way to enumerate all the types in the type set of IT. The type IT is a member of its own type set because an interface inherently declares all of its own methods. The type set of the empty interface interface{} is the set of all possible types.

    With this idea of type sets, we can restate what it means for a type T to implement an interface type IT: T implements IT if T is a member of the type set of IT. Since the type set of IT is the set of all types that declare all the methods of the interface, T is a member of the type set of IT if and only if the method set of T is a (possibly improper) superset of the method set of IT, which is the standard definition of implementing an interface.

    Now let's consider embedded interfaces. For a case like type O1 interface{ E }, the type set of O1 is the same as the type set of E. The case type O2 interface{ E1; E2 } is more interesting: the type set of O2 is the intersection of the type sets of E1 and E2. To see this, observe that the type set of E1 is the set of all types that implement all the methods of E1, and similarly for E2. What we want for the type set of O2 is the set of all types that implement all the methods of O2. The methods of O2 are all of the methods of E1 combined with all of the methods of E2. The set of types that implement all the methods of both E1 and E2 is the intersection of the type sets of E1 and E2.

    Note that listing a method in an interface type definition in the usual way is, from a type set perspective, indistinguishable from embedding an interface that declares just that method. Although a method by itself is not a type, for our purposes we can say that the type set for a method listed explicitly in an interface type definition is exactly the type set of an interface type with only that method: the set of all types that implement that method. The advantage of doing this is that we can now say that the type set of an interface type is exactly the intersection of the type sets of each element listed in the interface.

    We've now described type sets, and we've explained the meaning of implementing an interface in terms of type sets. None of this changes the language in any way, but it serves as background and motivation for the next steps.

    Proposal

    We propose to replace type lists as defined by the generics proposal with three new, simpler, ideas.

    An interface type that is used as a constraint, or that is embedded in a constraint, is permitted to embed some additional constructs that we will call interface elements. An interface element can be:

    1. Any type, not just an interface type.
    2. A new syntactic construct called an approximation element.
    3. A new syntactic construct called a union element.

    With these new elements we will be able to state simply that a type argument A satisfies a constraint C exactly when A implements the interface type C, or, in terms of type sets, exactly when A is a member of the type set of C.

    First, we propose that an interface type used as a constraint is permitted to embed a non-interface type. For example: type Integer interface{ int }. As discussed in the previous section, the type set of an interface type is the intersection of the type sets of the elements of the interface. The type set of int is simply {int}. This means that the type set of Integer is also {int}. This constraint can be satisfied by any type that is a member of the set {int}. There is exactly one such type: int.

    Of course, that is useless by itself. For constraint satisfaction, we want to be able to say not just int, but "any type whose underlying type is int." To implement this, we propose a new syntactic construct, which may be embedded in an interface type used as a constraint. This is an approximation element, written as ~T. The type set of an approximation ~T is the set of all types whose underlying type is T. An approximation ~T is only valid if the underlying type of T is itself T; this is discussed in more detail below.

    For example: type AnyInt interface{ ~int }. The type set of ~int, and therefore the type set of AnyInt, is the set of all types whose underlying type is int. For example, if MyInt is defined as type MyInt int, then MyInt used as a type argument will satisfy the constraint AnyInt.

    The final step is another new syntactic construct that may be embedded in an interface type used as a constraint: a union element. A union element is written as a sequence of types or approximation elements separated by vertical bars (|). For example: int | float32 or ~int8 | ~int16 | ~int32 | ~int64. The type set of a union element is the union of the type sets of each element in the sequence. The types and elements listed in a union must all be different: no two types may be identical, and no two approximation elements ~T1 and ~T2 may have T1 identical to T2. For example:

    type PredeclaredSignedInteger interface {
    	int | int8 | int16 | int32 | int64
    }
    

    The type set of this union element is the set {int, int8, int16, int32, int64}. Since the union is the only element of PredeclaredSignedInteger, that is also the type set of PredeclaredSignedInteger. This constraint can be satisfied by any of those five types.

    Here is an example using approximation elements:

    type SignedInteger interface {
    	~int | ~int8 | ~int16 | ~int32 | ~int64
    }
    

    The type set of this constraint is the set of all types whose underlying type is one of int, int8, int16, int32, or int64. Any of those types will satisfy this constraint. This is the equivalent of the notation used in the generics proposal

    interface {
    	type int, int8, int16, int32, int64
    }
    

    The use of explicit approximation elements clarifies when we are matching on underlying types, the use of | instead of , emphasizes that this is a union of elements, and the type keyword can be omitted by permitting constraints to embed non-interface elements.

    The purpose of introducing type lists in the generics proposal was to specify the operations available to type parameters in parameterized functions. This is easy to define based on the idea of type sets. Given a type parameter P with a constraint C, a parameterized function is permitted to use an operation with a value of type P if the operation is permitted for every member of the type set of C.

    That is the complete proposal: a conceptual change to use type sets, and three new syntax changes. We will now mention some details and ramifications.

    Approximation elements

    The new ~T syntax will be the first use of ~ as a token in Go.

    Since ~T means the set of all types whose underlying type is T, it will be an error to use ~T with a type T whose underlying type is not itself. Types whose underlying types are themselves are:

    1. Type literals, such as []byte or struct{ f int }.
    2. Predeclared types, such as int or string.

    We do not permit ~P where P is a type parameter.

    The type set of ~T is an infinite set of types.

    The ~ will bind more tightly than |. ~T1 | T2 means (~T1) | (T2), not ~(T1 | T2) (note that ~(T1 | T2) is not syntactically valid)..

    The new syntax is

    InterfaceType = "interface" "{" { ( MethodSpec | InterfaceTypeName | ConstraintElem ) ";" } "}" .
    ConstraintElem = ConstraintTerm { "|" ConstraintTerm } .
    ConstraintTerm = [ "~" ] Type .
    

    Embedding constraints

    A constraint can embed another constraint. Union elements can include constraints.

    // Signed is a constraint whose type set is any signed integer type.
    type Signed interface {
    	~int | ~int8 | ~int16 | ~int32 | ~int64
    }
    
    // Unsigned is a constraint whose type set is any unsigned integer type.
    type Unsigned interface {
    	~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr
    }
    
    // Float is a constraint whose type set is any floating point type.
    type Float interface {
    	~float32 | ~float64
    }
    
    // Ordered is a constraint whose type set is any ordered type.
    // That is, any type that supports the < operator.
    type Ordered interface {
    	Signed | Unsigned | Float | ~string
    }
    

    Interface types in union constraint elements

    The type set of a union element is the union of the type sets of all elements in the union. For most types T the type set of T is simply T itself. For interface types (and approximation elements), however, this is not the case.

    The type set of an interface type that does not embed a non-interface element is the set of all types that implement the interface, including the interface type itself. Using such an interface type in a union element will add that type set to the union. For example:

    type Stringish interface {
    	string | fmt.Stringer
    }
    

    The type set of Stringish will be the type string and all types that implement fmt.Stringer. Any of those types (including fmt.Stringer itself) will be permitted as a type argument for this constraint. No operations will be permitted for a value of a type parameter that uses Stringish as a constraint (other than operations supported by all types). This is because fmt.Stringer is in the type set of Stringish, and fmt.Stringer, an interface type, does not support any type-specific operations. The operations permitted by Stringish are those operations supported by all the types in the type set, including fmt.Stringer, so in this case there are no operations other than those supported by all types. A parameterized function that uses this constraint will have to use type assertions or reflection in order to use the values. Still, this may be useful in some cases for stronger static type checking. The main point is that it follows directly from the definition of type sets and constraint satisfaction.

    Combining embedded non-interfaces with methods

    A constraint can embed a constraint element and also list methods.

    type StringableSignedInteger interface {
    	~int | ~int8 | ~int16 | ~int32 | ~int64
    	String() string
    }
    

    The rules for type sets define what this means. The type set of the union element is the set of all types whose underlying type is one of the predeclared signed integer types. The type set of String() string is the set of all types that declare that method. The type set of StringableSignedInteger is the intersection of those two type sets. The result is the set of all types whose underlying type is one of the predeclared signed integer types and that declare the method String() string. A function that uses a parameterized type P that uses StringableSignedInteger as a constraint may use the operations permitted for any integer type (+, *, and so forth) on a value of type P. It may also call the String method on a value of type P to get back a string.

    Empty type sets

    It is possible to write a constraint with an empty type set. There is no type argument that will satisfy such a constraint. ~~The compiler should give an error whenever it detects such an unsatisfiable constraint. However, in general a compiler may not be able to detect all such cases.~~ It is not feasible to detect all such cases, though they can't be used with any type argument. It may be appropriate to have vet give an error for cases that it can detect.

    // Unsatisfiable is an unsatisfiable constraint with an empty type set.
    // No predeclared types have any methods.
    // If this used ~int | ~float32 the type set would not be empty.
    type Unsatisfiable interface {
    	int | float32
    	String() string
    }
    

    Method sets of constraint elements

    Much as the type set of an interface type is the intersection of the type sets of the elements of the interface, the method set of an interface type can be defined as the union of the method sets of the elements of the interface. In most cases, an embedded element will have no methods, and as such will not contribute any methods to the interface type. That said, for completeness, we'll note that the method set of ~T is the method set of T. The method set of a union element is the intersection of the method sets of the elements of the union. These rules are implied by the definition of type sets, but they are not needed for understanding the behavior of constraints.

    Possible future step: permitting constraints as ordinary interface types

    We have proposed that constraints can embed some additional elements. With this proposal, any interface type that embeds anything other than an interface type can only be used as a constraint or as an embedded element in another constraint. A natural next step would be to permit using interface types that embed any type, or that embed these new elements, as an ordinary type, not just as a constraint.

    We are not proposing that today. But the rules for type sets and methods set above describe how they would behave. Any type that is an element of the type set could be assigned to such an interface type. A value of such an interface type would permit calling any member of the corresponding method set.

    This would permit a version of what other languages call sum types or union types. It would be a Go interface type to which only specific types could be assigned. Such an interface type could still take the value nil, of course, so it would not be quite the same as a typical sum type.

    In any case, this is something to consider in a future proposal, not this one.

    Proposal Proposal-Accepted Proposal-FinalCommentPeriod generics 
    opened by ianlancetaylor 365
  • proposal: leave

    proposal: leave "if err != nil" alone?

    The Go2 proposal #32437 adds new syntax to the language to make the if err != nil { return ... } boilerplate less cumbersome.

    There are various alternative proposals: #32804 and #32811 as the original one is not universally loved.

    To throw another alternative in the mix: Why not keep it as is?

    I've come to like the explicit nature of the if err != nil construct and as such I don't understand why we need new syntax for this. Is it really that bad?

    Proposal FrozenDueToAge Proposal-Hold error-handling 
    opened by miekg 314
  • proposal: cmd/go: make major versions optional in import paths

    proposal: cmd/go: make major versions optional in import paths

    Semantic Import Versioning (SIV) is a novel idea for supporting multiple versions of a package within the same program. To my knowledge and experience, it's the first example of a strategy for supporting multiple versions of a project / dependency in the same application. More importantly though, its clever introductory design allowed it to offer multi-versioned packages in a Go program while maintaining Go's compatibility guarantee.

    Multi-versioned packages in a single program can be quite powerful -- for instance, imagine a Web service where you'd like to maintain backwards compatible support for your consumers, you can simply use an older import path from the same origin repository and versioning control, and quite elegantly continue to support those older API versions.

    Although SIV may be an elegant solution in the scenario described above, it also adds unnecessary complexity, cost, code noise, discoverability and ergonomics for the majority of packages (publicly and privately) which may not ever have a mutli-version requirement (I'd argue most packages, and simply we can look to other ecosystems to see this is true). I am sure the Go team has heard a lot of feedback on the friction of SIV. https://twitter.com/peterbourgon/status/1236657048714182657?s=21 and https://peter.bourgon.org/blog/2020/09/14/siv-is-unsound.html offers some excellent points as well.

    Clearly there is a case for SIV as an elegant solution for supporting multiple versions of a package in a single application, and there is also a strong case to make SIV optional.

    It's clear to me there is a design trade-off at hand, and there is no single correct answer. As I consider the 80/20 rule in making an architectural decision between two trade-offs of capability and usability, I prefer to go with the 80% case so long as it doesn't forego the 20% ability. Which design is the best to optimize for if we can still support both? In the case with Go today, its not possible to opt-out of SIV, or opt-into SIV -- I believe both approaches can yield a happy solution. If we were starting from the beginning, I'd suggest to have SIV be opt-in, but maybe at this point its better for it to be an opt-out design to maintain backwards compatibility with history.


    I'd like to propose a path to make SIV opt-out at the level of an application developer consuming a package, while being backwards compatible with current packages and tools.

    I'd like to use https://github.com/go-chi/chi as an example for this proposal which adopted semver ahead of Go modules and SIV, and is built for developer simplicity and ergonomics intended for pro Go developers, but also making it familiar and accessible for developers who are new to Go -- these are my design goals for chi as an author and maintainer as started back in 2017. My present goal is to release Chi v5 without a SIV requirement and the only way I can do so is with the proposal below:


    Proposal, by example:

    github.com/go-chi/chi/go.mod:

    module github.com/go-chi/chi/v5
    
    go 1.16
    

    then, git tag chi as v5.0.0 to make the release.

    Application developers may consume the package via go get github.com/go-chi/[email protected] or with @v5 or @v5.0.0 and the expected import path will be "github.com/go-chi/chi", however "github.com/go-chi/chi/v5" import path would also be valid and usable.

    In the above case, we're specifying the go.mod as expected with current behaviour with SIV from a library perspective. However, from the application perspective when fetching or consuming the library, I may opt-out of the "/v5" suffix in the import path and only adopt it in the scenario when I'd like to support "/v5" and "/v4" (or some other prior version), where I require the handling of multiple versions simultaneously in my program.

    I believe the implementation of the above to be backwards compatible as developers would continue to use "github.com/go-chi/chi/v5" with older version of Go as SIV is implied, but optionally developers could make their choice of multiple-version support for the package by handling the import paths themselves and import "github.com/go-chi/chi" to utilize v5.x.x as specified by go.mod.

    I believe changes to the Go toolchain for such support would be minimal and would be isolated to the components which build module lists.

    Thank you for reading my proposal, and its consideration.

    Proposal modules 
    opened by pkieltyka 258
  • runtime: FreeBSD memory corruption involving fork system call

    runtime: FreeBSD memory corruption involving fork system call

    Please answer these questions before submitting your issue. Thanks!

    1. What version of Go are you using (go version)?

    go version go1.6.2 freebsd/amd64

    1. What operating system and processor architecture are you using (go env)?
    GOARCH="amd64"
    GOBIN=""
    GOEXE=""
    GOHOSTARCH="amd64"
    GOHOSTOS="freebsd"
    GOOS="freebsd"
    GOPATH=""
    GORACE=""
    GOROOT="/usr/local/go"
    GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
    GO15VENDOREXPERIMENT="1"
    CC="cc"
    GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
    CXX="clang++"
    
    1. What did you do?
    package main
    
    /* stdlib includes */
    import (
            "fmt"
            "os/exec"
    )
    
    func run(done chan struct{}) {
            cmd := exec.Command("true")
            if err := cmd.Start(); err != nil {
                    goto finished
            }
    
            cmd.Wait()
    
    finished:
            done <- struct{}{}
            return
    }
    
    func main() {
            fmt.Println("Starting a bunch of goroutines...")
    
            // 8 & 16 are arbitrary
            done := make(chan struct{}, 16)
    
            for i := 0; i < 8; i++ {
                    go run(done)
            }
    
            for {
                    select {
                    case <-done:
                            go run(done)
                    }
            }
    }
    
    1. What did you expect to see?

    I expect this strange program to spawn instances of /bin/true in parallel, until I stop it.

    1. What did you see instead?

    Various types of panics caused by what looks to be corruption within the finalizer lists, caused by what I am assuming is based on race conditions. These panics can happen as quickly as 2 minutes, or much longer. 10 minutes seems a good round number.

    Occasionally addspecial gets stuck in an infinite loop holding the lock, and the process wedges. This is illustrated in log 1462933614, with x.next pointing to x. This appears to be corruption of that data structure. I have seen processes in this state run for 22 hours.

    I understand there is some trepidation expressed in issue #11485 around the locking of the data structures involved.

    Here are some sample messages:

    • fatal error: runtime.SetFinalizer: finalizer already set
    • runtime: nonempty check fails b.log[0]= 0 b.log[1]= 0 b.log[2]= 0 b.log[3]= 0 fatal error: workbuf is empty

    1462926841-SetFinalizer-ex1.txt 1462926969-SetFinalizer-ex2.txt 1462933295-nonempty-check-fails.txt 1462933614-wedged.txt

    This was run on an 8-core processor, and a 4-core 8-thread processor with ECC RAM, similar results.

    Additionally, while this example is an extreme, it also represents the core functionality of a project I've been working on part-time for many months. I'm happy to provide any further assistance diagnosing this issue - I'm very invested!

    help wanted OS-FreeBSD NeedsInvestigation FrozenDueToAge 
    opened by derekmarcotte 243
  • access: may-start-trybots

    access: may-start-trybots

    Hi,

    I'd like to request "may-start-trybots" access https://go-review.googlesource.com/#/admin/groups/1030,members for [email protected]. Thanks.

    See https://go.dev/wiki/GerritAccess

    cc @golang/release @dmitshur

    opened by cuiweixie 0
  • cmd/compile: MacOS ARM: nosplit stack overflow with -gcflags

    cmd/compile: MacOS ARM: nosplit stack overflow with -gcflags "all=-N -l" -race (Goland debug)

    What version of Go are you using (go version)?

    $ go version
    go version go1.18.5 darwin/arm64
    
    

    Does this issue reproduce with the latest release?

    Yes (go 1.19)

    $ go version
    go version go1.19 darwin/arm64
    

    What operating system and processor architecture are you using (go env)?

    go env Output
    $ go env
    GO111MODULE=""
    GOARCH="arm64"
    GOBIN=""
    GOCACHE="/Users/ghostiam/Library/Caches/go-build"
    GOENV="/Users/ghostiam/Library/Application Support/go/env"
    GOEXE=""
    GOEXPERIMENT=""
    GOFLAGS=""
    GOHOSTARCH="arm64"
    GOHOSTOS="darwin"
    GOINSECURE=""
    GOMODCACHE="/Users/ghostiam/projects/golang/pkg/mod"
    GONOPROXY=""
    GONOSUMDB=""
    GOOS="darwin"
    GOPATH="/Users/ghostiam/projects/golang"
    GOPRIVATE=""
    GOPROXY="http://localhost:8123"
    GOROOT="/Users/ghostiam/projects/golang/sdk/go1.19"
    GOSUMDB="sum.golang.org"
    GOTMPDIR=""
    GOTOOLDIR="/Users/ghostiam/projects/golang/sdk/go1.19/pkg/tool/darwin_arm64"
    GOVCS=""
    GOVERSION="go1.19"
    GCCGO="gccgo"
    AR="ar"
    CC="clang"
    CXX="clang++"
    CGO_ENABLED="1"
    GOMOD="/Users/ghostiam/Desktop/test/go.mod"
    GOWORK=""
    CGO_CFLAGS="-g -O2"
    CGO_CPPFLAGS=""
    CGO_CXXFLAGS="-g -O2"
    CGO_FFLAGS="-g -O2"
    CGO_LDFLAGS="-g -O2"
    PKG_CONFIG="pkg-config"
    GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/pc/st46ghc9375gx_q1ktbvpq900000gn/T/go-build1017110940=/tmp/go-build -gno-record-gcc-switches -fno-common"
    

    What did you do?

    go build -gcflags "all=-N -l" -race -v

    2 lines of code: https://go.dev/play/p/v-LC84qDHo4

    package main
    
    import (
    	"os/exec"
    )
    
    func main() {
    	cmd := exec.Command("echo", "test")
    	_ = cmd.Start()
    }
    

    What did you expect to see?

    Successful build and debug

    What did you see instead?

    go 1.18.5 Output
    $ go build  -gcflags "all=-N -l" -race -v
    test
    # test
    runtime.fatalthrow: nosplit stack overflow
    	792	assumed on entry to syscall.ptrace<1> (nosplit)
    	664	after syscall.ptrace<1> (nosplit) uses 128
    	456	after syscall.ptrace1<1> (nosplit) uses 208
    	264	after syscall.syscall6<1> (nosplit) uses 192
    	232	after runtime.entersyscall<1> (nosplit) uses 32
    	168	after runtime.reentersyscall<1> (nosplit) uses 64
    	136	after runtime.save<1> (nosplit) uses 32
    	104	after runtime.badctxt<1> (nosplit) uses 32
    	56	after runtime.throw<1> (nosplit) uses 48
    	-8	after runtime.fatalthrow<1> (nosplit) uses 64
    
    go 1.19 Output
    $ go build  -gcflags "all=-N -l" -race -v
    unicode/utf8
    math/bits
    internal/itoa
    internal/unsafeheader
    internal/goos
    internal/goarch
    unicode
    internal/goexperiment
    runtime/internal/math
    runtime/internal/sys
    internal/abi
    sync/atomic
    internal/cpu
    math
    runtime/internal/atomic
    internal/bytealg
    runtime
    internal/reflectlite
    internal/race
    sync
    internal/testlog
    errors
    sort
    internal/oserror
    path
    io
    strconv
    syscall
    bytes
    strings
    internal/syscall/execenv
    internal/syscall/unix
    time
    runtime/cgo
    context
    io/fs
    internal/poll
    os
    internal/godebug
    path/filepath
    os/exec
    runtime/race
    test
    # test
    syscall.ptrace: nosplit stack over 792 byte limit
    syscall.ptrace<1>
        grows 128 bytes, calls syscall.ptrace1<1>
            grows 208 bytes, calls syscall.syscall6<1>
                grows 192 bytes, calls runtime.entersyscall<1>
                    grows 32 bytes, calls runtime.reentersyscall<1>
                        grows 64 bytes, calls runtime.save<1>
                            grows 32 bytes, calls runtime.badctxt<1>
                                grows 32 bytes, calls runtime.throw<1>
                                    grows 48 bytes, calls runtime.fatalthrow<1>
                                        grows 64 bytes, calls runtime.systemstack<0>
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.abort<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                        grows 64 bytes, calls runtime.casgstatus<1>
                            grows 80 bytes, calls runtime.nanotime<1>
                                grows 32 bytes, calls runtime.nanotime1<0>
                                    grows 48 bytes, calls runtime.libcCall<1>
                                        grows 64 bytes, calls runtime.(*guintptr).set<1>
                                        56 bytes over limit
                                        grows 64 bytes, calls runtime.asmcgocall<0>
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                            grows 80 bytes, calls runtime.nanotime<1>
                                grows 32 bytes, calls runtime.nanotime1<0>
                                    grows 48 bytes, calls runtime.libcCall<1>
                                        grows 64 bytes, calls runtime.(*guintptr).set<1>
                                        56 bytes over limit
                                        grows 64 bytes, calls runtime.asmcgocall<0>
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                            grows 80 bytes, calls runtime.osyield<1>
                                grows 32 bytes, calls runtime.usleep<0>
                                    grows 32 bytes, calls runtime.libcCall<1>
                                        grows 64 bytes, calls runtime.(*guintptr).set<1>
                                        40 bytes over limit
                                        grows 64 bytes, calls runtime.asmcgocall<0>
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                56 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            56 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                56 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            56 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                56 bytes over limit
                            grows 80 bytes, calls runtime.nanotime<1>
                                grows 32 bytes, calls runtime.nanotime1<0>
                                    grows 48 bytes, calls runtime.libcCall<1>
                                        grows 64 bytes, calls runtime.(*guintptr).set<1>
                                        56 bytes over limit
                                        grows 64 bytes, calls runtime.asmcgocall<0>
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                            grows 80 bytes, calls runtime.nanotime<1>
                                grows 32 bytes, calls runtime.nanotime1<0>
                                    grows 48 bytes, calls runtime.libcCall<1>
                                        grows 64 bytes, calls runtime.(*guintptr).set<1>
                                        56 bytes over limit
                                        grows 64 bytes, calls runtime.asmcgocall<0>
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                            grows 80 bytes, calls runtime.nanotime<1>
                                grows 32 bytes, calls runtime.nanotime1<0>
                                    grows 48 bytes, calls runtime.libcCall<1>
                                        grows 64 bytes, calls runtime.(*guintptr).set<1>
                                        56 bytes over limit
                                        grows 64 bytes, calls runtime.asmcgocall<0>
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            72 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                72 bytes over limit
                            grows 80 bytes, calls runtime.throw<1>
                                grows 48 bytes, calls runtime.fatalthrow<1>
                                    grows 64 bytes, calls runtime.systemstack<0>
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.abort<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                        grows 64 bytes, calls runtime.save<1>
                            grows 32 bytes, calls runtime.badctxt<1>
                                grows 32 bytes, calls runtime.throw<1>
                                    grows 48 bytes, calls runtime.fatalthrow<1>
                                        grows 64 bytes, calls runtime.systemstack<0>
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.abort<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                        grows 64 bytes, calls runtime.save<1>
                            grows 32 bytes, calls runtime.badctxt<1>
                                grows 32 bytes, calls runtime.throw<1>
                                    grows 48 bytes, calls runtime.fatalthrow<1>
                                        grows 64 bytes, calls runtime.systemstack<0>
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.abort<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                        grows 64 bytes, calls runtime.save<1>
                            grows 32 bytes, calls runtime.badctxt<1>
                                grows 32 bytes, calls runtime.throw<1>
                                    grows 48 bytes, calls runtime.fatalthrow<1>
                                        grows 64 bytes, calls runtime.systemstack<0>
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.abort<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                        grows 64 bytes, calls runtime.save<1>
                            grows 32 bytes, calls runtime.badctxt<1>
                                grows 32 bytes, calls runtime.throw<1>
                                    grows 48 bytes, calls runtime.fatalthrow<1>
                                        grows 64 bytes, calls runtime.systemstack<0>
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.abort<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls gosave_systemstack_switch<21>
                                                grows 0 bytes, calls runtime.abort<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                                            grows 16 bytes, calls indirect
                                                grows 0 bytes, calls runtime.morestack<0>
                                                24 bytes over limit
                                            grows 16 bytes, calls runtime.save_g<0>
                                            24 bytes over limit
                grows 192 bytes, calls runtime.exitsyscall<1>
                    grows 64 bytes, calls runtime.exitsyscallfast<1>
                        grows 80 bytes, calls runtime.wirep<1>
                            grows 64 bytes, calls runtime.throw<1>
                                grows 48 bytes, calls runtime.systemstack<0>
                                    grows 16 bytes, calls indirect
                                        grows 0 bytes, calls runtime.morestack<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.abort<0>
                                    8 bytes over limit
                                    grows 16 bytes, calls gosave_systemstack_switch<21>
                                        grows 0 bytes, calls runtime.abort<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.save_g<0>
                                    8 bytes over limit
                                    grows 16 bytes, calls indirect
                                        grows 0 bytes, calls runtime.morestack<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.save_g<0>
                                    8 bytes over limit
                                grows 48 bytes, calls runtime.fatalthrow<1>
                                    grows 64 bytes, calls runtime.systemstack<0>
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            72 bytes over limit
                                        grows 16 bytes, calls runtime.abort<0>
                                        72 bytes over limit
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            72 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        72 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            72 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        72 bytes over limit
                            grows 64 bytes, calls runtime.throw<1>
                                grows 48 bytes, calls runtime.systemstack<0>
                                    grows 16 bytes, calls indirect
                                        grows 0 bytes, calls runtime.morestack<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.abort<0>
                                    8 bytes over limit
                                    grows 16 bytes, calls gosave_systemstack_switch<21>
                                        grows 0 bytes, calls runtime.abort<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.save_g<0>
                                    8 bytes over limit
                                    grows 16 bytes, calls indirect
                                        grows 0 bytes, calls runtime.morestack<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.save_g<0>
                                    8 bytes over limit
                                grows 48 bytes, calls runtime.fatalthrow<1>
                                    grows 64 bytes, calls runtime.systemstack<0>
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            72 bytes over limit
                                        grows 16 bytes, calls runtime.abort<0>
                                        72 bytes over limit
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            72 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        72 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            72 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        72 bytes over limit
                    grows 64 bytes, calls runtime.casgstatus<1>
                        grows 80 bytes, calls runtime.nanotime<1>
                            grows 32 bytes, calls runtime.nanotime1<0>
                                grows 48 bytes, calls runtime.libcCall<1>
                                    grows 64 bytes, calls runtime.(*guintptr).set<1>
                                    24 bytes over limit
                                    grows 64 bytes, calls runtime.asmcgocall<0>
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                        grows 80 bytes, calls runtime.nanotime<1>
                            grows 32 bytes, calls runtime.nanotime1<0>
                                grows 48 bytes, calls runtime.libcCall<1>
                                    grows 64 bytes, calls runtime.(*guintptr).set<1>
                                    24 bytes over limit
                                    grows 64 bytes, calls runtime.asmcgocall<0>
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                        grows 80 bytes, calls runtime.osyield<1>
                            grows 32 bytes, calls runtime.usleep<0>
                                grows 32 bytes, calls runtime.libcCall<1>
                                    grows 64 bytes, calls runtime.(*guintptr).set<1>
                                    8 bytes over limit
                                    grows 64 bytes, calls runtime.asmcgocall<0>
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            24 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        24 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            24 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        24 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            24 bytes over limit
                        grows 80 bytes, calls runtime.nanotime<1>
                            grows 32 bytes, calls runtime.nanotime1<0>
                                grows 48 bytes, calls runtime.libcCall<1>
                                    grows 64 bytes, calls runtime.(*guintptr).set<1>
                                    24 bytes over limit
                                    grows 64 bytes, calls runtime.asmcgocall<0>
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                        grows 80 bytes, calls runtime.nanotime<1>
                            grows 32 bytes, calls runtime.nanotime1<0>
                                grows 48 bytes, calls runtime.libcCall<1>
                                    grows 64 bytes, calls runtime.(*guintptr).set<1>
                                    24 bytes over limit
                                    grows 64 bytes, calls runtime.asmcgocall<0>
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                        grows 80 bytes, calls runtime.nanotime<1>
                            grows 32 bytes, calls runtime.nanotime1<0>
                                grows 48 bytes, calls runtime.libcCall<1>
                                    grows 64 bytes, calls runtime.(*guintptr).set<1>
                                    24 bytes over limit
                                    grows 64 bytes, calls runtime.asmcgocall<0>
                                        grows 16 bytes, calls gosave_systemstack_switch<21>
                                            grows 0 bytes, calls runtime.abort<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                                        grows 16 bytes, calls runtime.save_g<0>
                                        40 bytes over limit
                                        grows 16 bytes, calls indirect
                                            grows 0 bytes, calls runtime.morestack<0>
                                            40 bytes over limit
                        grows 80 bytes, calls runtime.throw<1>
                            grows 48 bytes, calls runtime.fatalthrow<1>
                                grows 64 bytes, calls runtime.systemstack<0>
                                    grows 16 bytes, calls indirect
                                        grows 0 bytes, calls runtime.morestack<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.abort<0>
                                    8 bytes over limit
                                    grows 16 bytes, calls gosave_systemstack_switch<21>
                                        grows 0 bytes, calls runtime.abort<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.save_g<0>
                                    8 bytes over limit
                                    grows 16 bytes, calls indirect
                                        grows 0 bytes, calls runtime.morestack<0>
                                        8 bytes over limit
                                    grows 16 bytes, calls runtime.save_g<0>
                                    8 bytes over limit
    

    Without -race everything compiles fine.

    compiler/runtime 
    opened by ghostiam 1
  • crypto/x509: err instead of panic on invalid curve

    crypto/x509: err instead of panic on invalid curve

    in marshalPublicKey case *ecdsa.PublicKey: because elliptic.Marshal() was called before oidFromNamedCurve we would panic if the curve was invalid. By calling oidFromNamedCurve first we can return early with a meaningfull error

    Fixes #54288

    opened by FnuGk 2
  • crypto/x509: panics on invalid curve instead of returning error

    crypto/x509: panics on invalid curve instead of returning error

    What version of Go are you using (go version)?

    $ go version 1.19
    
    

    What did you do?

    In go 1.19 crypto/elliptic will now panic when operating on invalid curve points. This is great as it avoids undefined behavior, but crypto/x509 will now panic in marshalPublicKey in the case *ecdsa.PublicKey: where it previosly would return errors.New("x509: unsupported elliptic curve") as it calls elliptic.Marshal(pub.Curve, pub.X, pub.Y) before it checks oidFromNamedCurve(pub.Curve).

    So simply switching those two calls around should fix the issue.

    Meanwhile clients have to manually check if their key satisfies IsOnCurve before calling something like x509.MarshalPKIXPublicKey where in previous versions of go you could rely on an error being returned instead of a panic.

    opened by FnuGk 1
  • runtime: cleanup timer codes

    runtime: cleanup timer codes

    The existing implementation has a poor structure and is a mess. I just moved exist codes to seprated files and structures to improve code and logic readability. No logic has been changed in this cleanup.

    Updates #53953

    opened by OmidHekayati 2
Owner
Go
The Go Programming Language
Go
Goal is a toolkit for high productivity web development in Go language in the spirit of Revel Framework that is built around the concept of code generation.

Goal Goal is a set of tools for high productivity web development in Go language. Goal, being mostly inspired by Revel Framework and its discussions,

null 88 Sep 27, 2021
T# Programming Language. Something like Porth, Forth but written in Go. Stack-oriented programming language.

The T# Programming Language WARNING! THIS LANGUAGE IS A WORK IN PROGRESS! ANYTHING CAN CHANGE AT ANY MOMENT WITHOUT ANY NOTICE! Something like Forth a

T# 92 Jun 29, 2022
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

null 1 Dec 27, 2021
Yayx programming language is begginer friendly programming language.

Yayx Yayx programming language is begginer friendly programming language. What have yayx: Easy syntax Dynamic types Can be compiled to outhers program

Yayx Programming Language 7 May 20, 2022
Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like.

Advent of Code 2021 Advent of Code is an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved

Kemal Ogun Isik 0 Dec 2, 2021
Zach Howell 0 Jan 4, 2022
A repository for showcasing my knowledge of the Google Go (2009) programming language, and continuing to learn the language.

Learning Google Golang (programming language) Not to be confused with the Go! programming language by Francis McCabe I don't know very much about the

Sean P. Myrick V19.1.7.2 1 Nov 26, 2021
A repository for showcasing my knowledge of the Go! (2003) programming language, and continuing to learn the language.

Learning Go! (programming language) Not to be confused with Google Golang (2009) I don't know too much about the Go! programming language, but I know

Sean P. Myrick V19.1.7.2 1 Nov 26, 2021
AWS SDK for the Go programming language.

AWS SDK for Go aws-sdk-go is the official AWS SDK for the Go programming language. Checkout our release notes for information about the latest bug fix

Amazon Web Services 7.8k Aug 5, 2022
go.fifo provides a simple fifo thread-safe queue for the Go programming language

go.fifo Description go.fifo provides a simple FIFO thread-safe queue. *fifo.Queue supports pushing an item at the end with Add(), and popping an item

Foize 41 Apr 15, 2022
Dynamic object-oriented programming support for the Go language

Goop Description The Goop (Go Object-Oriented Programming) package provides support for dynamic object-oriented programming constructs in Go, much lik

Los Alamos National Laboratory 105 Jun 6, 2022
Eclipse IDE for the Go programming language:

Project website: http://goclipse.github.io/ As of 2017, Goclipse is no longer actively maintained, see this blog post for more information. If you are

null 843 Jul 29, 2022
Gentee - script programming language for automation. It uses VM and compiler written in Go (Golang).

Gentee script programming language Gentee is a free open source script programming language. The Gentee programming language is designed to create scr

Alexey Krivonogov 95 Jul 22, 2022
PHP bindings for the Go programming language (Golang)

PHP bindings for Go This package implements support for executing PHP scripts, exporting Go variables for use in PHP contexts, attaching Go method rec

Alex Palaistras 868 Jul 23, 2022
Vulkan API bindings for Go programming language

Golang Bindings for Vulkan API Package vulkan provides Go bindings for Vulkan — a low-overhead, cross-platform 3D graphics and compute API. Updated Oc

null 637 Jul 31, 2022
A package to build progressive web apps with Go programming language and WebAssembly.

go-app is a package to build progressive web apps (PWA) with Go programming language and WebAssembly. It uses a declarative syntax that allows creatin

Maxence Charriere 6.3k Jul 30, 2022
A Windows GUI toolkit for the Go Programming Language

About Walk Walk is a "Windows Application Library Kit" for the Go Programming Language. Its primarily useful for Desktop GUI development, but there is

Alexander Neumann 6.1k Aug 4, 2022
beego is an open-source, high-performance web framework for the Go programming language.

Beego Beego is used for rapid development of enterprise application in Go, including RESTful APIs, web apps and backend services. It is inspired by To

astaxie 498 Aug 2, 2022
BGP implemented in the Go Programming Language

GoBGP: BGP implementation in Go GoBGP is an open source BGP implementation designed from scratch for modern environment and implemented in a modern pr

null 2.9k Jul 30, 2022
A simple wrapper around libpcap for the Go programming language

PCAP This is a simple wrapper around libpcap for Go. Originally written by Andreas Krennmair [email protected] and only minorly touched up by Mark Smith

Andreas Krennmair 445 Jul 27, 2022
Diameter stack and Base Protocol (RFC 6733) for the Go programming language

Diameter Base Protocol Package go-diameter is an implementation of the Diameter Base Protocol RFC 6733 and a stack for the Go programming language. St

Alexandre Fiori 204 Jul 27, 2022
SMPP 3.4 Protocol for the Go programming language

SMPP 3.4 This is an implementation of SMPP 3.4 for Go, based on the original smpp34 from Kevin Patel. The API has been refactored to idiomatic Go code

Alexandre Fiori 191 Jul 25, 2022
Basic LDAP v3 functionality for the GO programming language.

Basic LDAP v3 functionality for the GO programming language. Install For the latest version use: go get gopkg.in/ldap.v2 Import the latest version wi

null 137 May 24, 2022
cartconvert is a package providing a set of cartography functions for the Go programming language

cartconvert - a cartography package This is the home of the cartconvert project. You can find it online at http://cartconvert.allowed.org/ Cartconvert

Johann Höchtl 31 Apr 4, 2022
Go language bindings for the COIN-OR Linear Programming library

clp Description The clp package provides a Go interface to the COIN-OR Linear Programming (CLP) library, part of the COIN-OR (COmputational INfrastruc

Los Alamos National Laboratory 34 Jun 6, 2022
🛠 A full-featured dependency injection container for go programming language.

DI Dependency injection for Go programming language. Tutorial | Examples | Advanced features Dependency injection is one form of the broader technique

Goava 156 Jul 15, 2022
Stemmer packages for Go programming language. Includes English, German and Dutch stemmers.

Stemmer package for Go Stemmer package provides an interface for stemmers and includes English, German and Dutch stemmers as sub-packages: porter2 sub

Dmitry Chestnykh 51 Jan 23, 2022
Gonum is a set of numeric libraries for the Go programming language. It contains libraries for matrices, statistics, optimization, and more

Gonum Installation The core packages of the Gonum suite are written in pure Go with some assembly. Installation is done using go get. go get -u gonum.

null 6k Aug 2, 2022
Amber is an elegant templating engine for Go Programming Language, inspired from HAML and Jade

amber Notice While Amber is perfectly fine and stable to use, I've been working on a direct Pug.js port for Go. It is somewhat hacky at the moment but

Ekin Koc 894 Jul 24, 2022