#
0f973ac7 |
| 02-Oct-2024 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as
[flang] Tag warnings with LanguageFeature or UsageWarning (#110304)
(This is a big patch, but it's nearly an NFC. No test results have
changed and all Fortran tests in the LLVM test suites work as expected.)
Allow a parser::Message for a warning to be marked with the
common::LanguageFeature or common::UsageWarning that controls it. This
will allow a later patch to add hooks whereby a driver will be able to
decorate warning messages with the names of its options that enable each
particular warning, and to add hooks whereby a driver can map those
enumerators by name to command-line options that enable/disable the
language feature and enable/disable the messages.
The default settings in the constructor for LanguageFeatureControl were
moved from its header file into its C++ source file.
Hooks for a driver to use to map the name of a feature or warning to its
enumerator were also added.
To simplify the tagging of warnings with their corresponding language
feature or usage warning, to ensure that they are properly controlled by
ShouldWarn(), and to ensure that warnings never issue at code sites in
module files, two new Warn() member function templates were added to
SemanticsContext and other contextual frameworks. Warn() can't be used
before source locations can be mapped to scopes, but the bulk of
existing code blocks testing ShouldWarn() and FindModuleFile() before
calling Say() were convertible into calls to Warn(). The ones that were
not convertible were extended with explicit calls to
Message::set_languageFeature() and set_usageWarning().
show more ...
|
#
1dd8da2d |
| 02-May-2022 |
Emil Kieri <j.emil.kieri@gmail.com> |
[flang] Fix semantics check for RETURN statement
The RETURN statement is allowed in functions and subroutines, but not in main programs. It is however a common extension, which we also implement, to
[flang] Fix semantics check for RETURN statement
The RETURN statement is allowed in functions and subroutines, but not in main programs. It is however a common extension, which we also implement, to allow RETURN from main programs -- we only issue a portability warning when -pedantic or -std=f2018 are set.
This patch fixes false positives for this portability warning, where it was triggered also when RETURN was present in functions or subroutines.
Fixexs #55080
Reviewed By: PeteSteinfeld
Differential Revision: https://reviews.llvm.org/D124732
show more ...
|
#
a53967cd |
| 07-Mar-2022 |
Peter Klausler <pklausler@nvidia.com> |
[flang] Distinguish usage and portability warning messages
Using recently established message severity codes, upgrade non-fatal messages to usage and portability warnings as appropriate.
Differenti
[flang] Distinguish usage and portability warning messages
Using recently established message severity codes, upgrade non-fatal messages to usage and portability warnings as appropriate.
Differential Revision: https://reviews.llvm.org/D121246
show more ...
|
#
1f525ece |
| 02-Dec-2020 |
Tim Keith <tkeith@nvidia.com> |
[flang][NFC] Add GetTopLevelUnitContaining functions
`GetTopLevelUnitContaining` returns the Scope nested in the global scope that contains the given Scope or Symbol.
Use "Get" rather than "Find" i
[flang][NFC] Add GetTopLevelUnitContaining functions
`GetTopLevelUnitContaining` returns the Scope nested in the global scope that contains the given Scope or Symbol.
Use "Get" rather than "Find" in the name because "Find" implies it might not be found, which can't happen. Following that logic, rename `FindProgramUnitContaining` to `GetProgramUnitContaining` and have it also return a reference rather that a pointer.
Note that the use of "ProgramUnit" is slightly confusing. In the Fortran standard, "program-unit" refers to what is called a "TopLevelUnit" here. What we are calling a "ProgramUnit" (here and in `ProgramTree`) includes internal subprograms while "TopLevelUnit" does not.
Differential Revision: https://reviews.llvm.org/D92491
show more ...
|
#
1f879005 |
| 29-Mar-2020 |
Tim Keith <tkeith@nvidia.com> |
[flang] Reformat with latest clang-format and .clang-format
Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f Reviewed-on: https://github.com/flang-compiler/f18/pull/1094
|
#
64ab3302 |
| 25-Feb-2020 |
CarolineConcatto <51754594+CarolineConcatto@users.noreply.github.com> |
[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)
This patch renames the modules in f18 to use a capital letter in the
module name
Signed-off-b
[flang] [LLVMify F18] Compiler module folders should have capitalised names (flang-compiler/f18#980)
This patch renames the modules in f18 to use a capital letter in the
module name
Signed-off-by: Caroline Concatto <caroline.concatto@arm.com>
Original-commit: flang-compiler/f18@d2eb7a1c443d1539ef12b6f027074a0eb15b1ea0 Reviewed-on: https://github.com/flang-compiler/f18/pull/980
show more ...
|