Odd compiler errors with SDK 7.4.1

Can you post a minimal project that reproduces this, along with your compiler options, OS, and jvm distro/version?

I'm not able to recreate the same problem that you're seeing with for loops.

I just wanted to +1 this. 

I'm getting tons of errors with 7.4.1 in code that used to compile without errors in 7.3 them.

They're mostly similar to OP:

• Trying to access an uninitialized variable.
• Invalid 'Uninitialized' passed as parameter 1 of type '$.Toybox.Graphics.Dc'.
• Cannot assign value 'Uninitialized' to member ':lastPaintTimestampMoment'.

While I'm not able right now to create some kind of minimal project to repro it, this is occurring in code like this function. It's saying certain function arguments aren't initialized.

public function onUpdateInternal(dc as Graphics.Dc, paintFace as Lang.Method){
    if(!hasLayout){
        //This is where the error occurs, saying dc is not initialized
        appState.watchFaceView.onLayout(dc);
    }
    //Other code continues here...
}

myaro said:

While I'm not able right now to create some kind of minimal project to repro it, this is occurring in code like this function. It's saying certain function arguments aren't initialized.

Oh, thank goodness! I just spent the last hour or so myself trying to create a minimal project but there seems to be no rhyme or reason to it. 

I just logged this bug. 
https://forums.garmin.com/developer/connect-iq/i/bug-reports/7-4-1-compiler-fails-it-claims-function-arguments-are-not-initialized

I hope we get a quick response on this, since this seems like it'll have a wide impact.  Kyle.ConnectIQ for visibility, since you were so quick to provide updates on the original 7.4.0 release.

Thanks for the heads up. We're taking a look.

I managed to get the for-loop to not error by eliminating the break; element within the if condition within the loop (I've updated my example in my original post). My other error has no such element, so it really does seem to no consistent reason in terms of causality.

As these things typically go, we can't reproduce this after trying quite a few different ways. myaro and dbrobert, are either of you willing to send us a log file to [email protected]? Verbose logging would be best, but we can try with intermediate.

To get the logs, add "-=debug-log-level [0-3] --debug-log-output <output file>" when building.

I can do that. Though, it might be helpful if we both do it? I'm not sure what is exposed on intermediate (or verbose to be honest). Can you explain further? To be more specific, I'm looking for more info on this statement: "Be aware that the log levels include increasingly more information about your source project. If you want to keep your project information private, limit the logging level to 1 or less. More verbosity will make it easier for Garmin to debug any issues."

The experts are out for the day. I don't want to misrepresent what is being sent so let me confirm with them before responding.

Kyle.ConnectIQ thanks for the fast response.

I'll look into sending logs over again.  I did this back when the simulator was crashing on me, but nobody ever replied.  Does it still help?

In the meantime, you can let the team know that it seems to have something to do with conditionals without matching else statements.  From the places I've seen problems, it is in places with conditional logic.

Here's how I was able to experiment to get one of the errors silenced.  But it's become whack-a-mole across my substantial codebase, and not all of them are yielding to refactors like this.

// THIS RESULTED IN AN ERROR
function getDateCountdown(arg1 as SomeType, arg2 as Lang.Dictionary) as SomeOtherType {
	if(someConditionalStatement){
		// Do something			
		return someValue;
	}
	// This results in an error, saying arg1 is Uninitialized
	return someFunctionCall(arg1);
}

// THIS SUBTLE CHANGE MADE THE ERROR GO AWAY
function getDateCountdown(arg1 as SomeType, arg2 as Lang.Dictionary) as SomeOtherType {
	if(someConditionalStatement){
		// Do something	
		return someValue;		
	}
	else{
		// The compiler is okay with this
		return someFunctionCall(arg1);
	}
}

I have a feeling it's a regression caused by this item in the Compiler Changes section of the release notes:

• Improve the unreachable code error with if statements.