Trouver des fichiers, suivre les symboles et vérifier les références source

Utilisez Aller au fichier si vous savez à peu près où chercher, « Rechercher dans tous les fichiers » si vous connaissez le texte, et la navigation par serveur de langage pour suivre un symbole. Passer de l’un à l’autre est souvent plus rapide qu’affiner une recherche trop large.

Choisir la bonne recherche

Ce que vous savez	Outil	Exemple
Partie d’un nom ou chemin de fichier	Command-P (Aller au fichier…)	SettingsStore ou src/config
Message, réglage ou fragment de code	Rechercher dans tous les fichiers dans la barre latérale	Message d’erreur exact ou clé de configuration
Symbole dans un fichier ouvert	Aller à la définition, Rechercher les références	Implémentation ou appelants d’une fonction

« Aller au fichier » recherche les noms et chemins, pas le contenu. Pour trouver un message d’erreur affiché par le programme, utilisez « Rechercher dans tous les fichiers » avec un texte distinctif plutôt que des mots comme data ou result.

Si un fichier ou résultat manque, vérifiez d’abord la racine du projet, puis l’affichage des fichiers cachés et ignorés par Git. Les valeurs par défaut dans Réglages → Général → Fichiers s’appliquent à la barre latérale et aux deux recherches. Chaque espace de travail peut les remplacer depuis la barre d’état de la barre latérale.

Remonter un message d’erreur à la branche qui l’a produit

Un message d’erreur donne un point de départ, mais la ligne qui l’affiche peut seulement envelopper un échec venu d’ailleurs.

1. Cherchez la partie fixe. Ouvrez Rechercher dans tous les fichiers avec la loupe de la barre latérale. Omettez horodatages, identifiants de requête et chemins insérés à l’exécution. Désactivez d’abord Regex et Mot entier ; si la casse est incertaine, choisissez Ignorer dans le menu Aa.
2. Vérifiez le périmètre. Ouvrez Filtres et effacez les anciens dossiers ou motifs avant une recherche large. Une fois le module probable connu, limitez le dossier ou utilisez un motif comme *.rs. Meilleurs résultats signifie que la liste est incomplète : affinez avant de conclure à l’absence d’une correspondance.
3. Lisez autour du résultat. Ouvrez-le et trouvez la condition qui y mène. Le message est-il créé ici, ou une couche catch/journalisation ajoute-t-elle du contexte à une autre erreur ? Dans ce dernier cas, suivez l’opération échouée.
4. Remontez l’entrée. Suivez les appelants de la fonction et la valeur qui sélectionne la branche. Utilisez Rechercher les références si le serveur le permet, ou cherchez les noms de fonction et de configuration puis vérifiez chaque usage en contexte.
5. Vérifiez l’explication. Comparez l’entrée et la branche proposées à un test ciblé ou un journal d’exécution de la même version. Notez ce que ces éléments confirment et ce qui reste à vérifier ; trouver le message seul n’établit pas la cause.

La recherche couvre l’espace de travail actuel, y compris le texte non enregistré des fichiers ouverts, pas toutes les révisions Git. Si l’erreur vient d’une ancienne version, comparez la version concernée avant d’utiliser le source actuel comme explication.

Serveurs de langage

« Aller à la définition », « Rechercher les références », les implémentations et la hiérarchie des appels proviennent d’un serveur de langage :

Langage	Serveur
Swift	SourceKit-LSP
Rust	rust-analyzer
C, C++, Objective-C, Objective-C++	clangd
Python	Pyright
JavaScript, JSX, TypeScript, TSX	TypeScript Language Server
Go	gopls

Yenpo peut installer rust-analyzer depuis Réglages → Navigation dans le code. SourceKit-LSP et clangd viennent de la chaîne d’outils Xcode sélectionnée. Vous devez installer Pyright, TypeScript Language Server et gopls et les rendre accessibles via PATH. Les capacités varient et certains projets nécessitent une configuration supplémentaire.

Si un symbole connu ne donne rien, vérifiez trois points : racine du projet ouverte, serveur installé, dépendances et configuration de compilation en place. La coloration syntaxique fonctionne même sans serveur.

Sans serveur, la recherche textuelle reste utile. Cherchez la déclaration et ses usages, puis distinguez les symboles homonymes grâce aux types et imports.

Suivre un comportement sans perdre sa place

Gardez le fichier de départ dans un onglet pendant que vous suivez une définition ailleurs. À chaque appel important, notez l’entrée et ce qui décide du chemin suivant : réglage, type, clé de registre ou état courant.

« Rechercher les références » affiche les usages signalés par le serveur, pas une trace d’exécution. Prise en charge, configuration et limites de résultats peuvent rendre la liste incomplète. Si un registre propose une implémentation locale et distante, trouvez la valeur qui choisit. En asynchrone, vérifiez aussi ce qui peut changer avant le retour du résultat.

Une note de lecture pour une valeur de configuration pourrait ressembler à ceci :

CLI input → config resolver → validation → request builder
Selected source: environment override
Failure: invalid value stops before request construction
Unverified: which parent process sets that environment variable

Ajoutez des références aux fichiers et lignes pour les étapes réellement vérifiées. Le parcours de configuration le fait de bout en bout avec des tests exécutables.

Vérifier une référence source de l’IA

Cliquer sur une référence dans une réponse IA ouvre les lignes citées dans Coup d’œil. Si l’extrait est trop court, cliquez sur Ouvrir le fichier pour voir le fichier entier dans un onglet.

Lisez les conditions environnantes et l’appelant avant de vous fier à la réponse. Une ligne supprimant une entrée de cache peut n’être sûre que si l’entrée appartient encore à la même requête. La référence indique où regarder ; le contexte dit si l’affirmation tient.

Documentation et anciennes versions

Les fichiers Markdown s’ouvrent en lecture ; vous pouvez passer à l’édition du source. Gardez un README ou un test près de l’implémentation et notez leurs divergences.

Les fichiers historiques Git peuvent côtoyer vos fichiers actuels. Avant de suivre une référence ou de modifier, vérifiez la version de l’onglet : l’explication d’un ancien commit peut ne pas correspondre à l’arbre de travail. Comparer commits et branches explique le choix des versions.