You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unknown Source for errors caused by misuse auto, void #1230
Just to clarify, the compile errors are valid, only the source (Target) should be known here instead.
Regarding the note: It is indeed true that you can currently use classtypes in places where it might make no sense. Generally these get converted to the string representing the classtype (e.g. value int would convert to string ms.lang.int), unless the function really expects you to input a classtype there. So while a script with only a classtype in it doesn't make much sense, it's valid code.
This bug is caused by using singular cached CClassTypes with an unknown target. These are created here.
One possible fix is to not use cached CClassTypes when a target for them is known, but this breaks any ==CCLassType comparisons, which could cause annoying bugs.
Another solution is to cache some ClassType instead of CClassType, and use cached ClassTypes as non-Construct within CClassType instances. User code would keep containing CClassType instances, but all code that handles these would do checks using the actual ClassType they represent.
452cde8 I fixed at least one place this occurs by using the trailing data Target instead of the ClassType Target. It was more appropriate in that context anyway. ClassTypes having an unknown Target is still an issue, so this isn't "fixed". But in regards to the above errors, only the Expected classtype, but received type void instead. one is still exists.
Activity
Pieter12345 commentedon Jul 31, 2020
Just to clarify, the compile errors are valid, only the source (
Target) should be known here instead.Regarding the note: It is indeed true that you can currently use classtypes in places where it might make no sense. Generally these get converted to the string representing the classtype (e.g. value
intwould convert to stringms.lang.int), unless the function really expects you to input a classtype there. So while a script with only a classtype in it doesn't make much sense, it's valid code.Pieter12345 commentedon Aug 23, 2020
This bug is caused by using singular cached
CClassTypes with an unknown target. These are created here.One possible fix is to not use cached
CClassTypes when a target for them is known, but this breaks any==CCLassTypecomparisons, which could cause annoying bugs.Another solution is to cache some
ClassTypeinstead ofCClassType, and use cachedClassTypes as non-ConstructwithinCClassTypeinstances. User code would keep containingCClassTypeinstances, but all code that handles these would do checks using the actualClassTypethey represent.PseudoKnight commentedon May 31, 2021
452cde8 I fixed at least one place this occurs by using the trailing data Target instead of the ClassType Target. It was more appropriate in that context anyway. ClassTypes having an unknown Target is still an issue, so this isn't "fixed". But in regards to the above errors, only the
Expected classtype, but received type void instead.one is still exists.PseudoKnight commentedon Oct 26, 2023
2eae885 I fixed the other example and related issues with unknown targets on assignment.
Adding code targets for CClassTypes in scripts is still something that should be considered, but it's a more extensive change.