| Summary: | [OCLinEcore] Loading Ecore.ecore takes forever | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.1.0 | ||
| Target Milestone: | M7 | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Bug Depends on: | 363894 | ||
| Bug Blocks: | |||
|
Description
Ed Willink
There appear to be at least three problems The CS 2 Pivot conversion cannot handle the type Wildcard in "attribute instanceClass : EJavaClass<?>[?]" giving an IAE. The subsequent CS analysis shows numerous proxy errors since the CS 2 PIvot conversion was aborted. These proxy errors then causes the serialization to barf. (In reply to comment #0) > b) find out why no JUnit test detects this. Because there is no LoadTests for Ecore.ecore. (In reply to comment #0) > a) file an Xtext bug with a repro. Bug 363894. (In reply to comment #1) > There appear to be at least three problems > > The CS 2 Pivot conversion cannot handle the type Wildcard in "attribute > instanceClass : EJavaClass<?>[?]" giving an IAE. The order of processing when opening a *.ecore for text edit is. a) Ecore to Pivot b) Pivot to CS c) CS to text d) text to CS the serializer locks up in c). the wildcard parsing difficulties are in d) and so are not relevant to the serializer problem. (In reply to comment #3) > the wildcard parsing difficulties are in d) and so are not relevant to the > serializer problem. If instrumentation is added with a toString() the wildcard problem shows up in a). There is a TemplateBindingCS with a null pivot. Xtext serializer problem fixed. NPE while debugging avoided. Premature conversion of exceptions in CS2Pivot fixed. Tests work. CLOSED after a year in the RESOLVED state. |