#Warn giving incorrect warnings in AutoHotkey 1.1.33.00

[PeterCM]

DISCLAIMER: I'm a complete non-coder who is quite new to AutoHotkey and who has only used it for key remapping. I'm running Windows 10 Home 1909, fully up to date with the exception of the most recent Patch Tuesday (for which some users have reported a forced-reboot bug).

I have a laptop with no dedicated media keys, half-height arrow keys, and other navigation keys in a non-standard layout. I run four AutoHotkey scripts, mostly to remap and repurpose the un-numlocked numeric keypad in order to remedy those shortcomings.

My scripts were running fine until I updated from AHK 1.1.32.00 to 1.1.33.00.

After the update, the #Warn setting in my each of my scripts threw warnings for lines of code that are not present in any of my scripts -- specifically that code following a non-existent second or third return (typically equally non-existent Exits) -- would not be executed -- and the scripts wouldn't run.

I commented out the #Warn setting in each of my scripts (; #Warn) and now they run fine again.

Barring beginner's ignorance on my part, something seems to be wrong with how #Warn is working in 1.1.33.00.

[swagfag]

ure probably triggering the "unreachable code" check, which doesnt necessarily default to there being something wrong with ur script, but if u have no clue as to why the warning is getting triggered, more likely than not theres something wrong with ur code

in any case, the correct way to submit bug reports(unless referencing something blatantly obviously bugged) is to show what errors ure getting and the code that produces them

[Xtra]

To add to Swags post.

OP you should read the patch notes.

Unreachable [v1.1.33+]: Before the script starts to run, show a warning for each line that immediately follows a Return, Break, Continue, Throw, Goto or Exit at the same nesting level, unless that line is the target of a label. Although this does not detect all unreachable code, it detects common errors such as:

Placing initialization code (such as an assignment or GroupAdd) in between hotkey subroutines, when it should be in the auto-execute section.
Placing the first line of a "multi-line" hotkey subroutine on the same line as the hotkey label. Doing so will make it a single-line hotkey, with an implicit return that prevents any subsequent lines from executing. Similarly, placing return after a single-line hotkey is redundant and will cause a warning.
Placing a subroutine inside another subroutine, breaking the flow of code.
If the code is intended to be unreachable - such as if a return has been used to temporarily disable a block of code, or a hotkey or hotstring has been temporarily disabled by commenting it out - consider commenting out the unreachable code as well. Alternatively, the warning can be suppressed by defining a label above the first unreachable line.

[lexikos]

There is an implicit Exit at the end of the main script that prevents auto included libs from auto executing, for backward compatibility. If you have code in a lib which is unreachable due to this, you should get a warning. The Exit itself is permitted to be unreachable (e.g. if you explicitly end the script with return or exit), but still appears in messages for nearby errors/warnings.

There are also two implicit Exits at the very end of the script, which should never trigger a warning.

If you believe you are getting erroneous warnings, post code that reproduces the issue. All of my own tests were successful.

[lexikos]

A "non-existent" return might be the implicit return in a one-line hotkey.

if a hotkey needs to execute only a single line, that line can be listed to the right of the double-colon. In other words, the return is implicit:

Code: Select all

#n::Run Notepad

Source: Hotkeys - Definition & Usage | AutoHotkey

So as another test, I ran

Code: Select all

#Warn
xxx()
^1::MsgBox

with Lib\xxx.ahk being:

Code: Select all

xxx() {
}
unreachable := 1
unreachable := 2

and the result was, as expected,

Code: Select all

Warning in #include file "...\Lib\xxx.ahk":
     This line will never execute, due to Exit preceeding it.

	Line#
	002: xxx()  
	003: Return
	003: MsgBox
	003: Return
	004: Exit
	001: {
	002: }
--->	003: unreachable := 1
	004: unreachable := 2
	006: Exit
	006: Exit

For more details, read the documentation for #Warn.

If the two "unreachable :=" lines are removed, there are no unreachable lines, and therefore no warning.

The line numbers show which line generated the return.


Aside from one-line hotkeys, an implicit return is added for:

• The first hotkey in the auto-execute section. This return is permitted to be unreachable, since scripts often end the auto-execute section explicitly, but the return is still added. The line following this return is never unreachable, since it is the target of a hotkey label.

  Note: While the script's first hotkey/hotstring label has the same effect as return, other hotkeys and labels do not.
  Source: Scripts - Definition & Usage | AutoHotkey

