Community
Participate
Working Groups
In 'type library' projects in eclipse, VJET reports type mismatch. In jQueryTL(existing type library), error details are:- "Type mismatch: cannot convert from Object to type::jQuery" jQuery.js /JQueryTL/src/org/jquery line 4 VJET Problem
Thanks Atul for the bug. I believe this may be a problem with undefined right hand expression not being bound to the Undefined type. We allow conversion from Undefined to any concrete type but we flag errors when converting from Object to more specific type. It is good to create a reduced test js file with minimum amount of properties/methods/types to reproduce the error. Can this be reproduced with just the outer vjo type and no properties? vjo.ctype('bugs.Bug402629') //< public .globals({ $: undefined //< type::bugs.Bug402629 }) .endType(); In this case the error checker should allow Undefined to be converted to type::bugs.Bug402629. We will work on some documentation in this release with conversion rules.
Justin, Thanks for the bit of explanation on probable cause, sounds logical to flag mismatch when converting Object to more specific type. Just wondering how, but the error now has changed to "Cannot convert from Undefined to type::jQuery", in place of 'Object' there is 'Undefined' now, so it seems right hand undefined is bound to the Undefined type but mismatch is still reported. Can't figure out how the error changed though. Yes, the error can be reproduced from the minimal js, going to add as an attachment.
Created attachment 228088 [details] Can be reproduced with this js
Once you have the minimal code you need to create the error as I mentioned in previous comment. Then you can start the VJET debug workspace. Place a future break point in this class's constructor. All validation warnings and errors go through this choke point. This is before the markers are created in Eclipse level that is a secondary place to check as well if the marker is not produced by VJET validation engine. org.eclipse.vjet.dsf.jsgen.shared.jstvalidator.DefaultJstProblem Once you have verified that the error is coming from VJET validator engine. We can go from there. I suggest looking up the call stack. In this case the stack looks like this: VjoSemanticProblem(DefaultJstProblem).<init>(String[], JstProblemId, String, char[], int, int, int, int, ProblemSeverity) line: 28 VjoSemanticProblem.<init>(String[], JstProblemId, String, char[], int, int, int, int, ProblemSeverity) line: 44 VjoSemanticProblemFactory.createProblem(String[], String, JstProblemId, String, IJstNode, VjoSemanticRule<?>) line: 37 AssignableRule.doFire(BaseVjoSemanticRuleCtx) line: 19 AssignableRule.doFire(IVjoSemanticRuleCtx) line: 1 AssignableRule(VjoSemanticRule<T>).fire(T) line: 115 VjoJstPropertyValidator(VjoSemanticValidator).satisfyRule(VjoValidationCtx, IVjoSemanticRule<Ctx>, Ctx) line: 259 VjoJstPropertyValidator.validatePropertyExpr(VjoValidationCtx, IJstProperty, IExpr) line: 192 VjoJstPropertyValidator.onPostAllChildrenEvent(IVjoValidationVisitorEvent) line: 147 VjoJstPropertyValidator(VjoSemanticValidator).onEvent(IVjoValidationVisitorEvent) line: 307 VjoSemanticValidatorRepo.dispatch(IVjoValidationVisitorEvent) line: 514 VjoValidationVisitor.visitAndValidate(IJstNode, boolean, boolean) line: 289 VjoValidationVisitor.visitAndValidate(IJstNode) line: 247 VjoValidationVisitor.visit(JstProperty) line: 414 JstProperty.accept(IJstNodeVisitor) line: 358 JstGlobalProp.accept(IJstNodeVisitor) line: 114 VjoValidationVisitor.visitChild(IJstNode) line: 312 VjoValidationVisitor.visitAndValidate(IJstNode, boolean, boolean) line: 277 VjoValidationVisitor.visitAndValidate(IJstNode) line: 247 VjoValidationVisitor.visit(JstGlobalVar) line: 678 JstGlobalVar.accept(IJstNodeVisitor) line: 73 VjoValidationVisitor.visitChild(IJstNode) line: 312 VjoValidationVisitor.visitAndValidate(IJstNode, boolean, boolean) line: 277 VjoValidationVisitor.visitAndValidate(IJstNode) line: 247 VjoValidationVisitor.visit(JstType) line: 431 JstType.accept(IJstNodeVisitor) line: 2710 VjoValidationDriver.walkThrough(IJstType, List<IJstNode>, List<IScriptProblem>, VjoValidationCtx, String, String, VjoValidationMode) line: 269 VjoValidationDriver.validateComplete(List<IJstType>, String, VjoValidationMode) line: 190 BasicValidator.doValidate(IJstType) line: 65 BasicValidator(AbstractValidator).validate(IJstType) line: 35 ValidationEntry.validator(IJstType) line: 53 VjoSourceParser.parse(char[], char[], IProblemReporter, VjetSourceModuleBuildCtx) line: 156 VjoSourceParser.parse(char[], char[], IProblemReporter) line: 196 ParserBuildParticipantFactory$ParserBuildParticipant.build(IBuildContext) line: 83 StructureBuilder.build(String, ISourceModule, AccumulatingProblemReporter) line: 89 VjoSourceModule.doBuild(OpenableElementInfo, IProgressMonitor, Map, IResource) line: 175 VjoSourceModule.access$1(VjoSourceModule, OpenableElementInfo, IProgressMonitor, Map, IResource) line: 132 VjoSourceModule$SourceStructureBuilder.run() line: 89 TypeSpaceMgr.run(ITypeSpaceRunnable) line: 792 VjoSourceModule.buildStructure(OpenableElementInfo, IProgressMonitor, Map, IResource) line: 127 VjoSourceModule(Openable).generateInfos(Object, HashMap, IProgressMonitor) line: 181 VjoSourceModule(ModelElement).openWhenClosed(Object, IProgressMonitor) line: 172 VjoSourceModule.openWhenClosed(Object, IProgressMonitor) line: 112 VjoSourceModule(SourceModule).makeConsistent(IProgressMonitor) line: 286 ReconcileWorkingCopyOperation.makeConsistent(SourceModule, IProblemRequestor) line: 76 ReconcileWorkingCopyOperation.executeOperation() line: 55 ReconcileWorkingCopyOperation(ModelOperation).run(IProgressMonitor) line: 698 ReconcileWorkingCopyOperation(ModelOperation).runOperation(IProgressMonitor) line: 763 VjoSourceModule(SourceModule).reconcile(boolean, WorkingCopyOwner, IProgressMonitor) line: 337 ScriptReconcilingStrategy.reconcile(ISourceModule, boolean) line: 117 ScriptReconcilingStrategy.access$0(ScriptReconcilingStrategy, ISourceModule, boolean) line: 106 ScriptReconcilingStrategy$1.run() line: 81 SafeRunner.run(ISafeRunnable) line: 42 ScriptReconcilingStrategy.reconcile(boolean) line: 79 ScriptReconcilingStrategy.reconcile(IRegion) line: 145 ScriptCompositeReconcilingStrategy(CompositeReconcilingStrategy).reconcile(IRegion) line: 97 ScriptCompositeReconcilingStrategy.reconcile(IRegion) line: 74 ScriptReconciler(MonoReconciler).process(DirtyRegion) line: 77 AbstractReconciler$BackgroundThread.run() line: 206 We need to look into the VjoJstPropertyValidator.validatePropertyExpr(VjoValidationCtx, IJstProperty, IExpr) line: 192 I actually found the error under org.eclipse.vjet.dsf.jsgen.shared.validation.vjo.semantic.rules.util.TypeCheckUtil.isAssignable When we convert from Undefined to type::T vs if we convert from Undefined to T there was a bug in this code. I only get an error on the type::T conversion. See this second example: vjo.ctype('bugs.bug402629') //< public .globals({ $: undefined //< type::bugs.bug402629 $2: undefined //< bugs.bug402629 }) .endType(); type:: is represented in the code base by JstTypeRefType - Jst TypeRef or type::T Not to be confused with a JstTypeReference (this is just a reference to a type) any IJstType can be a JstTypeReference. If you open the ScriptUnit viewer you can see the JstModel (I have attached screenshot) this is a great way to navigate the model.
Created attachment 228094 [details] script unit + property + vjet editor views for this bug
I have also done some additional reducing of the problem var a = undefined //< type::Date var b = undefined //< type::Window This is also a problem. I just tried using the EcmaScript Date data type and W3c Window data type rather than a user defined data type and yes those cause same issue. When I look at the TypeCheckUtil line 557 I see the problem Undefined type is not of type IJstRefType (the interface that JstTypeRefType implements) When I apply this fix to the condition at line 557 I see that this problem goes away which is fair since we allow conversion from Undefined to T now we can allow Undefined to type::T. if (!(assignFrom instanceof IJstRefType) && !isUndefined(assignFrom)) { return false; }
Applied patch.. you can try it out and confirm that this fixed the bug please. http://git.eclipse.org/c/vjet/org.eclipse.vjet.core.git/commit/?id=935571f3f385806d64b45c69ffbf39afe1520c09&ss=1
We have one more step we need to add test cases for the assignment / conversion code. Where valid conversions are ok and what are not ok and should flag error. I will document those created separate bug for that bug402683
Indeed the patch fixes the bug :), Undefined can now be converted to JstTypeRefType. Thanks for debugging details, will try to learn more about vjo implementation. Yes, creating and organizing docs would be great, they seem to be dispersed right now.
