From 5b89670a318e52e271f65d96bfe1116d85d20988 Mon Sep 17 00:00:00 2001
From: wxiaoguang <wxiaoguang@gmail.com>
Date: Fri, 7 Apr 2023 21:25:49 +0800
Subject: Use a general Eval function for expressions in templates. (#23927)

One of the proposals in #23328

This PR introduces a simple expression calculator
(templates/eval/eval.go), it can do basic expression calculations.

Many untested template helper functions like `Mul` `Add` can be replaced
by this new approach.

Then these `Add` / `Mul` / `percentage` / `Subtract` / `DiffStatsWidth`
could all use this `Eval`.

And it provides enhancements for Golang templates, and improves
readability.

Some examples:

----

* Before: `{{Add (Mul $glyph.Row 12) 12}}`
* After: `{{Eval $glyph.Row "*" 12 "+" 12}}`

----

* Before: `{{if lt (Add $i 1) (len $.Topics)}}`
* After: `{{if Eval $i "+" 1 "<" (len $.Topics)}}`

## FAQ

### Why not use an existing expression package?

We need a highly customized expression engine:

* do the calculation on the fly, without pre-compiling
* deal with int/int64/float64 types, to make the result could be used in
Golang template.
* make the syntax could be used in the Golang template directly
* do not introduce too much complex or strange syntax, we just need a
simple calculator.
* it needs to strictly follow Golang template's behavior, for example,
Golang template treats all non-zero values as truth, but many 3rd
packages don't do so.

### What's the benefit?

* Developers don't need to add more `Add`/`Mul`/`Sub`-like functions,
they were getting more and more.
Now, only one `Eval` is enough for all cases.
* The new code reads better than old `{{Add (Mul $glyph.Row 12) 12}}`,
the old one isn't familiar to most procedural programming developers
(eg, the Golang expression syntax).
* The `Eval` is fully covered by tests, many old `Add`/`Mul`-like
functions were never tested.

### The performance?

It doesn't use `reflect`, it doesn't need to parse or compile when used
in Golang template, the performance is as fast as native Go template.

### Is it too complex? Could it be unstable?

The expression calculator program is a common homework for computer
science students, and it's widely used as a teaching and practicing
purpose for developers. The algorithm is pretty well-known.

The behavior can be clearly defined, it is stable.
---
 modules/util/util.go | 64 +++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 53 insertions(+), 11 deletions(-)

(limited to 'modules/util')

diff --git a/modules/util/util.go b/modules/util/util.go
index e9ea007ccb..782b905bec 100644
--- a/modules/util/util.go
+++ b/modules/util/util.go
@@ -9,7 +9,6 @@ import (
 	"errors"
 	"fmt"
 	"math/big"
-	"os"
 	"strconv"
 	"strings"
 
@@ -198,14 +197,8 @@ func ToTitleCaseNoLower(s string) string {
 	return cases.Title(language.English, cases.NoLower).String(s)
 }
 
-func logError(msg string, args ...any) {
-	// TODO: the "util" package can not import the "modules/log" package, so we use the "fmt" package here temporarily.
-	// In the future, we should decouple the dependency between them.
-	_, _ = fmt.Fprintf(os.Stderr, msg, args...)
-}
-
 // ToInt64 transform a given int into int64.
-func ToInt64(number interface{}) int64 {
+func ToInt64(number interface{}) (int64, error) {
 	var value int64
 	switch v := number.(type) {
 	case int:
@@ -218,6 +211,7 @@ func ToInt64(number interface{}) int64 {
 		value = int64(v)
 	case int64:
 		value = v
+
 	case uint:
 		value = int64(v)
 	case uint8:
@@ -228,13 +222,61 @@ func ToInt64(number interface{}) int64 {
 		value = int64(v)
 	case uint64:
 		value = int64(v)
+
+	case float32:
+		value = int64(v)
+	case float64:
+		value = int64(v)
+
 	case string:
 		var err error
 		if value, err = strconv.ParseInt(v, 10, 64); err != nil {
-			logError("strconv.ParseInt failed for %q: %v", v, err)
+			return 0, err
+		}
+	default:
+		return 0, fmt.Errorf("unable to convert %v to int64", number)
+	}
+	return value, nil
+}
+
+// ToFloat64 transform a given int into float64.
+func ToFloat64(number interface{}) (float64, error) {
+	var value float64
+	switch v := number.(type) {
+	case int:
+		value = float64(v)
+	case int8:
+		value = float64(v)
+	case int16:
+		value = float64(v)
+	case int32:
+		value = float64(v)
+	case int64:
+		value = float64(v)
+
+	case uint:
+		value = float64(v)
+	case uint8:
+		value = float64(v)
+	case uint16:
+		value = float64(v)
+	case uint32:
+		value = float64(v)
+	case uint64:
+		value = float64(v)
+
+	case float32:
+		value = float64(v)
+	case float64:
+		value = v
+
+	case string:
+		var err error
+		if value, err = strconv.ParseFloat(v, 64); err != nil {
+			return 0, err
 		}
 	default:
-		logError("unable to convert %q to int64", v)
+		return 0, fmt.Errorf("unable to convert %v to float64", number)
 	}
-	return value
+	return value, nil
 }
-- 
cgit v1.2.3