Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EDT:Extensible Compiler Development"

(Compiler updates)
Line 55: Line 55:
 
== Compiler updates<br> ==
 
== Compiler updates<br> ==
  
TBD<br>
+
The following changes are made to the compiler:
 +
 
 +
#Package name is now represented as a string (for example "pkg1,pkg2") instead of a string[]. This is so that we are not tied to object identity of the string[] and allow us to easily change to a case sensitive package name.
 +
#All references to string interning should be removed. Instead, we will go through a&nbsp;common class to convert strings (for now, this means just lowercasing the string).
 +
#There will be new binders/binding completors&nbsp;for AnnotationType and StereotypeType. This is because these are not represented as records in the IRs.
  
 
<br>
 
<br>

Revision as of 11:59, 16 July 2012

This page covers the work being done to make the compiler more extensible. Validation, for example, will be made extensible. A new model will be created so that bound AST will use IRs instead of bindings. The old binding model will still exist so that tooling written against it does not need to be rewritten. New tooling will be encouraged to use the new IR-based model.


Where to get the code

CVS repository: :extssh:<user>@dev.eclipse.org:/cvsroot/tools

Projects:
org.eclipse.edt.compiler
org.eclipse.edt.mof
org.eclipse.edt.mof.egl

Branch:
edtExtensibleCore


How to run the code

Right now you can only compile in SDK mode (the IDE builder will NOT work). Take a look at the "EGL2IR XML" Java Application launch configuration that's predefined. This will prompt you a couple times if you run it, or you can create a copy of this launch configuration and hard-code some values if you don't want to be prompted. Here's an example of hardcoded arguments:

-eglpath "/home/justin/.workspaces/edt-ext/test/EGLSource/" -irDestination "/home/justin/.workspaces/edt-ext/test/batchbin" -xmlOut "/home/justin/.workspaces/edt-ext/test/EGLSource/pkg/prog.egl"


Parser Updates

Several changes to the parser/lexer grammer files will be made:

  1. Remove primitive types
  2. Add ability for name types to include parameters. This is to support parameterizable types like eDecimal(5,2). This will requie the new expression to change, since the arguments to constructors will now be on the type.
  3. Refactor the isNullable flag to be on fields, function returns and array elements, instead of being on the type.
  4. Remove old keywords, such as FIELD and SQLNULLABLE from function parms


Annotation changes

To make the EGL code more consitant and readable, EDT will require all references to annotations to be preceded by a @. Previously, for annotations with a single value, we allowed the annotation to be specified without using the @. For example, consider the following annotation:

Record stuff type Annotation {targets = [fieldMember]}

    value boolean = false;

end


In RBD we allowed the following for this annotation:       myfield record1 {stuff = true}

However, this is confusing, since there is no indication if "stuff" is an annotation or a field in the record Record1.

To alleviate this, EDT will require that the user explicitly indicate all annotations. Therfore, the user will need to code the following to specify the annotation: 

    myfield record1 {@stuff{value = true}};

or

   myField record1 {@stuff{true}};

Compiler updates

The following changes are made to the compiler:

  1. Package name is now represented as a string (for example "pkg1,pkg2") instead of a string[]. This is so that we are not tied to object identity of the string[] and allow us to easily change to a case sensitive package name.
  2. All references to string interning should be removed. Instead, we will go through a common class to convert strings (for now, this means just lowercasing the string).
  3. There will be new binders/binding completors for AnnotationType and StereotypeType. This is because these are not represented as records in the IRs.


Validation Design

TBD


Serialization Design

TBD

Back to the top