search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[editor] Spurious error markers #2013

Open eclipse-ocl-bot opened 2 hours ago

eclipse-ocl-bot commented 2 hours ago

| --- | --- | | Bugzilla Link | 541380 | | Status | NEW | | Importance | P3 normal | | Reported | Nov 20, 2018 11:52 EDT | | Modified | Mar 16, 2022 05:43 EDT | | Depends on | 579025 | | See also | 579037, 551822 | | Reporter | Ed Willink |

Description

When editing the old Pivot.ocl to simplify obsolete constructs such as

context IteratorExp\ inv AnyHasOneIterator: ...

context IteratorExp\ inv AnyTypeIsSourceElementType: ...

context IteratorExp\ inv AnyBodyTypeIsBoolean: ...

context IteratorExp\ inv ClosureHasOneIterator: ...

to

context IteratorExp\ inv AnyHasOneIterator: true -- FIXME obsolete\ inv AnyTypeIsSourceElementType: true -- FIXME obsolete\ inv AnyBodyTypeIsBoolean: true -- FIXME obsolete\ inv ClosureHasOneIterator: true -- FIXME obsolete

the editor goes stale with numerous errors that require an editor restart.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Feb 28, 2022 10:16

Time to fix this.

Another repro on 6.17.1RC1 (and Xtext 2.26).

Edit /org.eclipse.ocl.pivot/model/OCL-2.5.oclstdlib, at line 176:

type Boolean : PrimitiveType conformsTo OclAny {

Select "Primitive", overtype with "Boolean".

After "B" no errors appear.

After "o" many errors appear.

After Ctrl-Z-ing twice back to the start, one error persists.

Presumably the CS2AS analysis is not using the 'same' Resource as the Node2CS.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Feb 28, 2022 10:26

(In reply to Ed Willink from comment #1)

Another repro on 6.17.1RC1 (and Xtext 2.26).

Repro works the same in nested Eclipse.

After Ctrl-Z-ing twice back to the start, one error persists.

Multiple markers at this line

Edits elsewhere are much better behaved.

Presumably the repro trashes the Boolean type causing the many errors, but they should unwind.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Feb 28, 2022 12:06

A simpler repro is just cut " PrimitiveType" and then Ctrl-Z.

The problem is that the Boolean PrimitiveTypeImpl is re-classed as a ClassImpl but not fully deleted so that when re-classed back again an orphan is re-used.

This seems like an obscure scenario that will be trashed by the eliminaton of CompleteClasses, but it's a solid repro, so worth some investigation ...

JVisualVM shows that one residual reference is via the lussids.

oops. The LUSSIDs provide the URO that Xtext's EObjectDescriptor uses, so LUSSIDs are from a one-short - need incremental update.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Mar 01, 2022 08:21

(In reply to Ed Willink from comment #3)

oops. The LUSSIDs provide the URO that Xtext's EObjectDescriptor uses, so LUSSIDs are from a one-short - need incremental update.

Leakage / update moved to Bug 579025.

If we disable LUSSIDs we can get to the next leakage.

The stale Boolean is used by the signatures of the LambdaTypeManager.

Creating a testEdit_Paste_OCLstdlib_541380 that trims " : PrimitiveType" from minimla.oclstdlib fails since the non-PrimitiveType Boolean provokes a CEE and an InvalidLibraryException - unfortunately too deep to be handled well.

Perhaps this particular edit is just too hard / stupid.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Mar 01, 2022 09:49

(In reply to Ed Willink from comment #4)

Perhaps this particular edit is just too hard / stupid.

The state that fails to comply with minimal.oclsdlib may indeed be too hard, Bug 579037 advocates making it impossible.

But the paste that restores a sensible state really should clean up.

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Mar 02, 2022 02:41

(In reply to Ed Willink from comment #5)

But the paste that restores a sensible state really should clean up.

This is really bad. Once eager LUSSID creation is deferred to save, in testValidate_Validate_completeocl we get

throw new IllegalStateException(formatMutationMessage(notification));

as ImmutabilityCheckingAdapter.notifyChanged for a not-saveable Validate.ecore.oclas resource processes a REMOVE from a refresh ownedPackages list.

Perhaps not quite so bad. ImmutabilityCheckingAdapter is a debug aid verifying that not-saveable ASResources do not chnage. Suppressing the the LUSSID creation meabs that an Ecore2AS refresh recreates and so updatres everything rather than nothing. The ISE just demonstrates that the debug aid is not very clever for REMOVE that never happen. The ImmutabilityCheckingAdapter is only in use when the resource/checkImmutability .option is set so nt a problem for users. resource/checkImmutability is set for all JUnit tests where the JUnit pane verdict does shows the ISE quite reasonably:

An exception occurred while delegating evaluation of the 'L3' constraint on 'Level3 yy': java.lang.IllegalStateException: 'file:/E:/Development/Chital/Workspace/_OCL_ValidateTests__testValidate_Validate_completeocl/Validate.ecore.oclas' modified at a 'Model.ownedPackages'

Bug 551822 advocates a cleanup of ExpressionInOCL/LanguageExpression which should remove the ImmutabilityCheckingAdapter irregularities.

Bottom line: LUSSIDs must be refreshed during editing.

Add a post CS2AS / ES2AS update check that LUSSIDs have been re-assigned.

Further LUSSID comments on Bug 579025

eclipse-ocl-bot commented 2 hours ago

By Ed Willink on Mar 16, 2022 05:43

(In reply to Ed Willink from comment #3)

so worth some investigation ...

The parsing of metatypes occurs early to ensure that the correct type is created. The associated error / flaback handling is very poor so that problems are left to occur obscurely downstream.

Diagnosing a bad metattpe and things are better. This also detects that Metaclass(T) was not eliminated from all test files.