• One-line hotstrings with the X option. If the hotstring's action is an explicit return, the implicit one will be unreachable; therefore it is permitted to be unreachable, and does not trigger a warning. The line following this return will trigger a warning if it is unreachable and not excluded.
• Auto-replace hotstrings. This implicit return is permitted to be unreachable. The line following it will trigger a warning if it is unreachable and not excluded.
  Spoiler

  (The source code indicates the original reason for adding it was "in case gosub/goto is ever used to jump to their labels", but auto-replace hotstrings don't define labels, so you would have to define a separate label above the hotstring. It also stop execution from flowing through the hotstring, which may be good or bad, but probably has to be kept this way in v1 for backward-compatibility.)

I understand that seeing a Return or Exit which is not physically written in the script may be confusing, but the warning is about some other line that will never be executed.

[PeterCM]

I greatly appreciate the time and care that went into these replies, but unfortunately, a lot of it is still above my head. I really am a complete non-coder with extremely little AHK experience, and spending several hours in AHK's documentation, as good as it is, hasn't fixed that. That said, I'm capable of learning in small increments when my mistakes are pointed out, so I'm posting my scripts and the warnings they threw, below. I hope there's nothing unforgivably stupid in my code ... but I wouldn't be surprised if there is. I manually typed out the warnings, since I couldn't copy the warning-box text, I don't know how to generate a log, and I don't know how to insert a screencap here. I tried to be careful, but if you come across something in the warnings that appears to be a typo, it probably is.

Again, I'm very grateful to all who replied.

SCRIPT # 1 (CustomVolumeKeys.ahk)

Code: Select all

#NoEnv
#Warn
SendMode Input
SetWorkingDir %A_ScriptDir%
SetTitleMatchMode, 2
; Custom Volume Keys
NumpadAdd::Volume_Up
NumpadSub::Volume_Down
NumpadEnter::Volume_Mute
return

CustomVolumeKeys.ahk

Warning: This line will never execute, due to Return preceding it.

Line#
008: Return
009: SetKeyDelay,-1
009: Send,{Blind}{Volume_Mute DownR}
009: Return
009: SetKeyDelay,-1
009: Send,{Blind}{Volume_Mute Up}
009: Return

---> 010: Return

011: Exit
012: Exit
012: Exit

For more details, read the documentation for #Warn.

SCRIPT # 2 (CustomPlaybackControls.ahk)

Code: Select all

#NoEnv
#Warn
SendMode Input
SetWorkingDir %A_ScriptDir%
SetTitleMatchMode, 2
; Custom Playback Controls
NumpadIns::Media_Play_Pause
NumpadDel::Media_Next
return

CustomPlaybackControls.ahk

Warning: This line will never execute, due to Return preceding it.

Line#
007: Return
008: SetKeyDelay,-1
008: Send,{Blind}{Media_Next DownR}
008: Return
008: SetKeyDelay,-1
008: Send,{Blind}{Media_Next Up}
008: Return

---> 009: Return

010: Exit
011: Exit
011: Exit

For more details, read the documentation for #Warn.

SCRIPT # 3 (CustomNumpadNavigation.ahk)

Code: Select all

#NoEnv
#Warn
SendMode Input
SetWorkingDir %A_ScriptDir%
SetTitleMatchMode, 2
; Custom Numpad Navigation
NumpadEnd::Left
NumpadPgDn::Right
NumpadLeft::End
NumpadClear::Up
NumpadRight::PgDn
return

CustomNumpadNavigation.ahk

Warning: This line will never execute, due to Return preceding it.

Line#
010: Return
011: SetKeyDelay,-1
011: Send,{Blind}{PgDn DownR}
011: Return
011: SetKeyDelay,-1
011: Send,{Blind}{PgDn Up}
011: Return

---> 012: Return

013: Exit
014: Exit
014: Exit

For more details, read the documentation for #Warn.

SCRIPT # 4 (CustomShortcuts.ahk)

Code: Select all

#NoEnv
#Warn
SendMode Input
SetWorkingDir %A_ScriptDir%
SetTitleMatchMode, 2
; Custom Shortcuts
#+i:: Run, control
return

CustomShortcuts.ahk

Warning: This line will never execute, due to Return preceding it.

Line#
003: SendMode,Input
004: SetWorkingDir,%A_ScriptDir%
005: SetTitleMatchMode,2
007: Return
007: Run,control
007: Return

---> 008: Return

009: Exit
010: Exit
010: Exit

For more details, read the documentation for #Warn.

[lexikos]

Script #1, #2 and #3: The warning is correct. The remapping is shorthand for two complete hotkey subroutines. There is no meaning in having a return after it.

Code: Select all

NumpadEnter::Volume_Mute
return ; ← remove this

Script #4: The warning is correct. One-line hotkeys have an implicit return, as I explained. There is no meaning in having a return after it.

Code: Select all

#+i:: Run, control
return ; ← remove this

Although a return does no harm here, its presence indicates a lack of understanding of control flow (or what the return statement does). I hope that pointing out these redundant lines will help users to understand more quickly. In other cases, the unreachable lines are important, such as variable assignments.

since I couldn't copy the warning-box text

If you press Ctrl+C (at least with English language), it will "ding" as though it is rejecting your keystroke, but it will also copy the dialog text. This is a standard feature of the system message box.

[kczx3]

I think one of the confusing things with the messages that show code and line numbers is that the code doesn't exactly reflect what the user wrote since it shows all statements "inserted" by the parser (or whatever). I think these types of warnings/errors would be much easier for the programmer to understand if it showed exactly the code that the user wrote at those points in the script.

[PeterCM]

@lexikos: Your corrections worked like a charm. I removed the returns and "uncommented out" the #Warns and my scripts all loaded without protest. I thought I'd read (at the very beginning of my dive into the documentation) that every script had to end with a return. Obviously, I misunderstood -- no surprise there.

I appreciate the lesson on AHK and on copying Windows message boxes, as well. I've been using Windows for a while (though not Windows 10), and that was a new and very useful tip to me. Thanks!

[lexikos]

@kczx3, the exact script text isn't retained in memory. What you see is produced by "decompiling" the structures that AutoHotkey uses during execution. (The text of each arg or expression is kept in memory due to the way the parser works, so those parts should look like the original.)

If it's re-read from file, we'd need to guard against changes to the script file while it is running. (Possibly just avoid showing code if the file has been modified.)

If we show the original text rather than the program's interpretation of it, references like "the preceding Return" will be even more confusing.

It may be feasible to show it as "automatic return" or similar.

[kczx3]

If it's re-read from file, we'd need to guard against changes to the script file while it is running. (Possibly just avoid showing code if the file has been modified.)

Isn't this also a concern when using a debugger?

I just think seeing the programmers own code would be less cryptic.

[joefiesta]

@PeterCm: I see this as you misinterpretting the placement of the RETURN statement that is usually used to mark the end of the auto-execute sectioin. This RETURN, however, is not required. Your auto-execute section is ended by your first HOTKEY definition. So, if you move your RETURN statment to above your first HOTKEY definition, the warnings will also not appear.

[lexikos]

@kczx3, the debugger client can account for this several different ways. For instance, lock editing, read all include files when debugging begins and keep them in memory (perhaps in the editor, read-only), or just warn the user if the file changes. What can the debugger engine do? Abort debugging, or not report line numbers? That would prevent the client from doing something more useful.

Similarly, the built in error messages could:

• Not show the line text in error dialogs if the file has been modified.
• Just show the wrong script text if the file has been modified.
• Fall back to "decompiling" if the script file has changed.
• Rely on the program retaining the script text in memory, increasing memory usage.
• Rely on the program keeping script files open while running, preventing them from being modified.

ListLines uses the same routine as the error dialog to generate line text, which saves it from having to keep the files in memory or read lines non-sequentially from the file. Reading a specific line generally means reading every line up to that point.

For ListLines, the "decompiled" code is more helpful when there are multiple actions on a single line, fat arrow functions, or similar.

[PeterCM]

@PeterCm: I see this as you misinterpreting the placement of the RETURN statement that is usually used to mark the end of the auto-execute section. . . .

Thanks, Joe. I will try to remember to learn about auto-execute sections and the function of return statements if I ever tackle more complex scripts.