Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

`find`, `findIndex`, `first` and `get` are type-checked as the element type where they return nil

Ouverte
  • Quelque chose ne va pas ?
#989 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

@TastyHeadphones y travaille déjà.

Depuis le 27/9/2026.

  • #992 par @TastyHeadphones — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
65/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
go
Domaine
compilers

Piste de recherche

Look at the type-checking logic for built-in functions like find, findIndex, first, and get in the compiler. The issue is that they return nil but are typed as the element type. Start by examining the type definitions and the WarnOnAny configuration. The test case provided shows the problem; run it to confirm. The fix likely involves adjusting the return type to be nullable or catching the mismatch during compilation.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

first of an empty []int, get with an out-of-range index and find/findIndex with no match are all type-checked as int, so AsInt() with WarnOnAny() accepts them at compile time and Run then fails with invalid operation: int(<nil>); the same find over a []any array is refused at compile time:

package main

import (
	"fmt"

	"github.com/expr-lang/expr"
)

func main() {
	env := map[string]any{
		"ints":  []int{1, 2, 3},
		"anys":  []any{1, 2, 3},
		"empty": []int{},
	}
	for _, src := range []string{
		"find(anys, # > 5)",
		"find(ints, # > 5)",
		"findIndex(ints, # > 5)",
		"first(empty)",
		"get(ints, 9)",
	} {
		program, err := expr.Compile(src, expr.Env(env), expr.AsInt(), expr.WarnOnAny())
		if err != nil {
			fmt.Printf("%-23s compile error: %v\n", src, err)
			continue
		}
		_, err = expr.Run(program, env)
		fmt.Printf("%-23s compiled as %v; Run: %v\n", src, program.Node().Type(), err)
	}
}

Output:

find(anys, # > 5)       compile error: expected int, but got interface {}
find(ints, # > 5)       compiled as int; Run: invalid operation: int(<nil>) (1:1)
 | find(ints, # > 5)
 | ^
findIndex(ints, # > 5)  compiled as int; Run: invalid operation: int(<nil>) (1:1)
 | findIndex(ints, # > 5)
 | ^
first(empty)            compiled as int; Run: invalid operation: int(<nil>) (1:1)
 | first(empty)
 | ^
get(ints, 9)            compiled as int; Run: invalid operation: int(<nil>) (1:1)
 | get(ints, 9)
 | ^

first and get are documented to return nil for an empty array and an out-of-range index (language-definition.md), and WarnOnAny() is documented to make the type checker return an error when the return type is any (configuration.md). With a []int array the static type of these calls is int, so the check passes and the nil only shows up when the program runs. I would expect these to be caught at compile time the way the []any case is, or to have a static type that admits nil.

Tested on expr v1.17.8 and on current master (4b31df3), Go 1.27.1.

BTW, this was found by an automated program that writes property-based tests for various open source projects using hegel (but it has been reviewed by hand before reporting). We've also potentially found (but not yet hand validated) 3 other bugs in expr. You can see the tests at https://github.com/hegeldev/hegel-zoo/tree/main/targets/go/expr. Let us know if you would like us to file the other bugs found and/or contribute the tests. NB the tests are currently LLM generated and probably not yet suitable for inclusion as is, but we're happy to help get them into a better state if you want them.

Langage dominant
Go
Étoiles
8k
Forks
535
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de expr-lang/expr

Toutes les issues de expr-lang/expr

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.