About the IMPORT instruction
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 20/100
Direzione di ricerca
The payload names no files, so start by finding the pre-parser and the IMPORT handling in the C# source. Read how the main file's configuration is applied to the merged text. Done would mean imported files are pre-parsed recursively with their own configuration, syntax errors report the correct file and line, and the grammar reads are merged before the main parse. The issue is a design proposal with no maintainer decision, so confirm the approach in the thread before writing code.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
What we have now
The pre-parsing applies on the main file. For each IMPORT read, it deletes that import and add the imported content to the start of the new string to parse.
The problem
Now if there is an error in one file, the parsing will still trigger an error, but it will neither give the file it occurs nor the correct line of the error. Moreover, different files may need different configurations. As for now, only the last line is taken into account for configuration, and that may lead to unexpected errors when parsing.
Idea for solution
Here is what I propose:
- When the pre-parser reads the main file, each time a IMPORT instruction is encountered
- The pre-parsing is also applied on the imported file, with a new empty configuration context so that the main configuration and the imported file configuration does not conflict. (Each time a IMPORT instruction is read, pre-parsing must recursively applied to the imported file).
- The syntax parsing is applied to the imported file.
- Once the pre-parsing is finished, all imported grammar reads are merged together
- The parsing can normally apply on the main file normally
- Lingua principale
- C#
- Stelle
- 0
- Fork
- 0
- Merge medio
- 3g 4h
- PR unite (30g)
- 5
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di Natvs/Nt.SyntaxParser
-
New light syntaxApertagood first issue usability
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
Natvs/Nt.SyntaxParser#45 ·
-
Starting a new branchApertagood first issue usability
Difficoltà 3/5 Mezza giornata Idoneità per principianti 73/100
Natvs/Nt.SyntaxParser#44 ·
-
documentation
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
Natvs/Nt.SyntaxParser#35 ·
-
enhancement
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
Natvs/Nt.SyntaxParser#28 ·
-
Comments in grammar filesApertaenhancement good first issue
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
Natvs/Nt.SyntaxParser#15 ·
Tutte le issue di Natvs/Nt.SyntaxParser
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Natvs/Nt.Automaton#33 ·
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
a-corriger documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
christian-raj/S-Aloha#312 ·
-
ready-for-agent tech-debt
Difficoltà 1/5 1-3 ore Idoneità per principianti 85/100
DigiBanks99/menlo#640 ·
I maintainer di solito rispondono entro 1 giorno
-
ci
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 62/100
OpenTabletDriver/OpenTabletDriver#5283 ·
I maintainer di solito rispondono entro 3 giorni