Support struct-like variants in `parser.py`
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 45/100
Direzione di ricerca
Inizia da parser.py e confronta la gestione esistente delle enum variants con gli esempi di VariantsShape nell’issue. Determina come i campi Single e Multiple vengono mappati nella K syntax del parser, quindi verifica che entrambe le forme struct-like siano accettate e rappresentate correttamente. L’implementazione ideale rimuove gli mk constructors intermedi quando possibile.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Consider
pub enum VariantsShape {
Single { index: VariantIdx },
Multiple {
tag: Scalar,
tag_encoding: TagEncoding,
tag_field: usize,
variants: Vec<LayoutShape>,
},
}
This can be modeled with proper parser support in K as follows:
syntax VariantsShape ::= variantsShapeSingle(VariantsShapeSingle) [group(mir-enum), symbol(VariantsShape::Single)]
| variantsShapeMultiple(VariantsShapeMultiple) [group(mir-enum), symbol(VariantsShape::Multiple)]
syntax VariantsShapeSingle ::= mk(index: VariantIdx) [group(mir---index)]
syntax VariantsShapeMultiple ::= mk ( tag: Scalar
, tagEncoding: TagEncoding
, tagField: MIRInt
, variants: LayoutShapes
) [group(mir---tag--tag-encoding--tag-field--variants)]
The ideal solution would be to eliminate the mk constructors, and model the struct-like variants directly, e.g.:
syntax VariantsShape ::= variantsShapeSingle(index: VariantIdx) [group(mir-enum---index), symbol(VariantsShape::Single)]
| variantsShapeMultiple ( tag: Scalar
, tagEncoding: TagEncoding
, tagField: MIRInt
, variants: LayoutShapes
) [group(mir-enum---tag--tag-encoding--tag-field--variants), symbol(VariantsShape::Multiple)]
- Lingua principale
- Python
- Stelle
- 55
- Fork
- 5
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
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 runtimeverification/mir-semantics
-
Remove #init function from KAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
-
Inconsistent KMIR versions across projectForse già presa @dkcumming l’ha presa 96 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 52/100
runtimeverification/mir-semantics#1078 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
runtimeverification/mir-semantics#1070 · 2 commenti ·
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 58/100
runtimeverification/mir-semantics#1067 ·
-
area:semantics kind:refactor priority:p1 status:triage type:task
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
runtimeverification/mir-semantics#1011 · 1 commento ·
Tutte le issue di runtimeverification/mir-semantics
Issue simili
-
debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
microsoft/vscode-flake8#601 ·
I maintainer di solito rispondono entro 1 giorno
-
nonews refactor
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
Uninett/nav#4255 · 1 commento · 1 reazione ·
I maintainer di solito rispondono entro 3 giorni
-
namespace operations
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 70/100
EclipseFdn/open-vsx.org#14421 ·
I maintainer di solito rispondono entro 1 giorno
-
untriaged
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ubuntu/ubuntu-project-docs#850 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno