Double Declaration Warning [Crosstesting]

[jvf]

Example Stack Trace:

main] WARN swp_compiler_ss13.javabite.ast.nodes.marynary.BlockNodeJb - declaration already inserted ... should be catched by the semantic analysis later. dec: DeclarationNodeJb{type=LongType, id=i}

java.lang.AssertionError: Unexpected warnings after successfull compilation.
 Expected ReportLog entries: [DOUBLE_DECLARATION]. Actual: []: array lengths differed, expected.length=1 actual.length=0
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.internal.ComparisonCriteria.assertArraysAreSameLength(ComparisonCriteria.java:71)
    at org.junit.internal.ComparisonCriteria.arrayEquals(ComparisonCriteria.java:32)
    at org.junit.Assert.internalArrayEquals(Assert.java:473)
    at org.junit.Assert.assertArrayEquals(Assert.java:265)
    at swp_compiler_ss13.crosstest.AbstractCrosstest.test(AbstractCrosstest.java:94)

Affected Tests:

• DoubleDeclarationProgTest

[Tkrauss]

Is fixed (dev)... probably. Don't know, why the message appeared in the reportLogger, actually the regular javabite internal logger has been called... .

[jvf]

5a1e0f42a doesn't seem to fix the problem.

[flofreud]

FUC: Parser recognize double-declaration and set the error. Javabite: Semantical Analysis recognize double-declaration and set the error.

Combined: Javabite-Parser + FUC-Semantical Analyser -> no one recognize the double-declaration

What is the correct and discussed version @leinge, @ and @Tkrauss ?

[leinge]

Hum, right! I don't think this has been discussed yet. It depends on where the SymbolTable is filled. What do you say?

[Tkrauss]

Hum hum hum... I think, this should be Covered by the sa. With this decision, the parser Deals with syntactically correctness and the sa with semantics. Imho, this is the best Way to go, isn't it?

Am 09.07.2013 um 23:33 schrieb leinge notifications@github.com:

Hum, right! I don't think this has been discussed yet. It depends on where the SymbolTable is filled. What do you say?

— Reply to this email directly or view it on GitHub.

[swpcom-heydu]

If the parser should only handle context-free grammer, the sa would be the correct place for it. But I guess it is a lot easy in the parser, as it fills the symbol table and that just needs to give this error.

[Tkrauss]

As you already said, the parser works independent of its context. The context may be the current block. Therefore, it cannot decide wether it is a double declaration under special circumstances. I recognized this weak spec. of the symbol table in the parser recently, i think the most general approach is:

• The symbol table resulting from the parser delivers the most recent declaration type of each id
• The sa can use dedicated symbol tables ( as we do), but if a double decl. error occurs, an error has to be reported.

[jvf]

What is the status? Who is going to fix this? Are we getting a fix until tomorrow?

[Tkrauss]

I didn't change my mind, i think the context-sensitive errors may not be thrown by the parser. It shouldn't be very complicate to change that in the fuc-implementation, is it? I'm reluctant to implement such a context-sensitive behavior in the parser.

[leinge]

You're right Till! We simply haven't had much time today; that's the only reason for the delay. I'm currently working on it..

[jvf]

fixed