j-brant / smacc Goto Github PK

I forgot if there ever was one, but is SmaCC not supposed to be MIT?

The TypeScript parser does not support the export modifier for classes

example:

import {
    Component,
    OnDestroy,
    OnInit
} from '@angular/core';

@Component({
    templateUrl: './myComponent.component.html'
})
export class MyComponent extends OtherClass {

}

I was about to get my hands on migrating the debugger to Pharo 10.
I happily discovered that you already did it!
Still, I wondered about the code to check if everything was working fine, and I learned that the parsing debugger does not work with non-GLR parsers.
As a workaround, I implement two methods at #SmaCCParser
#SmaCCParser>>states
^ stateStack.

#SmaCCParser>>currentState
^ currentToken.

It seems to be enough. If you are interested, I can make a pull request with that. I would like any what you think about these changes.

Hello,

I'd like to use SmaCC for Java and with the source code. But, SmaCC_Source_Editing package is not present in any group (except "all").

Is it possible to have it alone in a group so I can configure my baseline to use both Java and SmaCC_Source_Editing?

(I can do a PR if you want)

Thanks!

Hello, it is impossible to parse default method in Java inteface.

For example, it is possible de parse

interface TestInterface1 
{ 
    // default method 
    default void show() 
    { 
        System.out.println("Default TestInterface1"); 
    } 
} 

But not

interface TestInterface1 
{ 
    // default method 
    public default void show() 
    { 
        System.out.println("Default TestInterface1"); 
    } 
} 

In the second example, I had the 'public' modifier.
It is possible (see: https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html)
in section "Static Methods"

I thought the error is probably there

interface_method_declaration 
    : interface_method_header block 'body' {{MethodDeclaration}}
    ;    
interface_method_header 
    : interface_modifiers_opt type_parameters_opt 'typeParameters' type 'type' method_declarator 'declarator' throws_opt 'throws'
    | interface_modifiers_opt type_parameters_opt 'typeParameters' void 'type' method_declarator 'declarator' throws_opt 'throws'
    ;
interface_modifiers_opt
    : modifiers_opt
    | default_modifier 'modifier'
    ;
default_modifier 
    : "default" 'token' {{Modifier}}

But I need help to solve it

If someone has time?

Feature suggestion: writing a grammar rule in terms of tokens that have different definitions depending on the scanner state…

%states default insideBraces insideParens;

insideBraces <any> : [^{}]+ ;
insideBraces <leftDelimiter> : \{ ;
insideBraces <rightDelimiter> : \} ;

insideParens <any> : [^()]+ ;
insideParens <leftDelimiter> : \( ;
insideParens <rightDelimiter> : \) ;

# this rule would only be used when the scanner is in one of the two states above
DelimitedContent
    : <any> 'content' {{}}
    | <leftDelimiter> 'content'
        DelimitedContent 'content' *
        <rightDelimiter> 'content' {{}}
;

Hello (sorry it's again me 😬 ),

From the previous issue (#9), I've discovered that we cannot use the same startingState to parse a method in Java if the method is written in an Interface or in a Class

ex doesn't work:

JavaParser
		parse: '
public default void show() 
    { 
        System.out.println("Default TestInterface1"); 
    } 
 ' startingAt: JavaParser startingStateForclass_body_declaration.

I think I understand why the parser cannot do that (the grammar is different in an interface and in a class).

So, what do you think we should do in such a case?
Using parse:startingAt:onError?
And give to onError the block that will execute the parsing with another startingPoint?

If yes, I will propose a pull request to add interface_member_declaration as a startingPoint (or maybe we can specify a startingPoint without adding it at the begin of the "parser generator").
If no, I'm interesting about the solution 😃