The Removal of Recoder #3120
The Removal of Recoder #3120
Conversation
|
@jwiesler Sources of key-javaparser are now available via maven. |
|
About Edit: Took a look around and I didn't find any usages outside of the XX2KeY-converters. |
jwiesler
force-pushed
the
weigl/key-javaparser3
branch
from
e9e9885 to
b2bd6c5
Compare
|
contraposition loads again. Syntax changes to |
|
@wadoon tests are not able to resolve Edit: This seems to be the issue everywhere. I'm not sure how to fix this or continue with this error. |
Is this the error message of This is not caused by unresolving And this is correct as |
|
Nope, what I meant is this one (thrown by most tests): However, I did see the one you mentioned and thought it would be the same error. |
|
I am stuck at the circular problem:
During the pre-transformation in (2), we resolve Options:
|
Could you point me to one test case? |
|
E.g. But you're right the remaining tests have the problem with |
|
We have an error in the pre-transformation pipeline. Complete: package java.lang;
public class ArithmeticException extends java.lang.RuntimeException {
public ArithmeticException() {
super();
}
public ArithmeticException(java.lang.String arg0) {
super(arg0);
}
@javax.annotation.processing.Generated()
static private boolean $classInitializationInProgress;
@javax.annotation.processing.Generated()
static private boolean $classErroneous;
@javax.annotation.processing.Generated()
static private boolean $classInitialized;
@javax.annotation.processing.Generated()
static private boolean $classPrepared;
static private void $clprepare() {
}
static public void $clinit() {
if (!@($classInitialized)) {
if (!@($classInitializationInProgress)) {
if (!@(this.$classPrepared)) {
//Created by ClassInitializeMethodBuilder.java:213
@($clprepare());
}
if (@($classErroneous)) {
throw new java.lang.NoClassDefFoundError();
}
//Created by ClassInitializeMethodBuilder.java:237
@($classInitializationInProgress) = true;
try {
@(java.lang.RuntimeException.$clinit());
{
super();
}
{
super(arg0);
}
}//Created by ClassInitializeMethodBuilder.java:188
catch (java.lang.Error err) {
//Created by ClassInitializeMethodBuilder.java:148
@($classInitializationInProgress) = true;
//Created by ClassInitializeMethodBuilder.java:149
@($classErroneous) = true;
throw err;
} catch (java.lang.Throwable twa) {
//Created by ClassInitializeMethodBuilder.java:148
@($classInitializationInProgress) = true;
//Created by ClassInitializeMethodBuilder.java:149
@($classErroneous) = true;
throw new java.lang.ExceptionInInitializerError(twa);
}
//Created by ClassInitializeMethodBuilder.java:243
@($classInitializationInProgress) = false;
//Created by ClassInitializeMethodBuilder.java:245
@($classErroneous) = false;
//Created by ClassInitializeMethodBuilder.java:247
@($classInitialized) = true;
}
}
}
protected void $prepare() {
}
private void $prepareEnter() {
}
public ArithmeticException $create() {
//Created by CreateBuilder.java:53
this.$initialized = false;
$prepareEnter();
return this;
}
public static ArithmeticException $createObject() {
ArithmeticException __NEW__;
//Created by CreateObjectBuilder.java:67
__NEW__ = ArithmeticException.$allocate();
__NEW__.$create()@ArithmeticException
return __NEW__;
}
} |
|
@wadoon fixed it. New issues are:
|
This may arise by two things: (1) I believe that the SchemaJavaParser has not used Recoder2KeY mapping, (2) there might be differences in |
Test case fails, as it is expected that Unknown if this is really required. |
There are some simple checks inside JavaParser, look into Case fixed with parenthesis. |
RAP:
|
…MethodBodyStatement's result var lookup
Method expand was used for instance creation instead of the taclet. Reason was that allocate had a non-null body (also it was empty)
…ot just its normalform)
In particular: - source code order of initializers respected - correct appending of initializer expressions to normalform body - fixes for recognizing implicit elements
|
…t at the moment the settings are ignored
This makes at least reverseArray2.key to be provable again.
- Fixes test strassen.key
|
Very curious behavior of switch_in_switch.key: When proven in the UI, at some point a label is removed (correctly) via The automatic tests save a proof without this rule app, creating an unloadable proof. |
RAP javadl Tests`testlocalDeclaredMethod`: Model Element not known:(type, sort): (B,B))`testfor_ReferenceArray`, `testvararg`, `testfor_Iterable`, `testfor_Array`: EnumDeclaration not supported`testclasspath`, `testexceptions3`, `testexceptions`: Unsolved Symbol`testobjectOfErroneousClass`: AssertionErrorFails w/o throwing exception
|
This PR replaces recoder by javaparser, or more precisely by key-javaparser.
The special version has support for
ProofJava,SchemaJavaand Java 17+, all in one grammar.Notes on the grammar can be found in the key-docs
This MR requires a complete overhaul of the KeY-Infrastructure.
Status:
JavaInfofor unused methods and delete themTestProofJavaParserandTestSchemaJavaParser?TestKeYRecoderMapping