helpers

type BitSet ¶ added in v0.11.5

type BitSet struct {
	// contains filtered or unexported fields
}

func NewBitSet(bitCount uint) BitSet

func (bs BitSet) Equals(other BitSet) bool

func (bs BitSet) HasBit(bit uint) bool

func (bs BitSet) SetBit(bit uint)

func (bs BitSet) String() string

type F64 ¶ added in v0.20.1

type F64 struct {
	// contains filtered or unexported fields
}

This wraps float64 math operations. Why does this exist? The Go compiler contains some optimizations to take advantage of "fused multiply and add" (FMA) instructions on certain processors. These instructions lead to different output on those processors, which means esbuild's output is no longer deterministic across all platforms. From the Go specification itself (https://go.dev/ref/spec#Floating_point_operators):

An implementation may combine multiple floating-point operations into a
single fused operation, possibly across statements, and produce a result
that differs from the value obtained by executing and rounding the
instructions individually. An explicit floating-point type conversion
rounds to the precision of the target type, preventing fusion that would
discard that rounding.

For instance, some architectures provide a "fused multiply and add" (FMA)
instruction that computes x*y + z without rounding the intermediate result
x*y.

Therefore we need to add explicit type conversions such as "float64(x)" to prevent optimizations that break correctness. Rather than adding them on a case-by-case basis as real correctness issues are discovered, we instead preemptively force them to be added everywhere by using this wrapper type for all floating-point math.

func Lerp(a F64, b F64, t F64) F64

func Max2(a F64, b F64) F64

func Max3(a F64, b F64, c F64) F64

func Min2(a F64, b F64) F64

func Min3(a F64, b F64, c F64) F64

func NewF64(a float64) F64

func (a F64) Abs() F64

func (a F64) Add(b F64) F64

func (a F64) AddConst(b float64) F64

func (a F64) Atan2(b F64) F64

func (a F64) Cbrt() F64

func (a F64) Ceil() F64

func (a F64) Cos() F64

func (a F64) Cubed() F64

func (a F64) Div(b F64) F64

func (a F64) DivConst(b float64) F64

func (a F64) Floor() F64

func (a F64) IsNaN() bool

func (a F64) Log2() F64

func (a F64) Mul(b F64) F64

func (a F64) MulConst(b float64) F64

func (a F64) Neg() F64

func (a F64) Pow(b F64) F64

func (a F64) PowConst(b float64) F64

func (a F64) Round() F64

func (a F64) Sin() F64

func (a F64) Sqrt() F64

func (a F64) Squared() F64

func (a F64) Sub(b F64) F64

func (a F64) SubConst(b float64) F64

func (a F64) Value() float64

func (a F64) WithSignFrom(b F64) F64

type GlobPart ¶ added in v0.19.0

type GlobPart struct {
	Prefix   string
	Wildcard GlobWildcard
}

func ParseGlobPattern(text string) (pattern []GlobPart)

type GlobWildcard ¶ added in v0.19.0

type GlobWildcard uint8

const (
	GlobNone GlobWildcard = iota
	GlobAllExceptSlash
	GlobAllIncludingSlash
)

type Joiner ¶ added in v0.9.4

type Joiner struct {
	// contains filtered or unexported fields
}

This provides an efficient way to join lots of big string and byte slices together. It avoids the cost of repeatedly reallocating as the buffer grows by measuring exactly how big the buffer should be and then allocating once. This is a measurable speedup.

func (j *Joiner) AddBytes(data []byte)

func (j *Joiner) AddString(data string)

func (j *Joiner) Contains(s string, b []byte) bool

func (j *Joiner) Done() []byte

func (j *Joiner) EnsureNewlineAtEnd()

func (j *Joiner) LastByte() byte

func (j *Joiner) Length() uint32

type Serializer ¶ added in v0.14.18

type Serializer struct {
	// contains filtered or unexported fields
}

Each call to "Enter(i)" doesn't start until "Leave(i-1)" is called

func MakeSerializer(count int) Serializer

func (s *Serializer) Enter(i int)

func (s *Serializer) Leave(i int)

type ThreadSafeWaitGroup ¶ added in v0.16.3

type ThreadSafeWaitGroup struct {
	// contains filtered or unexported fields
}

Go's "sync.WaitGroup" is not thread-safe. Specifically it's not safe to call "Add" concurrently with "Wait", which is problematic because we have a case where we would like to do that.

This is a simple alternative implementation of "sync.WaitGroup" that is thread-safe and that works for our purposes. We don't need to worry about multiple waiters so the implementation can be very simple.

func MakeThreadSafeWaitGroup() *ThreadSafeWaitGroup

func (wg *ThreadSafeWaitGroup) Add(delta int32)

func (wg *ThreadSafeWaitGroup) Done()

func (wg *ThreadSafeWaitGroup) Wait()

type Timer ¶ added in v0.11.13

type Timer struct {
	// contains filtered or unexported fields
}

func (t *Timer) Begin(name string)

func (t *Timer) End(name string)

func (t *Timer) Fork() *Timer

func (t *Timer) Join(other *Timer)

func (t *Timer) Log(log logger.Log)

type TypoDetector ¶ added in v0.14.12

type TypoDetector struct {
	// contains filtered or unexported fields
}

func MakeTypoDetector(valid []string) TypoDetector

func (detector TypoDetector) MaybeCorrectTypo(typo string) (string, bool)