WO2015135769A1 - Procede et dispositif pour gerer les ambigüites dans l'analyse d'un code source - Google Patents

Procede et dispositif pour gerer les ambigüites dans l'analyse d'un code source Download PDF

Info

Publication number
WO2015135769A1
WO2015135769A1 PCT/EP2015/054187 EP2015054187W WO2015135769A1 WO 2015135769 A1 WO2015135769 A1 WO 2015135769A1 EP 2015054187 W EP2015054187 W EP 2015054187W WO 2015135769 A1 WO2015135769 A1 WO 2015135769A1
Authority
WO
WIPO (PCT)
Prior art keywords
name
grammar
lexical
symbol
typedef
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2015/054187
Other languages
English (en)
Inventor
Thierry GOUBIER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat a lEnergie Atomique et aux Energies Alternatives CEA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Commissariat a lEnergie Atomique CEA, Commissariat a lEnergie Atomique et aux Energies Alternatives CEA filed Critical Commissariat a lEnergie Atomique CEA
Priority to EP15709632.2A priority Critical patent/EP3117307A1/fr
Priority to US15/123,937 priority patent/US20170024193A1/en
Publication of WO2015135769A1 publication Critical patent/WO2015135769A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/42—Syntactic analysis
    • G06F8/425—Lexical analysis
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/43—Checking; Contextual analysis

