Projets-INFO4 issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/groups/Projets-INFO4/-/issues2023-11-29T17:43:28+01:00https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/25Introduce Type::UnknownNumeric?2023-11-29T17:43:28+01:00Edgar Onghenadev@edgar.bzhIntroduce Type::UnknownNumeric?Introduce a `Type::UnknownNumeric`/`Type::Numeric` that works like `Type::Unknown` but guarantees a **known** numeric type (`Integer` or `Real`). This would be returned by numeric operators when operands cannot be determined or when they...Introduce a `Type::UnknownNumeric`/`Type::Numeric` that works like `Type::Unknown` but guarantees a **known** numeric type (`Integer` or `Real`). This would be returned by numeric operators when operands cannot be determined or when they differ in types.https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/30Diagnostics should remember their context when raised from within a generic n...2023-11-24T07:38:27+01:00Edgar Onghenadev@edgar.bzhDiagnostics should remember their context when raised from within a generic node instantiationSimilarly to C++'s templates, it'd be great if a diagnostic thrown by a generic node instantiation showed the entire instantiation stack when printed. However, we must decide what happens when the node is instantiated from two locations.Similarly to C++'s templates, it'd be great if a diagnostic thrown by a generic node instantiation showed the entire instantiation stack when printed. However, we must decide what happens when the node is instantiated from two locations.https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/29Introduce `rustredoc`2023-08-09T16:40:14+02:00Edgar Onghenadev@edgar.bzhIntroduce `rustredoc`### What?
`rustredoc` is to Lustre what `rustdoc` is to Rust. A documentation tool.
### Why not `lustredoc` ?
Lustre doesn't have an official documentation tool. We would have to invent our own standard/format for the doc comments, an...### What?
`rustredoc` is to Lustre what `rustdoc` is to Rust. A documentation tool.
### Why not `lustredoc` ?
Lustre doesn't have an official documentation tool. We would have to invent our own standard/format for the doc comments, and we wouldn't want users to believe that this has anything to do with the official Lustre tools. Also, the tool would most likely be invoked as `rustre doc` rather than a specific `rustredoc` command, so it just makes sense to not call it `lustredoc`.
### Goal
Ability to generate documentation given one or many Lustre files (including dependencies), in HTML or PDF format (Pandoc?). The documentation would give the details of
* each module that was found
* each nodes/functions defined in them (name, signature, statefulness, acceptability of null values) with an added custom documentation text
* typedefs, structs, enums
* external nodes/functions
The documentation could include additional Lustre-specific information, e.g.:
* A (visual) graph of a node's implementation
* For pure nodes that emit a stream of data, independent of the input, a computed series of the first values, as an example
These would be opt-in, enabled through special documentation directives (see below paragraphs).
### Documenting within the code
Like rustdoc, javadoc, doxygen, etc., we would expect the code to be documented internally, by adding special comments before documented items. These comments could add a description of the item, and additional directives to customize what information is rendered exactly, and how.
As said previously, Lustre doesn't have an official doc format, and it's thus our responsibility to invent our own. Since Lustre is very tied to OCaml, it would make sense to take inspiration from OCaml's own doc tool. As such I propose the syntax `(** *)` to denote documentation comments. Because Lustre also has C-style comments, these should also work (`/** */`) to have parity with Javadoc/Doxygen.
* The indent removal should work the same way as OCaml, which I guess just ignores preceding whitespace on each line withing doc comments (we should check). The content of doc comments should support as much of the markdown syntax as possible. Language-specific features, such as intra links, are desirable: Rustdoc has a nice approach to them which feels very Markdown-y.
* It should be possible to write brief single-line comments (e.g. `(** Returns the negation of the given boolean value *)`
* Like Rustdoc, it'd be nice to not rely too much on directives. The first paragraph could also be implicitly used as a brief summary.
### TODO
* [ ] Define the doc format clearly
* [ ] Implement at least one backend
* [ ] Improve this issuehttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/28Remove UTF-8 encoding requirement2023-06-29T14:58:12+02:00Edgar Onghenadev@edgar.bzhRemove UTF-8 encoding requirement### Motivation
Lustre doesn't specify an encoding, and yet we're currently using `String`s and `&str`s everywhere. This makes many tests/examples from the official repository not compile without prior conversion, as they are not in UTF-...### Motivation
Lustre doesn't specify an encoding, and yet we're currently using `String`s and `&str`s everywhere. This makes many tests/examples from the official repository not compile without prior conversion, as they are not in UTF-8, but in an old-school weird French ASCII variant.
### Solution
We should eventually migrate our uses of `&str` to `&[u8]`, as [logos v0.13.0 now supports bytes slices](https://docs.rs/logos/latest/logos/trait.Logos.html#associatedtype.Source) (which wasn't the case when we started the project). **However, we're still blocked by `rowan`**, [whose internal representation relies on string slices](https://docs.rs/rowan/0.15.11/rowan/struct.GreenNodeBuilder.html#method.token).
### Implementation
This shouldn't be too hard to implement at all. The only place where we may actually care about the actual textual representation of strings would be when printing diagnostics containing identifiers, and maybe later, in docstrings.
* Docstrings are out of the question: we'll literally be the ones specifying them so we can choose to require UTF-8, at least inside the comment
* Printing diagnostics isn't an issue too, because they follow the regex `/[a-zA-Z_][a-zA-Z0-9_]*/` which is trivially safe to treat as a string. For the matters of making our compiler as lax as possible, it may not be absurd to relax this regex to wider ranges of unicode and check their validity much later, but again, we're making the rules, so we can choose to really only allow UTF-8 anyway.
If we trust `logos`' regex engine with our lives, we can probably do an unsafe conversion of bytes to String (behind a default-enabled feature flag, with a safe baseline implementation else, just in case).https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/26Implement stdlib as actual Lustre file2023-06-14T16:56:28+02:00Edgar Onghenadev@edgar.bzhImplement stdlib as actual Lustre fileInstead of hard-coding Lustre's standard library functions (e.g. the named operators: `Lustre::add`, `Lustre::mul`...), it may be reasonable to define them in an actual Lustre file that gets shipped inside the compiler. This would make t...Instead of hard-coding Lustre's standard library functions (e.g. the named operators: `Lustre::add`, `Lustre::mul`...), it may be reasonable to define them in an actual Lustre file that gets shipped inside the compiler. This would make the compiler much simpler to maintain.
Some functions may benefit from having specialized diagnostics. To deal with this, it could be possible to follow Rust's path where the standard library code has access to various compiler-private attributes to alter error emitting.
Some functions, such as Lustre's "iterators", can literally _not_ be expressed in Lustre syntax (both the body and the signature, as they're variadic). Again, this can probably be patched using custom stdlib-reserved attributes. It won't be super clean, but always better than special-casing in 1) the name resolver 2) the function type-checker 3) the potential "lustredoc" 4) the various function-level LSP refactorings & probably more.
## Examples of standard function implementations
### Operator static arguments
There's a weird case in Lustre where `node`-kind static parameters may be instanciated using an iterator literal, as in `res = fold_left<<+>>(my_list)`. This example would be equivalent to `res = fold_left<<Lustre::add>>(my_list)`. In the standard library file, we could have:
```lus
function add {% lustre_internal_operator_impl:_ %} <<type N>> (a, b: N) returns (r : N);
let
r = a + b;
tel;
```
The pragma would be interpreted as a very special case, and would require the function body to have a very precise strucure, token-wise, so it can extract the `+` inside the body and correctly create a mapping to the enclosing function. Of course, this should also work with unary operators. I don't know how it should work for minus (unary/binary depending on context) though.
This is clearly "weird" and kinda feels wrong to handle such specific special cases, but it looks to me like the cleanest way to not hardcode all ot this.
### Iterators
Iterators are exceptionally weird due to them looking like functions but having variadic args. It makes complete sense to treat them as functions though. As soon as their static arguments are known, their number of arguments is known, and they can be aliased in function alias declarations or passed as node parameters, so it wouldn't make sense to specialize them that much.
* A possible way to implement them is to declare a stub with zero arguments and a special pragma, and override its signature resolution on a case-by-case basis (much better already than treating the entire iterator as a special ghost function)
* We can also think about implementing special syntax that would only be allowed inside the standard library (like Rust's `box` operator). This would be a bit weird though since our parser isn't tied to the Rustre core.
* We can also try to see if one or more of the iterators can be expressed as an alias of one of the other one, to simplify even morehttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/27Embed file source reference inside the AST?2023-06-11T13:26:13+02:00Edgar Onghenadev@edgar.bzhEmbed file source reference inside the AST?This may be controversial, but I think it wouldn't be a bad idea to embed the location of a source file inside the rowan AST (at the root), in a way that is — obviously — hidden to text editors, LSP servers or pretty-printers.
### What ...This may be controversial, but I think it wouldn't be a bad idea to embed the location of a source file inside the rowan AST (at the root), in a way that is — obviously — hidden to text editors, LSP servers or pretty-printers.
### What for?
This would help with diagnostic emitting, `include` resolution and maybe other parts, as ASTs wouldn't need to be accompanied by a path (or require an external global mapping of `Root` → `SourceFile` as it's the case right now.
### Rationale
Due to `include`s supporting relative paths, it's actually not absurd at all to consider the source code file's location as an intrinsic part of it, even if it's not "source code" strictly speaking. By embedding the location inside the file, an AST will contain absolutely everything any AST node consumer may possibly need.
### Implementation
Attention should be given to the potential future need for "virtual" files, such as remote files provided by an LSP client or the embedded standard library file (c.f. #26).
Unfortunately, this idea looks a bit tricky to implement as rowan doesn't support adding arbitrary metadata to nodes. Two approches could be:
* Make the file source path an integral part of the "source" code (at the end so it doesn't mess up with character/line numbers), and filter it out as appropriate
* Use the fact that a `u16` can represent much more values than our current `Token` enum uses, and make the remaining values — inside token tree nodes — act as keys to a global table to arbitrary Rust objects. This requires manually freeing entries when ASTs are destroyed, though. This ends up being similar to what we have in place right now, but at least we're not relying on unreliable object `Eq` identity as keys.https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/24Discretise compiler diagnostics2023-06-11T11:53:33+02:00Edgar Onghenadev@edgar.bzhDiscretise compiler diagnosticsCurrently, compiler diagnostics are built using the `Diagnostic` struct from within the compiler's core. The message is allocated inside the compiler and provided directly as a `String`. That makes it simple to create new diagnostics but...Currently, compiler diagnostics are built using the `Diagnostic` struct from within the compiler's core. The message is allocated inside the compiler and provided directly as a `String`. That makes it simple to create new diagnostics but has a few issues:
* It's hard to refer to a unique diagnostic "type" (mismatched type, syntax error, missing argument, ...), as the only identity of an error is the line its diagnostic is created at
* Having a numeric error code is much easier to Google or seek help on an online index (e.g. [Rust's error code index](https://doc.rust-lang.org/error_codes/error-index.html))
* It's near-impossible to localize errors for different languages if we ever had to do that
* It bloats the core of the compiler with user-facing, almost UI-related, code
* We're using `Diagnostic` as an abstraction over `ariadne` but over time we might tend to just reimplement `ariadne`'s API
* This also requires allocating more memory from within the compiler
* It makes it super hard for compiler drivers to understand the diagnostics as they're directly emitted in human form
* It also makes it hard for external tool to be one day able to receive diagnostics in stdout but as a machine format (e.g. [Rust's JSON output](https://doc.rust-lang.org/rustc/json.html#diagnostics))
* Same remark for language servers
* Same remark for "quick fix" features of language servers. Generating quick-fixes from inside the compiler would be ridiculous
* It's hard to categorize errors/warnings, notably to be able to granularly disable the latter
Ideally, our diagnostics would be represented as a big enum, or a boxed `dyn` trait, and all presentation-related stuff would be the problem of user-facing drivers (incl. quick fixes).
Doing this today would be a bad idea as we don't really have enough hindsight on all errors we may emit.
Possibly interesting reads (yeah I like Rust how would you guess?):
* https://doc.rust-lang.org/rustc/lints/levels.html
* https://rustc-dev-guide.rust-lang.org/diagnostics/error-codes.html
* https://doc.rust-lang.org/rustc/json.html#diagnostics
* https://doc.rust-lang.org/error_codes/error-index.htmlhttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/9Compilation#4 - Compilation vers llvm (inkwell)2023-05-11T14:15:54+02:00Mathis GrangeCompilation#4 - Compilation vers llvm (inkwell)https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/20`type_check_query` unwraps None when a node has no body2023-04-02T20:01:35+02:00Edgar Onghenadev@edgar.bzh`type_check_query` unwraps None when a node has no bodyhttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/12Query salsa: vérifications post-parsing2023-04-02T19:57:34+02:00Edgar Onghenadev@edgar.bzhQuery salsa: vérifications post-parsingC'est très fastidieux et peut être mieux que je m'en occupe, mais il faudrait une query salsa qui vérifie le tout l'AST. Plein de petites erreurs ne sont pas gérées, notamment le fait que sur beaucoup d'éléments en répétition Lustre en r...C'est très fastidieux et peut être mieux que je m'en occupe, mais il faudrait une query salsa qui vérifie le tout l'AST. Plein de petites erreurs ne sont pas gérées, notamment le fait que sur beaucoup d'éléments en répétition Lustre en requiert minimum 1, mais que notre parseur accepte qu'il n'y en ai pas. Cette query ne serait une dépendance que d'une compilation finale, ou d'une recherche spécifique de diagnostics par un LSP.
Vérifs à faire (non exhaustif, mis à jour quand j'y pense)
* Interdire
* [ ] Equations récursives (hors `pre`)
* [ ] Consts récursifs
* [ ] Si un fichier contient un package, il ne doit rien contenir d'autre (à part des include)
* [x] Les fonctions/nœuds à 0 arguments (!26)
* Obliger
* [ ] Unicité des noms de variable / nœud / const / etc.
* [ ] Ordre des items top-level dans l'ordre imposé par la syntaxe Lustrehttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/21/tanks_of_freedom/-/issues/53Explosion is not a child (remove_child)2023-03-28T14:30:53+02:00Theo LopesExplosion is not a child (remove_child)To an instance of explosion, there is multiple call of the func remove_child and give an error. Not urgent but neededTo an instance of explosion, there is multiple call of the func remove_child and give an error. Not urgent but neededMaxime LeroyMaxime Leroyhttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/21/tanks_of_freedom/-/issues/50AI wrong movement2023-03-28T13:46:29+02:00Theo LopesAI wrong movementWhen the AI play, some illegal movements are done, like be in a statue tile, or a city tile.When the AI play, some illegal movements are done, like be in a statue tile, or a city tile.https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/7Compilation#2 - Génération EC (Extended Code)2023-03-27T18:32:18+02:00Mathis GrangeCompilation#2 - Génération EC (Extended Code)https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/14Tests par fuzzing2023-03-27T17:50:36+02:00Edgar Onghenadev@edgar.bzhTests par fuzzingTrès probablement pas dans les limites de temps imposées par le projet; mais ça pourrait être bien de fuzzer le parseur et/ou le compilateur pour comparer son comportement avec celui de `lv6` lorsqu'on lui donne du code identique.
Le te...Très probablement pas dans les limites de temps imposées par le projet; mais ça pourrait être bien de fuzzer le parseur et/ou le compilateur pour comparer son comportement avec celui de `lv6` lorsqu'on lui donne du code identique.
Le test en lui même n'est pas trop dur à faire. Le plus compliqué est de générer des séquences de lexèmes aléatoires qui tendent à être correctes relativement souvent pour pouvoir tester aussi bien du code supposé invalide que du code supposé valide.
Selon la "profondeur" des tests, cela peut être plus ou moins compliqué. Des tests du parseur/lexeur peuvent probablement se faire avec une chaîne de Markov (ou similaire) tandis que des tests du type-checker requièrent beaucoup plus de code complexe.https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/17LSP: Retrouver un Ident à partir d'une position dans le code2023-03-27T17:50:09+02:00Edgar Onghenadev@edgar.bzhLSP: Retrouver un Ident à partir d'une position dans le codeSi on souhaite implémenter un LSP (probablement pas dans le contexte INFO4/Polytech mais plus tard), ça sera intéressant d'avoir un moyen de remonter à un `Ident` étant donnée une position dans le texte (par exemple [`::lsp_types::TextDo...Si on souhaite implémenter un LSP (probablement pas dans le contexte INFO4/Polytech mais plus tard), ça sera intéressant d'avoir un moyen de remonter à un `Ident` étant donnée une position dans le texte (par exemple [`::lsp_types::TextDocumentPositionParams`](https://docs.rs/lsp-types/0.94.0/lsp_types/struct.TextDocumentPositionParams.html)). Éventuellement on pourrait faire la même chose pour la partie "string" des imports, afin de naviguer d'un fichier à l'autre.
Il s'agit des seuls deux tokens qui aurait besoin de ctrl+click, à première vue.
On pourrait aussi vouloir fournir de la docu au survol pour les mots-clés, mais pas besoin de résoudre leur position dans l'AST pour ça (quoi que, certains tokens peuvent avoir des significations différentes selon le contexte).https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/10Commande de formatage du code2023-03-27T17:49:51+02:00Mathis GrangeCommande de formatage du codehttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/11Affichage graphique type luciole (??)2023-03-27T17:49:41+02:00Mathis GrangeAffichage graphique type luciole (??)https://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/21/tanks_of_freedom/-/issues/47Register id player in online crash2023-03-27T15:44:32+02:00Maxime LeroyRegister id player in online crashSeems like callback result format changedSeems like callback result format changedhttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/18ast::TypeNode as an enum?2023-03-22T18:30:13+01:00Ana Gelezast::TypeNode as an enum?Not sure, but it seems weird to me to have all these optional fields and not variants.Not sure, but it seems weird to me to have all these optional fields and not variants.Edgar Onghenadev@edgar.bzhEdgar Onghenadev@edgar.bzhhttps://gricad-gitlab.univ-grenoble-alpes.fr/Projets-INFO4/22-23/26/rustre/-/issues/5Mettre en place l'interpréteur2023-03-13T16:15:24+01:00Mathis GrangeMettre en place l'interpréteurInterpréteurEdgar Onghenadev@edgar.bzhEdgar Onghenadev@edgar.bzh