Comparisons of heterogenous primitive types are not considered for dead code elimination

[hamish-milne]

echo "if ('foo'=='bar') foo(); else bar();" | yarn esbuild --minify outputs bar(); as expected.

echo "if ('foo'==null) foo(); else bar();" | yarn esbuild --minify outputs "foo"==null?foo():bar(); when we expect it to output bar();, because 'foo'==null is always false.

This occurs when the LHS and RHS of an equality operator are different types, or arrays, or objects. Additionally, only ==, ===, the logical and ternary operators, and property accessors of new object expressions seem to be considered; arithmetic and comparison operators are excluded. While some of these are probably out of scope, it would be helpful to understand which constructs are eliminated and which are not.

[evanw]

The code for this is here:

esbuild/internal/js_ast/js_ast_helpers.go

Lines 840 to 878 in f730c03

	// Returns "equal, ok". If "ok" is false, then nothing is known about the two
	// values. If "ok" is true, the equality or inequality of the two values is
	// stored in "equal".
	func CheckEqualityIfNoSideEffects(left E, right E) (bool, bool) {
	if r, ok := right.(*EInlinedEnum); ok {
	return CheckEqualityIfNoSideEffects(left, r.Value.Data)
	}
	switch l := left.(type) {
	case *EInlinedEnum:
	return CheckEqualityIfNoSideEffects(l.Value.Data, right)
	case *ENull:
	_, ok := right.(*ENull)
	return ok, ok
	case *EUndefined:
	_, ok := right.(*EUndefined)
	return ok, ok
	case *EBoolean:
	r, ok := right.(*EBoolean)
	return ok && l.Value == r.Value, ok
	case *ENumber:
	r, ok := right.(*ENumber)
	return ok && l.Value == r.Value, ok
	case *EBigInt:
	r, ok := right.(*EBigInt)
	return ok && l.Value == r.Value, ok
	case *EString:
	r, ok := right.(*EString)
	return ok && helpers.UTF16EqualsUTF16(l.Value, r.Value), ok
	}
	return false, false
	}

Code folding for loose comparisons hasn't been implemented yet. Unlike JavaScript minifiers written in JavaScript, doing this in Go is non-trivial because you have to carefully and manually implement JavaScript type coercion rules. Right now constant folding for loose comparisons is only done in cases where both sides are primitives and there is no type coercion.

I'm open to implementing some additional rules. The specific algorithm to use as a guide would be this: https://tc39.es/ecma262/#sec-islooselyequal. Which rules are you looking for? Just equality with null?

[Conaclos]

Loose equality is often discouraged except for null/undefined checks. It seems fine to implement loose equality for these cases. It is pretty straightforward since null/undefined are only loosely equal to null/undefined.