[flang] Detect and report parsing failure (#121349)

The flang-new driver doesn't check for the case of the parser failing to
consume the entire input file. This is of course never an ideal outcome,

[flang] Detect and report parsing failure (#121349)

The flang-new driver doesn't check for the case of the parser failing to
consume the entire input file. This is of course never an ideal outcome,
and usually signals a need to improve error recovery, but it is better
for the compiler to admit failure rather than to silently proceed with
compilation of what may well be an incomplete parse tree.

show more ...

[flang][preprocessor] Don't expand INCLUDE under -E by default (#110333)

Fortran INCLUDE lines have (until now) been treated like #include
directives. This isn't how things work with other Fortran

[flang][preprocessor] Don't expand INCLUDE under -E by default (#110333)

Fortran INCLUDE lines have (until now) been treated like #include
directives. This isn't how things work with other Fortran compilers when
running under the -E option for preprocessing only, so stop doing it by
default, and add -fpreprocess-include-lines to turn it back on when
desired.

show more ...

[flang] Add -fhermetic-module-files (#98083)

Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their mod

[flang] Add -fhermetic-module-files (#98083)

Module files emitted by this Fortran compiler are valid Fortran source
files. Symbols that are USE-associated into modules are represented in
their module files with USE statements and special comments with hash
codes in them to ensure that those USE statements resolve to the same
modules that were used to build the module when its module file was
generated.

This scheme prevents unchecked module file growth in large applications
by not emitting USE-associated symbols redundantly. This problem can be
especially bad when derived type definitions must be repeated in the
module files of their clients, and the clients of those modules, and so
on. However, this scheme has the disadvantage that clients of modules
must be compiled with dependent modules in the module search path.

This new -fhermetic-module-files option causes module file output to be
free of dependences on any non-intrinsic module files; dependent modules
are instead emitted as part of the module file, rather than being
USE-associated. It is intended for top level library module files that
are shipped with binary libraries when it is not convenient to collect
and ship their dependent module files as well.

Fixes https://github.com/llvm/llvm-project/issues/97398.

show more ...

[flang] Intermix messages from parser and semantic analysis (#90654)

When there are one or more fatal error messages produced by the parser,
semantic analysis is not performed. But when there are m

[flang] Intermix messages from parser and semantic analysis (#90654)

When there are one or more fatal error messages produced by the parser,
semantic analysis is not performed. But when there are messages produced
by the parser and none of them are fatal, those messages are emitted to
the user before compilation continues with semantic analysis, and any
messages produced by semantics are emitted after the messages from
parsing.

This can be confusing for the user, as the messages may no longer all be
in source file location order. It also makes it difficult to write tests
that check for both non-fatal messages from parsing as well as messages
from semantics using inline CHECK: or other expected messages in test
source code.

This patch ensures that if semantic analysis is performed, and non-fatal
messages were produced by the parser, that all the messages will be
combined and emitted in source file order.

show more ...

[flang][cuda] Enable cuda with -x cuda option (#84944)

Flang driver was already able to enable the CUDA language feature base
on the file extension but there was no command line option. This PR add

[flang][cuda] Enable cuda with -x cuda option (#84944)

Flang driver was already able to enable the CUDA language feature base
on the file extension but there was no command line option. This PR adds
one.

show more ...

[flang][driver][nfc] Move the definition of SemanticsContext (#73669)

Moves the defintion of `SemanticsContext` within the Flang driver.

Rather than in `CompilerInvocation`, semantic context fits

[flang][driver][nfc] Move the definition of SemanticsContext (#73669)

Moves the defintion of `SemanticsContext` within the Flang driver.

Rather than in `CompilerInvocation`, semantic context fits better within
`CompilerInstance` that encapsulates the objects that are required to
run the
frontend. `CompilerInvocation` is better suited for objects
encapsulating compiler configuration (e.g. set-up resulting from user
input or host set-up).

show more ...

[flang] CUDA Fortran - part 1/5: parsing

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature en

[flang] CUDA Fortran - part 1/5: parsing

Begin upstreaming of CUDA Fortran support in LLVM Flang.

This first patch implements parsing for CUDA Fortran syntax,
including:
- a new LanguageFeature enum value for CUDA Fortran
- driver change to enable that feature for *.cuf and *.CUF source files
- parse tree representation of CUDA Fortran syntax
- dumping and unparsing of the parse tree
- the actual parsers for CUDA Fortran syntax
- prescanning support for !@CUF and !$CUF
- basic sanity testing via unparsing and parse tree dumps

... along with any minimized changes elsewhere to make these
work, mostly no-op cases in common::visitors instances in
semantics and lowering to allow them to compile in the face
of new types in variant<> instances in the parse tree.

Because CUDA Fortran allows the kernel launch chevron syntax
("call foo<<<blocks, threads>>>()") only on CALL statements and
not on function references, the parse tree nodes for CallStmt,
FunctionReference, and their shared Call were rearranged a bit;
this caused a fair amount of one-line changes in many files.

More patches will follow that implement CUDA Fortran in the symbol
table and name resolution, and then semantic checking.

Differential Revision: https://reviews.llvm.org/D150159

show more ...

[clang] Include the error message in file reading error diagnostic

in order to provide as much information as possible to the user. The
diagnostic will now look like for example:

error: error rea

[clang] Include the error message in file reading error diagnostic

in order to provide as much information as possible to the user. The
diagnostic will now look like for example:

error: error reading '/tmp/foo.c': Permission denied

(This addresses a FIXME from 2019, 9ef6c49baf45)

Differential revision: https://reviews.llvm.org/D146280

show more ...

[flang][driver] Switch to the MLIR coding style in the driver (nfc)

This patch re-factors the driver code in LLVM Flang (frontend +
compiler) to use the MLIR style. For more context, please see:
htt

[flang][driver] Switch to the MLIR coding style in the driver (nfc)

This patch re-factors the driver code in LLVM Flang (frontend +
compiler) to use the MLIR style. For more context, please see:
https://discourse.llvm.org/t/rfc-coding-style-in-the-driver/

Most changes here are rather self-explanatory. Accessors are renamed to
be more consistent with the rest of LLVM (e.g. allSource -->
getAllSources). Additionally, MLIR clang-tidy files are added in the
affected directories.

clang-tidy and clang-format files were copied from MLIR. Small
additional changes are made to silence clang-tidy/clang-format
warnings.

[1] https://mlir.llvm.org/getting_started/DeveloperGuide/

Differential Revision: https://reviews.llvm.org/D125007

show more ...

[flang][driver] NFC: Make code more in line with LLVM style

This patch basically implements [1] in ExecuteCompilerInvocation.cpp. It
also:
* replaces `CreateFrontendBaseAction` with `CreateFronten

[flang][driver] NFC: Make code more in line with LLVM style

This patch basically implements [1] in ExecuteCompilerInvocation.cpp. It
also:
* replaces `CreateFrontendBaseAction` with `CreateFrontendAction`
(only one method is needed ATM, this change removes the extra
indirection)
* removes `InvalidAction` from the `ActionKind` enum (I don't think it
adds much and keeping it would mean adding a new void case in
`CreateFrontendAction`)
* sets the default frontend action in FrontendOptions.h to
`ParseSyntaxOnly` (note that this is still overridden independently
in `ParseFrontendArg` in CompilerInvocation.cpp)

No new functionality is added, hence no tests.

[1] https://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

Differential Revision: https://reviews.llvm.org/D124245

show more ...

[flang][driver] Make `flang-new` always generate run-time type info

Currently, the driver generates the tables with "run-time type
information for derived types" only when specific actions are run.

[flang][driver] Make `flang-new` always generate run-time type info

Currently, the driver generates the tables with "run-time type
information for derived types" only when specific actions are run.
However, the corresponding data might be required by the subsequent
compilation stages (e.g. lowering, code-gen) and should be generated
unconditionally. Note that this is only possible once the semantic
checks have been run.

Note that when generating these tables, extra semantic errors might be
generated. The driver will always report these and in most cases such
semantic errors will cause the driver to exit immediately. The only
exception are actions inheriting from `PrescanAndSemaDebugAction`.
Currently, there's only one such action: `DebugDumpAllAction`
(corresponds to `-fdebug-dump-all` command-line flag). I've updated the
comments for this action to clarify this.

This change will mostly affect lowering, which currently is only
available for most basic examples (e.g. empty programs). I wasn't able
to find a working case that would demonstrate the new behaviour. I
hope that this change is straightforward enough and am submitting it
without a test.

Differential Revision: https://reviews.llvm.org/D120051

show more ...

[flang][driver][nfc] Fix capitalisation

As pointed out in https://reviews.llvm.org/D93401, some methods in the
Flang driver are named inconsistently. The driver strives to follow
Flang's C++ style [

[flang][driver][nfc] Fix capitalisation

As pointed out in https://reviews.llvm.org/D93401, some methods in the
Flang driver are named inconsistently. The driver strives to follow
Flang's C++ style [1] and this patch updates these methods accordingly.

[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/C%2B%2Bstyle.md

Differential Revision: https://reviews.llvm.org/D118381

show more ...

[flang][nfc] Tweak the FrontendAction class

This patch refactors the `FrontendAction` class. It merely moves code
around so that re-using it is easier. No new functionality is
introduced.

1. Three

[flang][nfc] Tweak the FrontendAction class

This patch refactors the `FrontendAction` class. It merely moves code
around so that re-using it is easier. No new functionality is
introduced.

1. Three new member methods are introduced: `RunPrescan`, `RunParse`,
`RunSemanticChecks`.
2. The following free functions are re-implemented as member methods:
* `reportFatalSemanticErrors`
* `reportFatalScanningErrors`
* `reportFatalParsingErrors`
* `reportFatalErrors`
`reportFatalSemanticErrors` is updated to resemble the other error
reporting functions and to make the API more consistent.
3. The `BeginSourceFileAction` methods are simplified and the unused
input argument is deleted.

Differential Revision: https://reviews.llvm.org/D108130

show more ...

[flang][driver] Add support for Frontend Plugins

Introducing a plugin API and a simple HelloWorld Plugin example.
This patch adds the `-load` and `-plugin` flags to frontend driver and
the code arou

[flang][driver] Add support for Frontend Plugins

Introducing a plugin API and a simple HelloWorld Plugin example.
This patch adds the `-load` and `-plugin` flags to frontend driver and
the code around using custom frontend actions from within a plugin
shared library object.

It also adds to the Driver-help test to check the help option with the
updated driver flags.

Additionally, the patch creates a plugin-example test to check the
HelloWorld plugin example runs correctly. As part of this, a new CMake
flag (`FLANG_BUILD_EXAMPLES`) is added to allow the example to be built
and for the test to run.

This Plugin API has only been tested on Linux.

Reviewed By: awarzynski

Differential Revision: https://reviews.llvm.org/D106137

show more ...

[flang][nfc] Fix variable names in `FrontendOptions` & `PreprocessorOptions`

As all member variables in `FrontendOptions` and `PreprocessorOptions`
are public, we should be naming them as `variable`

[flang][nfc] Fix variable names in `FrontendOptions` & `PreprocessorOptions`

As all member variables in `FrontendOptions` and `PreprocessorOptions`
are public, we should be naming them as `variable` rather than
`variable_` [1]. This patch fixes that.

Also, `FrontendOptions` & `PreprocessorOptions` are re-defined as a
structs rather than classes (all fields are meant to be public).

[1]
https://github.com/llvm/llvm-project/blob/main/flang/docs/C%2B%2Bstyle.md#naming

Differential Revision: https://reviews.llvm.org/D107062

show more ...

[flang] Revert "PoC for Flang Driver Plugins"

This patch has not been reviewed and was commited by accident.

This reverts commit 788a5d4afe6407e647454a9832a7b4a27fba06bf.

PoC for Flang Driver Plugins

[flang][driver] Add support for `-cpp/-nocpp`

This patch adds support for the `-cpp` and `-nocpp` flags. The
implemented semantics match f18 (i.e. the "throwaway" driver), but are
different to gfort

[flang][driver] Add support for `-cpp/-nocpp`

This patch adds support for the `-cpp` and `-nocpp` flags. The
implemented semantics match f18 (i.e. the "throwaway" driver), but are
different to gfortran. In Flang the preprocessor is always run. Instead,
`-cpp/-nocpp` are used to control whether predefined and command-line
preprocessor macro definitions are enabled or not. In practice this is
sufficient to model gfortran`s `-cpp/-nocpp`.

In the absence of `-cpp/-nocpp`, the driver will use the extension of
the input file to decide whether to include the standard macro
predefinitions. gfortran's documentation [1] was used to decide which
file extension to use for this.

The logic mentioned above was added in FrontendAction::BeginSourceFile.
That's relatively late in the driver set-up, but this roughly where the
name of the input file becomes available. The logic for deciding between
fixed and free form works in a similar way and was also moved to
FrontendAction::BeginSourceFile for consistency (and to reduce
code-duplication).

The `-cpp/-nocpp` flags are respected also when the input is read from
stdin. This is different to:
* gfortran (behaves as if `-cpp` was used)
* f18 (behaves as if `-nocpp` was used)

Starting with this patch, file extensions are significant and some test
files had to be renamed to reflect that. Where possible, preprocessor
tests were updated so that they can be shared between `f18` and
`flang-new`. This was implemented on top of adding new test for
`-cpp/-nocpp`.

[1] https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html

Reviewed By: kiranchandramohan

Differential Revision: https://reviews.llvm.org/D99292

show more ...

[flang][driver] Add PrescanAction frontend action (nfc)

This new action encapsulates all actions that require the prescanner to
be run before proceeding with other processing. By adding this new
act

[flang][driver] Add PrescanAction frontend action (nfc)

This new action encapsulates all actions that require the prescanner to
be run before proceeding with other processing. By adding this new
action, we are better equipped to control which actions _do_ run the
prescanner and which _do not_.

The following actions that require the prescanner are refactored to
inherit from `PrescanAction`:
* `PrintPreprocessedAction`
* `ParseSyntaxOnlyAction` .

New virtual method is introduced to facilitate all this:
* `BeginSourceFileAction`
Like in Clang, this method is run inside `BeginSourceFile`. In other
words, it is invoked before `ExecuteAction` for the corresponding
frontend action is run. This method allows us to:
* carry out any processing that is always required by the action (e.g.
run the prescanner)
* fine tune the settings/options on a file-by-file basis (e.g. to
decide between fixed-form and free-form based on file extension)

This patch implements non-functional-changes.

Reviewed By: FarisRehman

Differential Revision: https://reviews.llvm.org/D95464

show more ...

[flang][driver] Disallow non-existent input files in the frontend driver

This patch adds a check that verifies that the input file used when
calling the frontend driver (i.e. `flang-new -fc1`) actua

[flang][driver] Disallow non-existent input files in the frontend driver

This patch adds a check that verifies that the input file used when
calling the frontend driver (i.e. `flang-new -fc1`) actually exists.
This was not required for the compiler driver, `flang-new`, as that's
already handled in libclangDriver.

Once all input/output file management is moved to the driver, we should
also check that for input from `stdin` the corresponding file descriptor
was successfully acquired.

This patch also makes sure that the default action in the frontend is
`ParseSyntaxOnly`. This is consistent with Clang. Before this change
`flang-new -fc1` would do nothing, which makes testing changes like the
one introduced here a bit tricky.

Reviewed By: SouraVX

Differential Revision: https://reviews.llvm.org/D95127

show more ...

[flang][driver] Move fixed/free from detection out of FrontendAction API

All Fortran options should be set in `CompilerInstance` (via its
`CompilerInvocation`) before any of `FrontendAction` is ente

[flang][driver] Move fixed/free from detection out of FrontendAction API

All Fortran options should be set in `CompilerInstance` (via its
`CompilerInvocation`) before any of `FrontendAction` is entered -
that's one of the tasks of the driver. However, this is a bit tricky
with fixed and free from detection introduced in
https://reviews.llvm.org/D94228.

Fixed-free form detection needs to happen:
* before any frontend action (we need to specify `isFixedForm` in
`Fortran::parser::Options` before running any actions)
* separately for every input file (we might be compiling multiple
Fortran files, some in free form, some in fixed form)
In other words, we need this to happen early (before any
`FrontendAction`), but not too early (we need to know what the current
input file is). In practice, `isFixedForm` can only be set later
than other options (other options are inferred from compiler flags). So
we can't really set all of them in one place, which is not ideal.

All changes in this patch are NFCs (hence no new tests). Quick summary:
* move fixed/free form detection from `FrontendAction::ExecuteAction` to
`CompilerInstance::ExecuteAction`
* add a bool flag in `FrontendInputFile` to mark a file as fixed/free
form
* updated a few comments

Differential Revision: https://reviews.llvm.org/D95042

show more ...

[flang][driver] Move isFixedFormSuffix and isFreeFormSuffix to flangFrontend

isFixedFormSuffix and isFreeFormSuffix should be defined in
flangFrontend rather than flangFrontendTool library. That's f

[flang][driver] Move isFixedFormSuffix and isFreeFormSuffix to flangFrontend

isFixedFormSuffix and isFreeFormSuffix should be defined in
flangFrontend rather than flangFrontendTool library. That's for 2
reasons:
* these methods are used in flangFrontend rather than flangFrontendTool
* flangFrontendTool depends on flangFrontend

As mentioned in the post-commit review for D94228, without this change
shared library builds fail.

Differential Revision: https://reviews.llvm.org/D94968

show more ...

[flang][driver] Add support for fixed form detection

Currently the new flang driver always runs in free form mode. This patch
adds support for fixed form mode detection based on the file extensions.

[flang][driver] Add support for fixed form detection

Currently the new flang driver always runs in free form mode. This patch
adds support for fixed form mode detection based on the file extensions.

Like `f18`, `flang-new` will treat files ending with ".f", ".F" and
".ff" as fixed form. Additionally, ".for", ".FOR", ".fpp" and ".FPP"
file extensions are recognised as fixed form files. This is consistent
with gfortran [1]. In summary, files with the following extensions are
treated as fixed-form:
* ".f", ".F", ".ff", ".for", ".FOR", ".fpp", ".FPP"

For consistency with flang/test/lit.cfg.py and f18, this patch also adds
support for the following file extensions:
* ".ff", ".FOR", ".for", ".ff90", ".fpp", ".FPP"
This is added in flang/lib/Frontend/FrontendOptions.cpp. Additionally,
the following extensions are included:
* ".f03", ".F03", ".f08", ".F08"
This is for compatibility with gfortran [1] and other popular Fortran
compilers [2].

NOTE: internally Flang will only differentiate between fixed and free
form files. Currently Flang does not support switching between language
standards, so in this regard file extensions are irrelevant. More
specifically, both `file.f03` and `file.f18` are represented with
`Language::Fortran` (as opposed to e.g. `Language::Fortran03`).

Summary of changes:
- Set Fortran::parser::Options::sFixedForm according to the file type
- Add isFixedFormSuffix and isFreeFormSuffix helper functions to
FrontendTool/Utils.h
- Change FrontendOptions::GetInputKindForExtension to support the missing
file extensions that f18 supports and some additional ones
- FrontendActionTest.cpp is updated to make sure that the test input is
treated as free-form

[1] https://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-and-GCC.html
[2] https://github.com/llvm/llvm-project/blob/master/flang/docs/OptionComparison.md#notes

Differential Revision: https://reviews.llvm.org/D94228

show more ...

[flang][driver] Update error messages (nfc)

As per Flang's coding guidelines
(flang/docs/C++style.md#error-messages):
```
Messages should start with a capital letter.
```

This patch updates error m

[flang][driver] Update error messages (nfc)

As per Flang's coding guidelines
(flang/docs/C++style.md#error-messages):
```
Messages should start with a capital letter.
```

This patch updates error messages in the driver (new and old) so that
they conform with the guideline above.

This change was suggested in one of the recent reviews:
https://reviews.llvm.org/D93712. It felt like this deserved a dedicated
patch, so sending it separately.

show more ...

[flang][driver] Add checks for errors from `Prescan` and `Parse`

If either `Prescan` or `Parse` generate any fatal errors, the new driver
will:
* report it (i.e. issue an error diagnostic)
* exi

[flang][driver] Add checks for errors from `Prescan` and `Parse`

If either `Prescan` or `Parse` generate any fatal errors, the new driver
will:
* report it (i.e. issue an error diagnostic)
* exit early
* return non-zero exit code
This behaviour is consistent with f18 (i.e. the old driver).

Reviewed By: sameeranjoshi

Differential Revision: https://reviews.llvm.org/D93712

show more ...