Conditional Compilation Support

[Lordfirespeed]

Say I write the following LaTex:

\documentclass[10pt,journal,compsoc]{IEEEtran}

\ifCLASSOPTIONcompsoc
\IEEEraisesectionheading{\section{Introduction}\label{sec:introduction}}
\else
\section{Introduction}
\label{sec:introduction}
\fi

(Source: IEEE Template For Computer Science Journals, Copyright (c) 2005 Michael Shell)

Conditional compilation directives from the ifoption package mean that only one label will ever actually be defined - since my document has the compsoc class, the else block should be ignored.
TeXiFy IDEA is not aware of this:

Relevant Packages/Resources

• ifoption reference (MIT CTAN)
• ifoption source download (iBiblio CTAN)
• iftex reference/source (latex3/iftex)
• ifthen reference (TeXDoc)
• ifthen source (U.o. Utah CTAN)

Suggested Solution

I think the best way of solving this problem would be similar to how Rider supports preprocessor directives:

Rider uses environment context to determine which branch will be compiled and ignores the branches that will not be compiled.

I believe a similar implementation should be possible. As far as I can tell, the relevant packages rely on the following 'core' macros:

• \if
• \ifx
• \ifnum
• \iftrue
• \iffalse

So assuming that macro definitions are resolved successfully, implementing support for these should be sufficient.

Related

Other compilation control-flow macros exist, e.g. \whiledo - Ideally TeXiFy idea should also support these. E.g. \label{sec:introduction} inside a \whiledo should be highlighted with a warning.

[PHPirates]

Thanks for the suggestion! It is not possible to do this generically for all inspections at once, but we can fix the most common issues.

This example is a bit simpler, as a starting point:

\documentclass{article}

\newif\ifdog
\dogtrue

\begin{document}

    \ifdog
    \section{DOG}\label{sec:pet}
    \else
    \section{CAT}\label{sec:pet}
    \fi

\end{document}

What do you think are the most important use cases?

I agree with the duplicate label inspection coming up often, and maybe we can extend this already to \ifs defined in packages, but \ifCLASSOPTIONcompsoc will go a bit too far because then we would need to somehow detect from the definition that it's based on class options. Can you explain the definition?

Something else might be the formatter, would be nice to have the proper parts indented.

[Lordfirespeed]

@PHPirates thankyou for picking this up - my apologies for not responding sooner, I'm not sure how I missed your comment!

Would you mind briefly explaining what is/isn't handled by #3670? This would help me formulate a more helpful response to your initial question

Edit: I looked here and it seems like it's all based on (e.g.)

• defining a new conditional 'FOO': \newif\ifFOO
• declaring options that assign a value to the conditional: \DeclareOption{bar}{\FOOtrue}, \DeclareOption{baz}{\FOOfalse}
• applying the desired default option(s): \ExecuteOptions{bar}
• applying (package) consumer-specified option(s) specified in \documentclass, e.g. \documentclass[baz,...]{mypkg}
• using the conditional \ifFOO ... \fi

[PHPirates]

#3760 basically just checks if a label is between an \if* and an \else and then ignores it. I realise that that won't work in many cases, but I feel like if I try to do this in our BNF-based parser I'm going to create more problems than it solves.

The problem is that the meaning of some \if* is defined in a package (I could also do \renewcommand{\ifFoo}{not an if}), and it may or may not behave as an \if-like command, while the #if directive in C# is always an #if and never something else.

[Lordfirespeed]

@PHPirates Ah, I see! Thankyou for clarifying. Yeah, that seems like the best solution for the time being; static analysis is tricky stuff ... and I can very much relate to gripes with JetBrains' grammar format 😭