Community
Participate
Working Groups
Build Identifier: 201109282102 Type mismatch: cannot convert from Calendar to EAny Reproducible: Always Steps to Reproduce: 1. Check out project "org.eclipse.edt.eunit.test" from kan-cvs. 2. Add java generator to the project. 3. Clean the whole workspace. 4. The issue exists in: fvt.operators.TestConcatOperatorsLib
Here's a simple testcase that shows the problem. nDate date? = "06/06/1944"; a any = nDate; The second line has the error. It's generated as a = (Calendar) org.eclipse.edt.javart.util.JavartUtil.checkNullable(EDate.ezeBox(nDate)); One solution would be to box the result of checkNullable, like this a = EDate.ezeBox(org.eclipse.edt.javart.util.JavartUtil.checkNullable(nDate));
The checkNullable method isn't really the problem. The problem is the runtime is missing a method call.
Some type of conversion needs to be done for sure, however a huge amount of this testcase is nonsense. There are many attempts to use :: to concatenate things like ints. There is no such function for this and causes the testcase to blow up when trying to generate. There should be many validation errors here.
fixed
I'm reopening this because it *IS* valid to concatenate things like ints with the :: operator. The :: operator is defined in EString to take two string operands. Thanks to EString.asString(EInt), ints can be converted to strings, so ints are valid operands for concatenation. Also, if we ever find a case where there should've been validation errors, someone should make sure a defect exists report the validation problem. Sometimes we can do this by changing the component to Compiler, or we can open a new defect.
Resolving this again because Tim has decided that EDT's :: operator won't be like the one in RBD. The thing on the left of :: should be a string.
Verified in build 201110110900
I read the conclusion of this year-old bug yesterday, and realized that we never implemented the validation rule mentioned in comment 6. It says the thing on the left of :: must be a string. I discussed it with Paul and Tim, we decided NOT to add that new rule. We'll continue to allow the left side of :: to be anything that's compatible with string, or a list. I'm going to try the testcase in 0.8.2, and I'll open a new bug if I find a problem.
