Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler: Type checks not performed on super calls #3513

Open
Adolio opened this issue Oct 10, 2024 · 4 comments
Open

Compiler: Type checks not performed on super calls #3513

Adolio opened this issue Oct 10, 2024 · 4 comments
Labels

Comments

@Adolio
Copy link

Adolio commented Oct 10, 2024

Having this would prevent runtime errors by detecting issues at compile time.


This issue was initially reported in BowlerHatLLC/vscode-as3mxml#770

Comment from @joshtynjala:

Interestingly, the ASC 2.0 compiler in the AIR SDK doesn't seem to perform type checks on super calls either. That's a bug that Harman should fix too. The Flex SDK compiler checks all super class properly, though.


Please consider adding those type checks in a future version of the SDK.

Thanks

@joshtynjala
Copy link

I'll just add the code examples from the vscode-as3mxml issue, so that the AIR SDK devs have more context without following the link to that issue.

In this example, there should be a compile-time error because 42 is not a valid value for the Point type:

import flash.geom.Point;

class A
{
	public function A(point:Point)
	{

	}
}

class B extends A
{
	public function B()
	{
		super(42);
	}
}

And this example should have a similar compile-time error:

override public function a(point:Point):void {
	super.a(42);
}

In the case of the AIR SDK compiler, I didn't specifically test whether other related checks are performed, but I'm guessing that they'll be missing similar to the Royale compiler, since they are related codebases. For example, it should also check that the number of arguments passed to the super method is correct. The Royale compiler didn't check that either.

@ajwfrost
Copy link
Collaborator

Thanks Josh! Although too late, I'd already followed the link :-)
Presumably this has been an issue from the start!

The linked issue is on the vscode-as3mxml project - I assume that's not actually the component at fault, and the fixes would need to come from us and from the Apache royale-compiler project?

@joshtynjala
Copy link

the fixes would need to come from us and from the Apache royale-compiler project?

Correct.

For royale-compiler, I've already implemented the necessary fixes in a branch. We have a release in progress, so they'll go into the next version. The commits with fixes, if you're interested, are linked below:

apache/royale-compiler@f0444c6
apache/royale-compiler@1b6a222

@joshtynjala
Copy link

I should also mention that making this change may introduce new compiler errors in existing AS3 code that previously compiled without errors. Users may need some guidance. In most cases, they just need to add a cast to convert to the correct type. In some cases, it may actually be a bug in their code that was previously undiscovered. I think that undiscovered bugs are a bit less common with the AIR SDK than with Royale because AIR has the verifier performing extra runtime checks that are more likely to catch issues and throw runtime exceptions for them. Royale runs in JS, which is untyped and more lenient, so Royale apps can pass bad types further away from their source, and are more likely to appear to be working correctly.

Starling, Feathers, and other high-visibility projects shouldn't be affected because they're commonly compiled with both the AIR SDK and Flex SDK compilers, and the Flex SDK compiler doesn't have this bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants