Pragmas in Xojo

The Xojo compiler knows a few pragmas, so let's today dive into them:

BackgroundTasks

This flag is valid only within a method and defines whether the Xojo compiler will insert RuntimeBackgroundTask() calls at loop boundaries. This call checks if some time passed, about 60 yields per second at maximum. Then it does a thread switch and passes CPU time to the next waiting thread.

Older name was DisableBackgroundTasks, but that has the meaning of the parameter reversed.

BoundsChecking

This pragma seems to have no effect currently. The array function always raise exceptions.
I think in older compilers before LLVM, the array access was inlined and thus the compiler could leave away the check.
See Issue 39349.

Older name was DisableBoundsChecking, but that has the meaning of the parameter reversed.

BreakOnExceptions

Calls BreakOnExceptions function for the runtime. So this can be turned on/off by wrapping in normal If condition and it takes effect to called methods.
When building an application, this pragma is ignored.

NilObjectChecking

Changes whether compiler adds "if" to check for nil.
So if you write win.test, the compiler basically writes:

If win = nil then
RaiseNilObjectException
Else
win.test
End if

But due to the compiler being extra cautious, it checks self for nil in the test method. See issue 64102.
And it does a lot of duplicate checking. See issue 45299

StackOverflowChecking

Whether compiler adds a call to RuntimeStackCheck function on the begin of the method.
This function just checks if Xojo's thread is nearly full and raises an exception, if we are close to the size limit.
The only use is for this to avoid endless recursion. So we often use this pragma for functions, which don't call other functions, so there is no recursion possible and we can skip it.

Warning

Outputs the text warning while doing compile/analzye.

Error

Outputs the text error while doing compile/analzye.

X86CallingConvention

Changes how the code is generated by compiler. Calling conventions defines who cleans up the stack. And this can be either caller (cdicl) or calle (std call). You may only need that difference for

More pragmas

There are more pragma known, but not documented. For example most framework methods are marked via pragma to not show up in the debugger. If they raise an exception, you don't see the framework code, but your method calling it. There have been bugs, where the debugger did stop and show framework code, but that was long ago.