2017-01-25 05:43:02 +03:00
// Copyright 2017 The Gitea Authors. All rights reserved.
2022-11-27 21:20:29 +03:00
// SPDX-License-Identifier: MIT
2017-01-25 05:43:02 +03:00
package util
2018-02-20 15:50:42 +03:00
import (
2019-11-13 05:27:11 +03:00
"bytes"
2021-05-10 09:45:17 +03:00
"crypto/rand"
2023-04-03 19:58:09 +03:00
"fmt"
2021-05-10 09:45:17 +03:00
"math/big"
2021-10-12 21:11:35 +03:00
"strconv"
2018-05-29 06:51:42 +03:00
"strings"
2022-05-11 00:55:54 +03:00
2024-02-23 05:18:33 +03:00
"code.gitea.io/gitea/modules/optional"
2022-05-11 00:55:54 +03:00
"golang.org/x/text/cases"
"golang.org/x/text/language"
2018-02-20 15:50:42 +03:00
)
2024-02-29 21:52:49 +03:00
// OptionalBoolParse get the corresponding optional.Option[bool] of a string using strconv.ParseBool
func OptionalBoolParse ( s string ) optional . Option [ bool ] {
v , e := strconv . ParseBool ( s )
2021-10-12 21:11:35 +03:00
if e != nil {
2024-02-29 21:52:49 +03:00
return optional . None [ bool ] ( )
2021-10-12 21:11:35 +03:00
}
2024-02-29 21:52:49 +03:00
return optional . Some ( v )
2021-10-12 21:11:35 +03:00
}
2019-01-21 14:45:32 +03:00
// IsEmptyString checks if the provided string is empty
func IsEmptyString ( s string ) bool {
return len ( strings . TrimSpace ( s ) ) == 0
}
2019-11-13 05:27:11 +03:00
// NormalizeEOL will convert Windows (CRLF) and Mac (CR) EOLs to UNIX (LF)
func NormalizeEOL ( input [ ] byte ) [ ] byte {
var right , left , pos int
if right = bytes . IndexByte ( input , '\r' ) ; right == - 1 {
return input
}
length := len ( input )
tmp := make ( [ ] byte , length )
// We know that left < length because otherwise right would be -1 from IndexByte.
copy ( tmp [ pos : pos + right ] , input [ left : left + right ] )
pos += right
tmp [ pos ] = '\n'
left += right + 1
pos ++
for left < length {
if input [ left ] == '\n' {
left ++
}
right = bytes . IndexByte ( input [ left : ] , '\r' )
if right == - 1 {
copy ( tmp [ pos : ] , input [ left : ] )
pos += length - left
break
}
copy ( tmp [ pos : pos + right ] , input [ left : left + right ] )
pos += right
tmp [ pos ] = '\n'
left += right + 1
pos ++
}
return tmp [ : pos ]
}
2020-11-25 14:20:40 +03:00
2022-01-26 07:10:10 +03:00
// CryptoRandomInt returns a crypto random integer between 0 and limit, inclusive
func CryptoRandomInt ( limit int64 ) ( int64 , error ) {
2022-01-04 18:13:52 +03:00
rInt , err := rand . Int ( rand . Reader , big . NewInt ( limit ) )
2021-05-10 09:45:17 +03:00
if err != nil {
return 0 , err
}
2022-01-04 18:13:52 +03:00
return rInt . Int64 ( ) , nil
2021-05-10 09:45:17 +03:00
}
2022-01-26 07:10:10 +03:00
const alphanumericalChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789"
2021-05-10 09:45:17 +03:00
2022-01-26 07:10:10 +03:00
// CryptoRandomString generates a crypto random alphanumerical string, each byte is generated by [0,61] range
func CryptoRandomString ( length int64 ) ( string , error ) {
buf := make ( [ ] byte , length )
limit := int64 ( len ( alphanumericalChars ) )
for i := range buf {
num , err := CryptoRandomInt ( limit )
2021-05-10 09:45:17 +03:00
if err != nil {
return "" , err
}
2022-01-26 07:10:10 +03:00
buf [ i ] = alphanumericalChars [ num ]
2021-05-10 09:45:17 +03:00
}
2022-01-26 07:10:10 +03:00
return string ( buf ) , nil
2021-05-10 09:45:17 +03:00
}
2022-01-04 18:13:52 +03:00
2022-01-26 07:10:10 +03:00
// CryptoRandomBytes generates `length` crypto bytes
// This differs from CryptoRandomString, as each byte in CryptoRandomString is generated by [0,61] range
// This function generates totally random bytes, each byte is generated by [0,255] range
func CryptoRandomBytes ( length int64 ) ( [ ] byte , error ) {
buf := make ( [ ] byte , length )
_ , err := rand . Read ( buf )
return buf , err
2022-01-04 18:13:52 +03:00
}
2022-02-01 15:59:25 +03:00
// ToUpperASCII returns s with all ASCII letters mapped to their upper case.
func ToUpperASCII ( s string ) string {
b := [ ] byte ( s )
for i , c := range b {
if 'a' <= c && c <= 'z' {
b [ i ] -= 'a' - 'A'
}
}
return string ( b )
}
2022-05-11 00:55:54 +03:00
// ToTitleCase returns s with all english words capitalized
func ToTitleCase ( s string ) string {
2023-04-04 01:03:45 +03:00
// `cases.Title` is not thread-safe, do not use global shared variable for it
return cases . Title ( language . English ) . String ( s )
2022-05-11 00:55:54 +03:00
}
2022-06-10 16:45:28 +03:00
2023-04-04 01:03:45 +03:00
// ToTitleCaseNoLower returns s with all english words capitalized without lower-casing
2022-11-19 14:08:06 +03:00
func ToTitleCaseNoLower ( s string ) string {
2023-04-04 01:03:45 +03:00
// `cases.Title` is not thread-safe, do not use global shared variable for it
return cases . Title ( language . English , cases . NoLower ) . String ( s )
2022-11-19 14:08:06 +03:00
}
2023-04-03 19:58:09 +03:00
// ToInt64 transform a given int into int64.
2023-07-04 21:36:08 +03:00
func ToInt64 ( number any ) ( int64 , error ) {
2022-06-12 15:08:23 +03:00
var value int64
switch v := number . ( type ) {
case int :
value = int64 ( v )
case int8 :
value = int64 ( v )
case int16 :
value = int64 ( v )
case int32 :
value = int64 ( v )
case int64 :
value = v
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.
2023-04-07 16:25:49 +03:00
2023-04-03 19:58:09 +03:00
case uint :
value = int64 ( v )
case uint8 :
value = int64 ( v )
case uint16 :
value = int64 ( v )
case uint32 :
value = int64 ( v )
case uint64 :
value = int64 ( v )
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.
2023-04-07 16:25:49 +03:00
case float32 :
value = int64 ( v )
case float64 :
value = int64 ( v )
2023-04-03 19:58:09 +03:00
case string :
var err error
if value , err = strconv . ParseInt ( v , 10 , 64 ) ; err != nil {
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.
2023-04-07 16:25:49 +03:00
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.
2023-07-04 21:36:08 +03:00
func ToFloat64 ( number any ) ( float64 , error ) {
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.
2023-04-07 16:25:49 +03:00
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
2023-04-03 19:58:09 +03:00
}
default :
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.
2023-04-07 16:25:49 +03:00
return 0 , fmt . Errorf ( "unable to convert %v to float64" , number )
2022-06-12 15:08:23 +03:00
}
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.
2023-04-07 16:25:49 +03:00
return value , nil
2022-06-12 15:08:23 +03:00
}
2023-07-07 08:31:56 +03:00
// ToPointer returns the pointer of a copy of any given value
func ToPointer [ T any ] ( val T ) * T {
return & val
}
2024-03-14 04:10:51 +03:00
2024-04-03 05:16:46 +03:00
// Iif is an "inline-if", it returns "trueVal" if "condition" is true, otherwise "falseVal"
2024-04-07 14:17:06 +03:00
func Iif [ T any ] ( condition bool , trueVal , falseVal T ) T {
2024-04-03 05:16:46 +03:00
if condition {
return trueVal
}
return falseVal
}
2024-03-14 04:10:51 +03:00
// IfZero returns "def" if "v" is a zero value, otherwise "v"
func IfZero [ T comparable ] ( v , def T ) T {
var zero T
if v == zero {
return def
}
return v
}
2024-03-28 23:40:35 +03:00
2024-11-01 18:18:29 +03:00
// OptionalArg helps the "optional argument" in Golang:
//
// func foo(optArg ...int) { return OptionalArg(optArg) }
// calling `foo()` gets zero value 0, calling `foo(100)` gets 100
// func bar(optArg ...int) { return OptionalArg(optArg, 42) }
// calling `bar()` gets default value 42, calling `bar(100)` gets 100
//
// Passing more than 1 item to `optArg` or `defaultValue` is undefined behavior.
// At the moment only the first item is used.
func OptionalArg [ T any ] ( optArg [ ] T , defaultValue ... T ) ( ret T ) {
if len ( optArg ) >= 1 {
return optArg [ 0 ]
}
if len ( defaultValue ) >= 1 {
return defaultValue [ 0 ]
}
return ret
}
2024-03-28 23:40:35 +03:00
func ReserveLineBreakForTextarea ( input string ) string {
// Since the content is from a form which is a textarea, the line endings are \r\n.
// It's a standard behavior of HTML.
// But we want to store them as \n like what GitHub does.
// And users are unlikely to really need to keep the \r.
// Other than this, we should respect the original content, even leading or trailing spaces.
return strings . ReplaceAll ( input , "\r\n" , "\n" )
}