Definitions

  • the invention relates to the field of source code compilation and in particular relates to a method and a device for managing ambiguities in the analysis of the source code.
  • the compilers perform first-stage analysis operations through three main components.
  • the analysis steps generally include a first step of lexical analysis performed by a lexical analyzer, also known as 'scanner', which breaks the source code into lexical entities called tokens ("tokens" according to anglicism). spent).
  • tokens tokens
  • the tokens are then used by a parser to identify the syntactic structure of the
  • a syntactic tree structure is usually constructed from the tokens according to a grammar that defines the syntax of the language.
  • a semantic analyzer completes the syntax tree and produces a symbol table that contains the definitions of source code symbols. The tree from the parse string is then used by other compiler components to generate the target code.
  • the grammar of a programming language such as C is a set of symbols and rules of production.
  • the symbols are of two kinds: "terminal symbol” corresponding to a lexical entity of the language, and "non-terminal symbol".
  • One of the non-terminal symbols is designated as the starting point of the grammar.
  • a production rule defines how a sequence of symbols belonging to the grammar can correspond to a new symbol.
  • the parsing then consists in constructing a tree from a source code decomposed into lexical entities, a tree commonly called a parse tree whose vertex is the starting symbol of the grammar, the leaves are the terminal symbols, and each of which node is created by the application of the production rules.
  • the grammar of the C language makes it possible to define the syntactic elements of the language as instructions, via the symbols of the grammar, and to define the role of the various lexical elements
  • a "Declaration” consists of defining a "symbol” in the program and associating it with a "type", that is, information describing the data associated with or designated by this symbol such as numerical values (integers, real numbers, etc.) ), text, or composite elements
  • Type / symbol For declarations whose description is “typedef”, and whose symbol name is “typedef-name”. Such a symbol name may appear in the rest of the source code only in another type description, or on the right side of another declaration. Apart from this exception, such a symbol can only be found in a type description.
  • the lexical analyzer queries the symbol table to determine if the name has already been defined and what kind. If the name encountered is already defined as "typedef-name", the lexical element is associated with a "typedef-name” token, otherwise the lexical element is associated with an "identify” token.
  • a first type of implementation is to extend the grammar of the C standard and allow the appearance of "typedef-name” tokens from contextual lexical analysis. This is to make the statement "a * a" syntactically correct if 'a' is a "typedef-name” token.
  • This so-called extended grammar implementation is used in existing compilers such as 'GCC (GNU Compiler Collection) in versions prior to V4.0 or' PCC (Portable C Compiler) and is also used in C such tools 'CIL' (C Intermediate Language), 'Frama-C or' FrontC.
  • 'GCC GPU Compiler Collection
  • PCC Portable C Compiler
  • C C Intermediate Language
  • the grammar of the C standard only allows the generation of "identify" tokens in a statement, and performing an extended grammar is a complex operation with a high risk of introducing new
  • an extended grammar is significantly longer than the grammar of the C standard, thus increasing the complexity of parsing.
  • the development of an analyzer consists of generating the implementation of the parser by a compiler generator such compilers for example 'Berkeley or AT & T YACC,' GNU bison 'or' USF ANTLR '. It is the generator that supports the development of the rest of the parser and ensures that the parser behavior as well
  • Another type of implementation is to abandon the grammar of the C standard and to rewrite the parser by hand, for example in C or C ++.
  • This technique called the downward recursive parser because it assumes a certain type of parser, has the drawbacks of operating in a simple way, only for a smaller class of grammars, whose grammar of C is not part of it.
  • the parser thus developed is generally very complex, both in code size and behavior, and has no guarantee of conformity, except as a manual transcription element by element, of the norm of the language analyzed. In addition, it requires an expensive test procedure, which does not guarantee complete compliance. Tools using this technique are for example 'GNU GCC from version 4.0 or' Apple CLANG '.
  • Another type of known implementation consists in considering that a partial analysis of the source code is sufficient for the purposes of the implementation, and that a complete resolution of the problem of
  • An object of the present invention is to provide a method that exploits a norm grammar without modifying it or to use an extended grammar to handle ambiguities in symbol declarations.
  • the device of the present invention allows the lexical analyzer to generate selective tokens differentiating ambiguous or multivocal lexical entities.
  • the technical advantages of the present invention are to significantly reduce the complexity of a parser, both in terms of software development cost thanks to a smaller code size, than in terms of its validation because it ensures a respect at most. close to the norm and not a revalidation of extensions that would not be defined in the standard.
  • Another object of the present invention is to provide a method for activating within the lexical analyzer an indicator of differentiation of the issued tokens.
  • the invention will find application for source code compilers and analyzers of the programming language C, as well as its extensions.
  • the invention applies to the field of development and analysis tools, compilers and code verification tools for software security and engineering.
  • a device coupled to a lexical analyzer comprises components adapted to: identifying in a source code received by the lexical analyzer, a lexical entity having ambiguity of interpretation relative to a given grammar of language; identifying in a symbol table associated with the lexical analyzer the existence of a symbol for said lexical entity; determining for the identified symbol the definition stored in the symbol table; and generating a token representative of said definition.
  • the components for identifying a lexical entity having ambiguity of interpretation comprise means for determining whether the lexical entity is a name corresponding to a lexeme of type "typedef-name".
  • the device comprises means for defining in the grammar a first zone where the lexemes "typedef-name” are differentiated from lexemes "to identify”, and a second zone where said lexemes are not differentiated.
  • the device comprises means for generating an identifier token if the name is in the second zone of the grammar.
  • the device includes means for enabling a search in the symbol table if the name is in the first area of the grammar.
  • the components for determining the recorded symbol definition further include means for determining whether the symbol is defined as "typedef-name".
  • the components for generating a token comprise means for generating a 'typedef-name' token.
  • the components for generating a token include means for generating an identifier token if the symbol is not defined as "typedef-name”.
  • the source code is in the C language and the grammar is the standard grammar of the C language.
  • the device is implemented in a code compiler.
  • the invention further relates to a method for handling interpretation ambiguities with respect to a given language grammar, the method comprising the steps of: identifying in a source code received by a lexical analyzer a lexical entity having ambiguity of interpretation ; identifying in a symbol table associated with the lexical analyzer the existence of a symbol for said lexical entity; - determine for the identified symbol, the definition recorded in the symbol table; and generating a token representative of said definition.
  • the invention may operate in the form of a computer program product that includes code instructions for performing the claimed process steps when the program is run on a computer.
  • Figure 1 shows schematically the components of the device of the invention in a preferred implementation
  • Figures 2a and 2b show a sequence of steps of the method of the invention in one embodiment
  • Figure 1 shows schematically a device 100 comprising the components of a lexical, syntactic and semantic analysis chain for a preferred implementation of the invention in a compiler C.
  • a lexical analysis module 120 receives source code 102 in the C language.
  • the source code C can come from a file stored on the computer implementing the device 100 or from a remote computer or any other computer-readable medium.
  • the lexical analysis module 120 comprises a set of analysis components 122, common to any lexical analyzer, for receiving the source code and breaking it down into lexical entities.
  • the lexical analyzer further comprises a state change component 124 for switching a status indicator from a true state to a false state and vice versa.
  • the component is implemented in the form of an "Application Programming Interface" (API) according to known anglicism - including the functions for changing the status of the status indicator.
  • API Application Programming Interface
  • the lexical analyzer 120 further includes a test component 126 for testing the value of the status indicator.
  • the test checks the value of the status indicator to determine the nature of the token to be issued, either an "identify” token or a "typedef-name” token.
  • the lexical analysis module generates tokens 104 to a parser module 140.
  • the parsing module 140 analyzes the tokens received from the lexical analyzer, generates a syntax tree based on the grammar used, and generates semantic actions (AST) 106 which are processed by a semantic analysis module 1 60. a preferred implementation, the parsing module makes it possible to use the grammar of ISO / ANSI C without extension, in which the production listed in chapter "6.7.8 ISO / IEC 9899: 201 1" is removed.
  • the grammar of the C language is analyzed in order to determine a first zone where it is necessary to distinguish between the entities "typedef-name" and "identifier", and a second zone where it is not necessary to make this distinction. .
  • the area of distinction is called “active zone” and the zone without distinction is called “passive zone”.
  • the grammar is considered to represent a space where the parsing is to move in this space in agreement with a selected parsing method.
  • Each production of the grammar (and the non-terminal in the left part of the production) represents a point of this space and the paths to reach it.
  • Each point of this space can be assigned one or more semantic actions, which are performed when the parser has finished its analysis at this point. When a point is at the boundary between the two active and passive zones, a semantic action is associated with this point to activate the state indicator component of the lexical analyzer, according to two cases:
  • the state change component 124 is activated to switch the state indicator from the true state to the false state;
  • the state indicator is toggled from the false state to the true state.
  • the semantic analysis module 1 60 receives the actions
  • semantics from the parser to process them and complete the syntax tree It includes a component 1 62 for the definition of zoning of the grammar that defines the boundary between the active zone and the passive zone.
  • the semantic analysis module is also coupled to a memory 180.
  • the memory is organized as a table of symbols which makes it possible to record the definitions of the symbols.
  • the memory is also coupled to the lexical analysis module.
  • the elements (108) generated by the semantic analysis module are addressed to compiler components (not shown in the figure) to finalize the code generation and optimization operations.
  • Figures 2a and 2b illustrate the steps 200 operated by the component chain of Figure 1 in a preferred implementation of the invention.
  • the method starts on reading a sequence of characters of a source code 202 submitted to the lexical analyzer.
  • the next step 204 consists in extracting lexical entities from the source code.
  • the present invention is implemented in a TC compiler, in its analysis portion of C, with the Smalltalk® language in which the concepts of structures are classes, objects (class instances), methods ( object behaviors) and attributes (object state variables).
  • the lexical analyzer is a lexer class called CCScanner in charge of lexical analysis.
  • the device comprises a class "parser” called CCParser corresponding to the parser in charge of the parsing and part of the semantic analysis.
  • the device further comprises a class of management of the symbol table, called CScope.
  • the compiler generator used is Smalltalk Compiler-Compiler (SmaCC) which defines the abstract classes containing the lexical analyzer and parser behavioral base, as well as the parser compiler from the grammar and lexical description.
  • the method allows the step 206 to test whether an entity is a name corresponding to a lexeme type "typedef-name" or not. If the entity is not of type "typedef- name" (branch No), the lexical analyzer produces a token appropriate to the type of the entity (207). If the lexical entity is a name (Yes branch), the method sends a request (208) to the symbol table to search for the symbol associated with the entity. The symbol is returned to the lexical analyzer.
  • the method verifies (step 210) in which area of the grammar the entity is encountered to determine whether the entity is in the active or passive grammar area. If the entity encountered is in the passive grammar area (No branch), that is, the symbol a has already been met and that there is no ambiguity in its interpretation, the lexical analyzer will produce a token type Identifier '(step 21 6).
  • step 210 If the entity encountered is in the active grammar area (Yes branch, step 210), meaning there is ambiguity in its interpretation, the method proceeds to the next step (212) to check whether the symbol is set to this entity in the symbol table, and how it is defined (type or variable). If the symbol is defined and specified by its type as "typedef-name", the method proceeds to step 214 where the lexical analyzer produces a 'typedef-name' token. If the symbol has not been previously defined, or if the symbol is defined but not specified as "typedef-name" (branch No), the method proceeds to step 216 where the lexical analyzer produces a token identifier. (step 21 6).
  • the CCScanner class defines an attribute "fTypename" initialized to the value 'true' ('true' in English) when an instance of the scanner is created by the method (CCScanner "initialize).
  • the Device Control API consists of two methods, (CCScanner "setFTypename) and (CCScanner" unsetFTypename), the first setting the attribute to 'true', the second setting the attribute to 'false'.
  • the CCScanner lexical analyzer has a routine 'CCScanner' iDENTiFiER 'which is started when a lexeme of the type' identifier 'is detected as input. Contextualization is implemented by querying the symbol table (an instance of CScope). The implementation is performed by a test on the fTypename attribute following the following logical expression:
  • step 218 by parsing and executing semantic actions (106).
  • the method then makes it possible to verify (step 220) whether a point of the analysis is located at the boundary of the active zone and the passive zone. If the point is not on the boundary (branch No), the method allows generation of the syntax tree (step 228). If the point is located on the boundary of the two zones (Yes branch), the method makes it possible to determine the direction of movement in the space (222) and to verify from which zone of the grammar the entity originates. If the zone of origin is the active zone (branch Yes), meaning that the direction of movement consists of a transition from the active zone to the passive zone, the method makes it possible to actuate the zone passing device (step 224). Then, the method generates the syntax tree (228) taking into account the modifications.
  • the method makes it possible to actuate the active zone passing device (step 226). Then, the method makes it possible to generate nodes of the syntax tree (228) taking into account the modifications, and the corresponding semantic actions.
  • the boundary between the two zones is implemented in the semantic analyzer and the zones are materialized in the semantic actions defined in the grammar, according to the following realization:
  • the semantic action contains the code 'self unsetFTypename' which activates the components of the lexical analyzer.
  • the semantic action contains the code 'self setFTypename' which deactivates the components of the lexical analyzer.
  • the boundaries between the two zones are identified at the following points:
  • declaration_specifiers declaration_specifier
  • I struct_or_union_specifier ⁇ self unsetFTypename. ... ⁇ enum_specifier ⁇ self unsetFTypename. ... ⁇
  • declaration_specifiers ";" ⁇ self setFTypename. ... ⁇
  • declaration_specifiers abstract_declarator ⁇ self setFTypename. I declaration_specifiers ⁇ self setFTypename. ... ⁇
  • an optional device can be added to the lexical analyzer to check on a token of advance (known as "look-ahead token” in English).
  • a token of advance known as "look-ahead token” in English.
  • the optional device is implemented in the lexical analyzer in the form of an API corresponding to the device (CCParser »setFTypename) and (CCParser» unsetFTypename) adapted to operate the optional device as follows :
  • the token being processed is contained in the "currentToken” attribute of the parser. If the device (setFTypename) is activated, the token is a "IDENTIFIERId” and its symbol exists and is a type, then the token is changed to a "TypeNameld”.
  • the token is a "TypeNameld” then it is changed to a "IDENTIFIERId”. In other cases, the current token is not changed.
  • the method makes it possible to manage the ambiguities that may appear on the symbol declarations.
  • the present invention can be implemented from hardware and / or software elements. It may be available as a computer program product on a computer readable medium.
  • the support can be electronic, magnetic, optical, electromagnetic or be an infrared type of diffusion medium.
  • Such supports are, for example, Random Access Memory RAMs (ROMs), magnetic or optical tapes, disks or disks (Compact Disk - Read Only Memory (CD-ROM), Compact Disk - Read / Write (CD-R / W) and DVD).

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Le dispositif de la présente invention permet à un analyseur lexical de générer des jetons sélectifs pour un analyseur syntaxique, différentiant des entités lexicales ambigües. En particulier, le dispositif s'applique pour lever les ambigüités dans la grammaire du langage C définie dans la norme ISO/ANSI C.

Description

PROCEDE ET DISPOSITIF POUR GERER LES AMBIGUÏTES DANS L'ANALYSE D'UN CODE SOURCE
Domaine de l'invention
L'invention concerne le domaine de la compilation de code source et en particulier porte sur un procédé et un dispositif pour gérer les ambiguïtés dans l'analyse du code source.
Etat de la Technique
Pour transformer le code source d'un programme informatique écrit dans un langage source en un code objet dans un langage cible, les compilateurs effectuent en première phase des opérations d'analyse au travers de trois principaux composants. Les étapes d'analyse incluent en général, une première étape d'analyse lexicale opérée par un analyseur lexical, aussi connu sous l'appellation 'scanner', qui décompose le code source en entités lexicales appelées jetons (« tokens » selon l'anglicisme consacré). Les jetons sont ensuite utilisés par un analyseur syntaxique (« parser » en anglais) pour identifier la structure syntaxique du
programme. Une structure en arbre syntaxique est en général construite à partir des jetons selon une grammaire qui définit la syntaxe du langage. Un analyseur sémantique permet de compléter l'arbre syntaxique et de produire une table de symboles qui contient les définitions des symboles du code source. L'arbre issu de la chaîne d'analyse est ensuite utilisé par d'autres composants du compilateur pour générer le code cible.
La grammaire associée à un compilateur de langage C a été définie par l'Organisation Internationale de Standardisation (ISO en anglais) selon la norme ISO/IEC 9899:1999 pour spécifier entre autres la syntaxe et les règles sémantiques du langage C. Cette norme a évoluée et est référencée actuellement comme ISO/IEC 9899 :201 1 .
La grammaire du langage C définie dans cette norme introduit des ambiguïtés dans l'analyse syntaxique du langage quant aux symboles que l'on retrouve dans les déclarations connues «typedef-name» et « identifier » référencées dans la norme au chapitre « 6.7.8 ISO/IEC 9899:201 1 ».
En effet, la grammaire d'un langage de programmation tel que le langage C est un ensemble comprenant des symboles et des règles de production. Les symboles sont de deux sortes : « symbole terminal » correspondant à une entité lexicale du langage, et « symbole non- terminal ». Un des symboles non-terminal est désigné comme le point de départ de la grammaire. Une règle de production définit de quelle manière une suite de symboles appartenant à la grammaire peut correspondre à un nouveau symbole. L'analyse syntaxique consiste alors à construire un arbre à partir d'un code source décomposé en entités lexicales, arbre communément appelé arbre de parse dont le sommet est le symbole de départ de la grammaire, les feuilles sont les symboles terminaux, et dont chaque nœud est créé par l'application des règles de production. Ainsi la grammaire du langage C permet de définir les éléments syntaxiques du langage comme des instructions, via les symboles de la grammaire, et de définir le rôle des différents éléments lexicaux
(ponctuation, noms) dans la constitution de phrases correctes, via les règles de production de la grammaire. Cette grammaire, comme énoncé plus haut est ambiguë, et peut, pour une même séquence de caractères telle la séquence «a * a», aboutir à plusieurs constructions différentes.
Par exemple, l'élément syntaxique nommé « déclaration » peut se confondre avec l'élément nommé «expression », les deux éléments n'ayant pourtant pas du tout la même signification. En effet, une « déclaration » consiste à définir un « symbole » dans le programme et lui associer un « type », c'est à dire une information décrivant les données associées ou désignées par ce symbole telles des valeurs numériques (entières, réelles, etc ...), du texte ou des éléments composites
(complexes). Dans la grammaire, on trouve alors des éléments
« déclaration » ayant une partie gauche correspondant à une
« description de type », et une partie droite correspondant à un « nom de symbole », le tout constituant communément une association
« type/symbole ». Cependant, il existe une exception à l'association type/symbole pour les déclarations dont la description est « typedef », et dont le nom de symbole est « typedef-name ». Un tel nom de symbole ne peut apparaître dans le reste du code source que soit dans une autre description de type, soit dans la partie droite d'une autre déclaration. Hormis cette exception, un tel symbole ne peut que se trouver dans une description de type.
Il est possible sous certaines conditions de redéfinir un symbole, et lui associer une description de type différente. Il est ainsi tout à fait envisageable de redéfinir un symbole « typedef-name » en un symbole d'un autre type. Par exemple, la suite de caractères suivante : « a * a » peut s'interpréter comme une « déclaration » ayant pour description de type la partie gauche « a * » et pour définition de symbole la partie droite « a », si l'élément « a » a été précédemment définit comme symbole "typedef-name".
Cependant, si le symbole « a » n'a pas été précédemment défini comme « typedef-name », cette même phrase « a * a » rencontrée dans le code, peut prendre un sens tout différent, et être une expression qui décrit un calcul, en l'occurrence la multiplication de la valeur représentée par « a » par elle-même.
Il existe des solutions pour permettre de gérer ces ambiguïtés. Une approche consiste de manière systématique à contextualiser l'analyseur lexical, l'analyseur syntaxique et l'analyseur sémantique en leur associant une mémoire pour enregistrer les définitions des symboles dans une table appelée table des symboles. Le principe de contextualisation opère suivant le découpage fonctionnel suivant :
- l'analyseur sémantique identifie la définition d'un symbole et la
description de type associée à ce symbole et l'enregistre dans la table des symboles ; - lors de la rencontre d'un nom (par exemple «a») dans le code
source entrant, l'analyseur lexical interroge la table des symboles pour déterminer si le nom a déjà été défini et de quelle nature. Si le nom rencontré est déjà défini comme « typedef-name », l'élément lexical est associé à un jeton « typedef-name » sinon l'élément lexical est associé à un jeton « identifier ».
Cependant cette approche implique que la règle listée dans la norme ISO/IEC 9899:201 1 au chapitre en 6.7.8 soit retirée de la grammaire: typedef-name:
identifier et que le symbole « typedef-name » devienne un symbole terminal de la grammaire, c'est à dire un jeton produit par l'analyseur lexical.
Sur la base de cette modification, différentes implémentations d'analyseurs C, que ce soit des compilateurs ou des outils d'analyse ont vu le jour.
Un premier type d'implémentation consiste à étendre la grammaire de la norme C et permettre l'apparition de jetons « typedef-name » issus de l'analyse lexicale contextuelle. Ceci vise à rendre syntaxiquement correcte la déclaration «a * a » dans le cas où 'a' est un jeton « typedef- name ». Cette implémentation dite d'une grammaire étendue est utilisée dans des compilateurs existants tels 'GCC (GNU Compiler Collection) dans les versions antérieures à la V4.0 ou 'PCC (Portable C Compiler) et est aussi utilisée dans des outils d'analyse de C tels les outils 'CIL' (C Intermediate Language), 'Frama-C ou encore 'FrontC. Or, la grammaire de la norme C n'autorise que la génération de jetons « identifier » dans une déclaration, et réaliser une grammaire étendue est une opération complexe présentant un risque élevé d'introduire de nouvelles
ambiguïtés.
Un autre inconvénient, est qu'une grammaire étendue est significativement plus longue que la grammaire de la norme C, augmentant ainsi la complexité de l'analyse syntaxique. En effet, une fois une grammaire étendue obtenue, le développement d'un analyseur consiste à générer l'implémentation de l'analyseur syntaxique par un générateur de compilateur tels les compilateurs par exemple 'Berkeley ou AT&T YACC, 'GNU bison' ou encore 'USF ANTLR'. C'est le générateur qui prend en charge le développement du reste de l'analyseur syntaxique et assure que le comportement de l'analyseur syntaxique ainsi
implémenté et son interaction avec l'analyseur lexical et avec l'analyseur sémantique est conforme à la grammaire.
Un autre type d'implémentation consiste à abandonner la grammaire de la norme C et à réécrire à la main l'analyseur syntaxique, par exemple en langage C ou C++. Cette technique, dite de l'analyseur syntaxique récursif descendant car elle suppose un certain type d'analyseur, présente les inconvénients de ne fonctionner de manière simple, que pour une classe plus réduite de grammaires, dont la grammaire de C ne fait pas partie. L'analyseur syntaxique ainsi développé est généralement très complexe, tant en taille de code qu'en comportement, et ne bénéficie d'aucune garantie de conformité, si ce n'est en tant que transcription manuelle élément par élément, de la norme du langage analysé. De plus, il requière une coûteuse procédure de test, qui ne garantit pas pour autant une conformité complète. Des outils utilisant cette technique sont par exemple 'GNU GCC à partir de la version 4.0 ou 'Apple CLANG'.
Un autre type d'implémentation connue consiste à considérer qu'une analyse partielle du code source est suffisante pour les buts de l'implémentation, et qu'une résolution complète du problème de
l'ambiguïté est alors inutile. Dans ce cas, l'analyseur syntaxique est considéré comme incapable de valider l'intégralité des syntaxes correctes, mais il est capable de réajuster via des stratégies ad-hoc lorsqu'il rencontre une ligne ambiguë. Des outils comme 'LIP6 Coccinelle' ou des outils de réingénierie de code utilisent cette approche, leurs objectifs se satisfaisant d'une analyse syntaxique partielle du code source. Une telle approche n'est pas appropriée pour un outil de compilation.
Ainsi les solutions connues présentent des inconvénients et ne répondent pas au besoin d'exploiter sans changement une grammaire normée dans un compilateur de code source.
Il existe alors le besoin de fournir un dispositif et un procédé pour gérer les ambiguïtés relatives aux déclarations de symboles pour une grammaire normée. L'invention proposée permet de répondre à ce besoin.
Résumé de l'invention Un objet de la présente invention est de proposer un procédé qui exploite une grammaire normée sans la modifier ni avoir recours à une grammaire étendue pour gérer les ambiguïtés des déclarations de symboles. Le dispositif de la présente invention permet à l'analyseur lexical de générer des jetons sélectifs différentiant les entités lexicales ambiguës ou multivoques.
Les avantages techniques de la présente invention sont de réduire significativement la complexité d'un analyseur syntaxique, tant en terme de coût de développement logiciel grâce à une taille de code plus réduite, qu'en terme de sa validation car il assure un respect au plus près de la norme et non une revalidation d'extensions qui ne seraient pas définies dans la norme.
Un autre objet de la présente invention est de proposer un procédé permettant d'activer au sein de l'analyseur lexical un indicateur de différentiation des jetons émis.
Avantageusement, l'invention trouvera application pour des compilateurs de code source et des analyseurs du langage de programmation C, ainsi que ses extensions. En particulier, l'invention s'applique au domaine des outils de développement et d'analyse, des compilateurs et des outils de vérification de code pour la sûreté et l'ingénierie du logiciel.
Pour obtenir les résultats recherchés, un dispositif, un procédé et un produit programme d'ordinateur sont proposés. En particulier, un dispositif couplé à un analyseur lexical comprend des composants adaptés pour : identifier dans un code source reçu par l'analyseur lexical, une entité lexicale présentant une ambiguïté d'interprétation relativement à une grammaire de langage donné ; identifier dans une table des symboles associée à l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale ; déterminer pour le symbole identifié, la définition enregistrée dans la table des symboles; et générer un jeton représentatif de ladite définition.
Avantageusement, les composants pour identifier une entité lexicale présentant une ambiguïté d'interprétation comprennent des moyens pour déterminer si l'entité lexicale est un nom correspondant à un lexème de type « typedef-name ».
Dans un mode de réalisation, le dispositif comprend des moyens pour définir dans la grammaire une première zone où les lexèmes « typedef-name » sont différenciés de lexèmes « identifier », et une deuxième zone où lesdits lexèmes ne sont pas différenciés.
Avantageusement, le dispositif comprend des moyens pour générer un jeton Identifier' si le nom est dans la deuxième zone de la grammaire. Dans un mode de réalisation, le dispositif comprend des moyens pour activer une recherche dans la table des symboles si le nom est dans la première zone de la grammaire.
Dans une variante, les composants pour déterminer la définition de symbole enregistrée comprennent de plus des moyens pour déterminer si le symbole est défini comme « typedef-name ». Selon cette variante, les composants pour générer un jeton comprennent des moyens pour générer un jeton 'typedef-name'. Dans une autre variante, les composants pour générer un jeton comprennent des moyens pour générer un jeton Identifier' si le symbole n'est pas défini comme « typedef-name ».
Avantageusement, le code source est en langage C et la grammaire est la grammaire normée du langage C.
Dans une implémentation préférentielle, le dispositif est implémenté dans un compilateur de code.
L'invention concerne de plus un procédé pour gérer les ambiguïtés d'interprétation relativement à une grammaire de langage donné, le procédé comprenant les étapes suivantes : identifier dans un code source reçu par un analyseur lexical, une entité lexicale présentant une ambiguïté d'interprétation; identifier dans une table des symboles associée à l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale ; - déterminer pour le symbole identifié, la définition enregistrée dans la table des symboles; et générer un jeton représentatif de ladite définition.
L'invention peut opérer sous la forme d'un produit programme d'ordinateur qui comprend des instructions de code permettant d'effectuer les étapes du procédé revendiqué lorsque le programme est exécuté sur un ordinateur.
Description des figures Différents aspects et avantages de l'invention vont apparaître en appui de la description d'un mode préféré d'implémentation de l'invention mais non limitatif, avec référence aux figures ci-dessous :
La figure 1 montre schématiquement les composants du dispositif de l'invention dans une implémentation préférentielle;
Les figures 2a et 2b montrent un enchaînement des étapes de la méthode de l'invention dans un mode de réalisation ;
Description détaillée de l'invention
Référence est faite à la figure 1 qui montre de manière schématique un dispositif 100 comportant les composants d'une chaîne d'analyse lexicale, syntaxique et sémantique pour une implémentation préférentielle de l'invention dans un compilateur C.
Un module d'analyse lexicale 120 reçoit du code source 102 en langage C. Le code source C peut provenir d'un fichier stocké sur l'ordinateur implémentant le dispositif 100 ou d'un ordinateur distant ou de tout autre support lisible par un ordinateur. Le module d'analyse lexicale 120 comprend un ensemble de composants d'analyse 122, communs à tout analyseur lexical, pour recevoir le code source et le décomposer en entités lexicales.
L'analyseur lexical selon l'invention comprend de plus un composant de changement d'état 124 pour basculer un indicateur d'état d'un état Vrai' à un état 'faux' et vice versa. Dans une implémentation préférentielle, le composant est implémenté sous la forme d'une « Application Programming Interface » - (API) selon l'anglicisme connu - comprenant les fonctions permettant le changement de l'état de l'indicateur d'état.
L'analyseur lexical 120 comprend en outre un composant de test 126 pour tester la valeur de l'indicateur d'état. Le test permet de vérifier la valeur de l'indicateur d'état pour déterminer la nature du jeton à émettre, soit un jeton « identifier », soit un jeton « typedef-name ». Le module d'analyse lexicale produit des jetons 104 vers un module d'analyse syntaxique 140.
Le module d'analyse syntaxique 140 analyse les jetons reçus de l'analyseur lexical, génère un arbre syntaxique basé sur la grammaire utilisée, et génère des actions sémantiques (AST) 106 qui sont traitées par un module d'analyse sémantique 1 60. Dans une implémentation préférentielle, le module d'analyse syntaxique permet d'exploiter la grammaire de la norme ISO/ANSI C sans extension, dans laquelle la production listée au chapitre « 6.7.8 ISO/IEC 9899:201 1 » est retirée.
La grammaire du langage C est analysée de manière à déterminer une première zone où il est nécessaire de faire la distinction entre les entités « typedef-name » et « identifier », et une deuxième zone où il n'est pas nécessaire de faire cette distinction. Pour faciliter la compréhension de l'invention, dans la suite de la description, la zone de distinction est dénommée « zone active » et la zone sans distinction est dénommée « zone passive ». Par ailleurs, la grammaire est considérée représenter un espace où l'analyse syntaxique consiste à se déplacer dans cet espace en accord avec une méthode d'analyse syntaxique choisie. Chaque production de la grammaire (et le non-terminal en partie gauche de la production) représente un point de cet espace et les chemins permettant de l'atteindre. Chaque point de cet espace peut se voir attribuer une ou plusieurs actions sémantiques, qui sont effectuées lorsque l'analyseur syntaxique a terminé son analyse en ce point. Lorsqu'un point se situe à la frontière entre les deux zones active et passive, une action sémantique est associée à ce point pour activer le composant d'indicateur d'état de l'analyseur lexical, suivant deux cas :
- si le déplacement dans l'espace consiste en un passage de la zone active à la zone passive, le composant de changement d'état 124 est activé pour basculer l'indicateur d'état de l'état vrai à l'état faux ;
- si le déplacement dans l'espace consiste en un passage de la zone passive à la zone active, l'indicateur d'état est basculé de l'état faux à l'état vrai.
Le module d'analyse sémantique 1 60 reçoit les actions
sémantiques issues de l'analyseur syntaxique pour les traiter et compléter l'arbre syntaxique. Il comprend un composant 1 62 pour la définition de zonage de la grammaire qui définit la frontière entre la zone active et la zone passive.
Le module d'analyse sémantique est de plus couplé à une mémoire 180. Dans une implémentation préférentielle, la mémoire est organisée comme une table des symboles qui permet d'enregistrer les définitions des symboles. La mémoire est aussi couplée au module d'analyse lexicale.
Les éléments (108) générés par le module d'analyse sémantique sont adressés à des composants du compilateur (non montrés sur la figure) pour finaliser les opérations de génération et d'optimisation de code.
Les figures 2a et 2b illustrent les étapes 200 opérées par la chaîne de composants de la figure 1 dans une implémentation préférentielle de l'invention. En figure 2a, le procédé débute à la lecture d'une suite de caractères d'un code source 202 soumis à l'analyseur lexical. L'étape suivante 204 consiste à extraire du code source des entités lexicales. Dans un mode de réalisation, la présente invention est implémentée dans un compilateur TC, dans sa portion analyse de C, avec le langage Smalltalk® dans lequel les concepts de structures sont les classes, les objets (les instances de classes), les méthodes (les comportements des objets) et les attributs (les variables d'état des objets). L'analyseur lexical est une classe « lexer » appelée CCScanner en charge de l'analyse lexicale. Le dispositif comprend une classe « parser » appelée CCParser correspondant à l'analyseur syntaxique en charge de l'analyse syntaxique et d'une partie de l'analyse sémantique. Le dispositif comprend de plus une classe de gestion de la table des symboles, appelée CScope. Dans cette implémentation préférentielle, le générateur de compilateur utilisé est Smalltalk Compiler-Compiler (SmaCC) qui définit les classes abstraites contenant la base comportementale de l'analyseur lexical et de l'analyseur syntaxique, ainsi que le compilateur d'analyseurs à partir de la grammaire et de la description lexicale.
Lorsque les entités lexicales sont extraites, le procédé permet à l'étape 206 de tester si une entité est un nom correspondant à un lexème de type « typedef-name » ou non. Si l'entité n'est pas de type « typedef- name » (branche Non), l'analyseur lexical produit un jeton approprié au type de l'entité (207). Si l'entité lexicale est un nom (branche Oui), le procédé envoie une requête (208) vers la table des symboles pour rechercher le symbole associé à l'entité. Le symbole est renvoyé à l'analyseur lexical.
Le procédé permet de vérifier (étape 210) dans quelle zone de la grammaire l'entité est rencontrée pour déterminer si l'entité est dans la zone de grammaire active ou passive. Si l'entité rencontrée est dans la zone de grammaire passive (branche Non), c'est-à-dire que le symbole a déjà été rencontré et qu'il n'existe pas d'ambiguïté dans son interprétation, l'analyseur lexical va produire un jeton de type Identifier' (étape 21 6).
Si l'entité rencontrée est dans la zone de grammaire active (branche Oui, étape 210), signifiant qu'il existe une ambiguïté dans son interprétation, le procédé poursuit à l'étape suivante (212) pour vérifier si le symbole est défini pour cette entité dans la table des symboles, et comment il est défini (type ou variable). Si le symbole est défini et qu'il est spécifié par son type comme « typedef-name » (branche Oui), le procédé poursuit à l'étape 214 où l'analyseur lexical produit un jeton 'typedef- name'. Si le symbole n'a pas été précédemment défini, ou si le symbole est défini mais pas spécifié comme « typedef-name » (branche Non), le procédé poursuit à l'étape 21 6 où l'analyseur lexical produit un jeton Identifier' (étape 21 6). Dans une réalisation implémentée dans un compilateur TC, la classe CCScanner définit un attribut « fTypename » initialisé à la valeur 'vrai' ('true' en anglais) à la création d'une instance du scanner par la méthode (CCScanner»initialize). L'API de contrôle du dispositif est constituée de deux méthodes, (CCScanner»setFTypename) et (CCScanner»unsetFTypename), la première mettant l'attribut à 'true', la deuxième mettant l'attribut à 'false'. Si un message 'setFTypename' est envoyé à une instance de CCScanner, l'attribut est mis à 'true', et si un message 'unsetFTypename' est envoyé à une instance de CCScanner, l'attribut est mis 'false'. Il est à noter que plusieurs instances peuvent cohabiter de manière indépendante dans le programme, avec des états décorrélés.
L'analyseur lexical CCScanner possède une routine 'CCScanner»iDENTiFiER' qui est lancée quand un lexème du type « identifier » est détecté en entrée. La contextualisation est implémentée en effectuant une requête sur la table des symboles (une instance de CScope). L'implémentation est réalisée par un test sur l'attribut fTypename suivant l'expression logique suivante :
(fTypename and: [ symbol notNil and: [ symbol isTypename ] ]) signifiant que si fTypename est égal à 'true', que le symbole existe
(présence antérieure d'une déclaration dans le code source analysé) et qu'il est défini comme un 'type', alors par l'ensemble de ces conditions, l'analyseur lexical produit un jeton de type TypeNameld, sinon il produit un jeton de type IDENTIFIERId. Revenant à la figure 2b, après la production d'un jeton, soit
Identifier' (21 6), soit 'typedef-name' (214), le procédé poursuit à l'étape 218 par l'analyse syntaxique et l'exécution des actions sémantiques (106).
Le procédé permet alors de vérifier (étape 220) si un point de l'analyse est situé à la frontière de la zone active et de la zone passive. Si le point n'est pas sur la frontière (branche Non), le procédé permet la génération de l'arbre de syntaxe (étape 228). Si le point est situé sur la frontière des deux zones (branche Oui), le procédé permet de déterminer le sens de déplacement dans l'espace (222) et vérifier de quelle zone de la grammaire l'entité provient. Si la zone de provenance est la zone active (branche Oui), signifiant que le sens de déplacement consiste en un passage de la zone active à la zone passive, le procédé permet d'actionner le dispositif de passage en zone (étape 224). Puis le procédé permet de générer l'arbre de syntaxe (228) prenant en compte les modifications.
Si à la vérification de l'étape 222, la zone de provenance est la zone passive (branche Non), signifiant que le déplacement dans l'espace consiste en un passage de la zone passive à la zone active, le procédé permet d'actionner le dispositif de passage en zone active (étape 226). Puis le procédé permet de générer des nœuds de l'arbre de syntaxe (228) prenant en compte les modifications, et les actions sémantiques correspondantes.
Dans une implémentation préférentielle intégrée au compilateur TC, la frontière entre les deux zones est implémentée dans l'analyseur sémantique et les zones sont matérialisées dans les actions sémantiques définies dans la grammaire, suivant la réalisation suivante :
- pour le passage de la zone active à la zone passive : l'action sémantique contient le code 'self unsetFTypename' qui active les composants de l'analyseur lexical.
- pour le passage de la zone passive à la zone active : l'action sémantique contient le code 'self setFTypename' qui désactive les composants de l'analyseur lexical.
A tire d'exemple selon une implémentation pour la grammaire du langage C, pour une analyse qui commence en zone active, les frontières entre les deux zones sont identifiées aux points suivants :
- pour le passage de la zone active à la zone passive :
• Production : init_comma : « , » dans init_declaration_list
• Production : declaration_specifiers : declaration_specifier
• Production : type_specifier
: "void" {self unsetFTypename. ...}
I "char" {self unsetFTypename. ...}
I "short" {self unsetFTypename. ...}
I "int" {self unsetFTypename. ...}
I "long" {self unsetFTypename. ...}
I "float" {self unsetFTypename. ...}
I "double" {self unsetFTypename. ...}
I "signed" {self unsetFTypename. ...}
I "unsigned" {self unsetFTypename. ...}
I "_Bool" {self unsetFTypename. ...}
I "_Complex" {self unsetFTypename. ...}
I struct_or_union_specifier {self unsetFTypename. ...} enum_specifier {self unsetFTypename. ...}
<TypeName> {self unsetFTypename. ...}
Production : kr_declaration_specifiers:
kr_declaration_specifier {self unsetFTypename.
- pour le passage de la zone passive à la zone active :
• Production : déclaration
: declaration_specifiers ";" {self setFTypename. ...}
• Production : direct_declarator
: <IDENTIFIER>
{self setFTypename. ...}
• Production : parameter_declaration
|declaration_specifiers abstract_declarator {self setFTypename. I declaration_specifiers {self setFTypename. ...}
• Production : type_name
: specifier_qualifier_list {self setFTypename. ...}
|specifier_qualifier_list abstract_declarator{self setFTypename. .
• Production : param_paren
: "(" {self setFTypename. ...}
• Production : left_block
: <LEFT_BLOCK> {self setFTypename. ΛΊ '}
Dans un mode de réalisation alternative, selon la technologie de l'analyseur syntaxique, un dispositif optionnel peut être ajouté à l'analyseur lexical pour faire une vérification sur un jeton d'avance (connu comme « look-ahead token » en anglais). Lors d'un changement d'état de l'indicateur d'état «typedefname » pour un tel jeton, qui a déjà été lu et généré par l'analyseur lexical mais pas encore traité complètement par l'analyseur syntaxique, s'il s'agit d'un jeton «identifier » et que le dispositif est mis à « vrai », le jeton est alors revérifié pour le passer en jeton « typedef-name » si l'action est appropriée. S'il s'agit d'un jeton « typedef- name » et que le dispositif est mis à « faux », le jeton est passé en jeton « identifier ».
Dans une implémentation préférentielle intégrée au compilateur TC, le dispositif optionnel est réalisé dans l'analyseur lexical sous la forme d'une API correspondante au dispositif (CCParser»setFTypename) et (CCParser»unsetFTypename) adaptée pour opérer le dispositif optionnel de la manière suivante :
Le jeton en cours de traitement est contenu dans l'attribut « currentToken » de l'analyseur syntaxique. Si le dispositif (setFTypename) est activé, que le jeton est un « IDENTIFIERId » et son symbole existe et est un type, alors le jeton est changé en un « TypeNameld ».
Si le dispositif (unsetFTypename) est désactivé, que le jeton est un « TypeNameld » alors il est changé en un « IDENTIFIERId ». Dans les autres cas, le jeton en cours n'est pas modifié.
Ainsi le procédé permet de gérer les ambiguïtés pouvant se présenter sur les déclarations de symboles.
La présente invention peut s'implémenter à partir d'éléments matériel et/ou logiciel. Elle peut être disponible en tant que produit programme d'ordinateur sur un support lisible par ordinateur. Le support peut être électronique, magnétique, optique, électromagnétique ou être un support de diffusion de type infrarouge. De tels supports sont par exemple, des mémoires à semi-conducteur (Random Access Memory RAM, Read-Only Memory ROM), des bandes, des disquettes ou disques magnétiques ou optiques (Compact Disk - Read Only Memory (CD- ROM), Compact Disk - Read/Write (CD-R/W) and DVD).

Claims

Revendications
Un dispositif pour gérer les ambiguïtés dans un code source, comprenant des composants logiciels adaptés pour :
- identifier dans un code source reçu par un analyseur lexical, une entité lexicale présentant une ambiguïté d'interprétation relativement à une grammaire de langage donné, ladite grammaire pouvant être définie par une première zone où des lexèmes « typedef-name » sont différenciés de lexèmes « identifier », et une deuxième zone où lesdits lexèmes ne sont pas différenciés ;
- déterminer si l'entité lexicale est un nom correspondant à un lexème de type « typedef-name » et si le nom appartient à la première zone de la grammaire ;
- si oui, identifier dans une table des symboles associée à l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale et la définition enregistrée pour ledit symbole; et
- générer un jeton 'typedef-name' .
Le dispositif selon la revendication 1 comprenant de plus des moyens pour générer un jeton Identifier' si le nom correspond à un lexème de type « typedef-name » et appartient à la deuxième zone de la grammaire.
Le dispositif selon la revendication 1 dans lequel les composants pour générer un jeton comprennent des moyens pour générer un jeton Identifier' si le symbole n'est pas défini dans la table des symboles comme « typedef-name ». 4. Le dispositif selon l'une quelconque des revendications 1 à 3, dans lequel le code source est en langage C et la grammaire est la grammaire normée du langage C. 5. Un compilateur de code comprenant les composants logiciels du dispositif selon l'une quelconque des revendications 1 à 4.
6. Un procédé pour gérer les ambiguïtés d'interprétation relativement à une grammaire de langage donné, ladite grammaire pouvant être définie par une première zone où des lexèmes « typedef-name » sont différenciés de lexèmes « identifier », et une deuxième zone où lesdits lexèmes ne sont pas différenciés, le procédé comprenant les étapes suivantes :
- identifier dans un code source reçu par un analyseur lexical, une entité lexicale présentant une ambiguïté d'interprétation ;
- déterminer si l'entité lexicale est un nom correspondant à un lexème de type « typedef-name » et si le nom appartient à la première zone de la grammaire ;
- si oui, identifier dans une table des symboles associée à l'analyseur lexical, l'existence d'un symbole pour ladite entité lexicale et la définition enregistrée pour ledit symbole; et
- générer un jeton 'typedef-name'.
7. Un produit programme d'ordinateur, ledit programme d'ordinateur comprenant des instructions de code permettant d'effectuer tout ou partie des étapes du procédé selon la revendication 6, lorsque ledit programme est exécuté sur un ordinateur.
PCT/EP2015/054187 2014-03-10 2015-02-27 Procede et dispositif pour gerer les ambigüites dans l'analyse d'un code source Ceased WO2015135769A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP15709632.2A EP3117307A1 (fr) 2014-03-10 2015-02-27 Procede et dispositif pour gerer les ambigüites dans l'analyse d'un code source
US15/123,937 US20170024193A1 (en) 2014-03-10 2015-02-27 Method and device for managing ambiguities in the analysis of a source code

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1451922 2014-03-10
FR1451922A FR3018368B1 (fr) 2014-03-10 2014-03-10 Procede et dispositif pour gerer les ambiguites dans l'analyse d'un code source

Publications (1)

Publication Number Publication Date
WO2015135769A1 true WO2015135769A1 (fr) 2015-09-17

Family

ID=50639763

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/054187 Ceased WO2015135769A1 (fr) 2014-03-10 2015-02-27 Procede et dispositif pour gerer les ambigüites dans l'analyse d'un code source

Country Status (4)

Country Link
US (1) US20170024193A1 (fr)
EP (1) EP3117307A1 (fr)
FR (1) FR3018368B1 (fr)
WO (1) WO2015135769A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11537791B1 (en) * 2016-04-05 2022-12-27 Intellective Ai, Inc. Unusual score generators for a neuro-linguistic behavorial recognition system
RU2016137177A (ru) 2016-09-16 2018-03-19 Оракл Интернэйшнл Корпорейшн Усовершенствованное преобразование исходного кода языка программирования
RU2016137176A (ru) * 2016-09-16 2018-03-19 Оракл Интернэйшнл Корпорейшн Связывание преобразованного исходного кода с первоначальным исходным кодом с помощью метаданных
CN116414395A (zh) * 2021-12-30 2023-07-11 广东优特云科技有限公司 一种基于递归下降算法的语法树构建方法及装置
CN114090017B (zh) 2022-01-20 2022-06-24 北京大学 编程语言的解析方法及装置、非易失性存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5560010A (en) * 1993-10-28 1996-09-24 Symantec Corporation Method for automatically generating object declarations

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
"Field Programmable Logic and Application", vol. 94, 1 January 1980, SPRINGER BERLIN HEIDELBERG, Berlin, Heidelberg, ISBN: 978-3-54-045234-8, ISSN: 0302-9743, article DAVID A. WATT: "Rule splitting and attribute-directed parsing", pages: 363 - 392, XP055132887, DOI: 10.1007/3-540-10250-7_29 *
DEREK PARTRIDGE: "Specifications and an implementation of the type-ambiguity problem in pascal", SOFTWARE: PRACTICE AND EXPERIENCE, vol. 15, no. 12, 1 December 1985 (1985-12-01), pages 1141 - 1158, XP055132891, ISSN: 0038-0644, DOI: 10.1002/spe.4380151203 *
MALLOY B A ET AL: "DECORATING TOKENS TO FACILITATE RECOGNITION OF AMBIGUOUS LANGUAGE CONSTRUCTS", SOFTWARE PRACTICE & EXPERIENCE, WILEY & SONS, BOGNOR REGIS, GB, vol. 33, no. 33, 1 January 2003 (2003-01-01), pages 19 - 39, XP001141806, ISSN: 0038-0644, DOI: 10.1002/SPE.493 *
SCOTT MCPEAK ET AL: "Elkhound: A Fast, Practical GLR Parser Generator", 18 February 2004, 13TH INTERNATIONAL CONFERENCE ON COMPILER CONSTRUCTION (CC 2004), BARCELONA, SPAIN, MARCH 29 - APRIL 2, 2004; [LECTURE NOTES IN COMPUTER SCIENCE ; 2985], SPRINGER-VERLAG, BERLIN/HEIDELBERG, PAGE(S) 73 - 88, ISBN: 978-3-540-21297-3, XP019003391 *
TERENCE J PARR ET AL: "Adding semantic and syntactic predicates to LL(k): pred-LL(k)", 7 April 1994, 5TH INTERNATIONAL CONFERENCE ON COMPILER CONSTRUCTION (CC '94). EDINBURGH, U.K., APRIL 7-9, 1994; [LECTURE NOTES IN COMPUTER SCIENCE ; 786], SPRINGER, BERLIN [U.A.], PAGE(S) 263 - 277, ISBN: 978-3-540-57877-2, pages: 263 - 277, XP019182637 *

Also Published As

Publication number Publication date
FR3018368B1 (fr) 2017-12-15
US20170024193A1 (en) 2017-01-26
EP3117307A1 (fr) 2017-01-18
FR3018368A1 (fr) 2015-09-11

Similar Documents

Publication Publication Date Title
Shah et al. Resolving ambiguities in natural language software requirements: a comprehensive survey
US20220197611A1 (en) Intent-based machine programming
Stabler Two models of minimalist, incremental syntactic analysis
RU2610241C2 (ru) Способ и система синтеза текста на основе извлеченной информации в виде rdf-графа с использованием шаблонов
WO2015135769A1 (fr) Procede et dispositif pour gerer les ambigüites dans l&#39;analyse d&#39;un code source
US10803254B2 (en) Systematic tuning of text analytic annotators
FR2906049A1 (fr) Procede, mis en oeuvre par ordinateur, de developpement d&#39;une ontologie a partir d&#39;un texte en langage naturel
US20070112718A1 (en) Method and apparatus to enable integrated computation of model-level and domain-level business semantics
WO2006122886A1 (fr) Methode dynamique de generation de documents xml a partir d&#39;une base de donnees
US20150261507A1 (en) Validating sql queries in a report
Bader et al. AI in software engineering at Facebook
WO2006136565A1 (fr) Procede de traitement de donnees compatible avec un formalisme de modelisation d&#39;objets
US20060129418A1 (en) Method and apparatus for analyzing functionality and test paths of product line using a priority graph
Bettini et al. Supporting safe metamodel evolution with edelta
WO2007001637A2 (fr) Utilisation de types de donnees forts pour exprimer des grammaires de reconnaissance vocale dans des programmes logiciels
EP1788497A1 (fr) Motif de conception et procédé de transformation d&#39;un modèle objet
Muller et al. HUTN as a bridge between modelware and grammarware-an experience report
WO2011098677A1 (fr) Systeme et un procede de gestion et de compilation d&#39;un cadre d&#39;applications de developpement logiciel.
Subahi et al. A New Framework for Classifying Information Systems Modelling Languages.
EP2182435A1 (fr) Procédé d&#39;implémentation d&#39;une machine à états finis via l&#39;utilisation d&#39;annotations Java
Ratiu et al. Towards a repository of common programming technologies knowledge
FR2887348A1 (fr) Structure de donnees compatible avec un formalisme de modelisation d&#39;objets et procede de traitement de donnees
EP2738693A1 (fr) Procédé d&#39;enregistrement de données hiérarchisées
FR2821972A1 (fr) Procede pour permettre un dialogue homme-machine
Lorenzo et al. Supporting safe metamodel evolution with edelta

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15709632

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2015709632

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 15123937

Country of ref document: US

Ref document number: 2015709632

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE