aboutsummaryrefslogtreecommitdiff
path: root/flang/lib/Semantics/scope.cpp
AgeCommit message (Collapse)AuthorFilesLines
2024-12-18[flang] Add UNSIGNED (#113504)Peter Klausler1-0/+1
Implement the UNSIGNED extension type and operations under control of a language feature flag (-funsigned). This is nearly identical to the UNSIGNED feature that has been available in Sun Fortran for years, and now implemented in GNU Fortran for gfortran 15, and proposed for ISO standardization in J3/24-116.txt. See the new documentation for details; but in short, this is C's unsigned type, with guaranteed modular arithmetic for +, -, and *, and the related transformational intrinsic functions SUM & al.
2024-09-17[flang] Tidy uses of raw_string_ostream (NFC)Youngsuk Kim1-1/+1
As specified in the docs, 1) raw_string_ostream is always unbuffered and 2) the underlying buffer may be used directly ( 65b13610a5226b84889b923bae884ba395ad084d for further reference ) Avoid unneeded calls to raw_string_ostream::str(), to avoid excess indirection.
2024-06-11[flang] Change argument to const reference (#95048)Peter Klausler1-1/+1
cppcheck recommends that a std::map being passed by value be changed to a const reference. Fixes https://github.com/llvm/llvm-project/issues/94932.
2023-08-29[flang] Faster implementation of FindScope()Peter Klausler1-18/+11
The utility semantics::SemanticsContext::FindScope() maps a contiguous range of cooked source characters to the innermost Scope containing them. Its implementation is unacceptably slow on large (tens of thousands of lines) source files with many program units; it traverses each level of the scope tree linearly. Replace this implementation with a single instance of std::multimap<> used as an index from each Scope's source range back to the Scope. Compilation time with "-fsyntax-only" on the 50,000-line test case that motivated this change drops from 4.36s to 3.72s, and FindScope() no longer stands out egregiously in the profile. Differential Revision: https://reviews.llvm.org/D159027
2023-05-31[flang] CUDA Fortran - part 2/5: symbols & scopesPeter Klausler1-2/+2
Add representations of CUDA Fortran data and subprogram attributes to the symbol table and scopes of semantics. Set them in name resolution, and emit them to module files. Depends on https://reviews.llvm.org/D150159. Differential Revision: https://reviews.llvm.org/D150161
2023-05-17[flang] Catch (and fix) attempts to create an invalid source range for a ScopePeter Klausler1-4/+45
When Scope::AddSourceRange() is called to extend the scope's source range to include another snippet from a cooked character stream, add a check to ensure that the new range is part of the same cooked character stream as the rest of the scope. And fix the bug that was causing such invalid source ranges to be created: a submodule's Scope is a children of its parent's in the Scope tree, but it may or may not be part of the same source file, and it is certainly not enclosed in the parent's source range. So don't propagate Scope source range expansion from a submodule to its parent. Differential Revision: https://reviews.llvm.org/D150714
2023-01-27[flang] Prohibit multiple separate module procedure definitionsPeter Klausler1-0/+3
Ensure that non-BIND(C) separate module procedures are not defined more than once. Differential Revision: https://reviews.llvm.org/D142750
2023-01-23[Flang] fix a copy-paste error in scope.cppShivam Gupta1-1/+1
found by PVS-Studio. Reviewed By: jeanPerier, klausler Differential Revision: https://reviews.llvm.org/D142306
2022-04-20[flang] Do not pass derived type by descriptor when not neededJean Perier1-24/+31
A missing "!" in the call interface lowering caused all derived type arguments without length parameters that require and explicit interface to be passed via fir.box (runtime descriptor). This was not the intent: there is no point passing a simple derived type scalars or explicit shapes by descriptor just because they have an attribute like TARGET. This would actually be problematic with existing code that is not always 100% compliant: some code implicitly calls procedures with TARGET dummy attributes (this is not something a compiler can enforce if the call and procedure definition are not in the same file). Add a Scope::IsDerivedTypeWithLengthParameter to avoid passing derived types with only kind parameters by descriptor. There is no point, the callee knows about the kind parameter values. Differential Revision: https://reviews.llvm.org/D123990
2022-03-11[flang][NFC] rename IsKindParameterizedDerivedType and fix comment typosJean Perier1-2/+2
Following post-review feedback on https://reviews.llvm.org/D120804 and https://reviews.llvm.org/D120801 about type descriptor changes, fix typos in comments and rename IsKindParameterizedDerivedType to IsDerivedTypeWithKindParameter. Remove a useless `;`. Reviewed By: clementval, PeteSteinfeld Differential Revision: https://reviews.llvm.org/D121470
2022-03-03[flang] Generate PDT runtime type info in the type definition scopeJean Perier1-0/+19
This patches modifies PDT runtime type info generation so that it is easier to handle derived type descriptor in lowering. It changes three aspects: 1. The symbol name suffix of runtime type info for PDT instantiation is changed from a serial number unrelated to the types to an encoding of the instantiated KIND parameters. 2. New runtime type info is not created for each instantiation of PDT without KIND parameters (only length parameters). Instead, the runtime type info of the type definition is always used. It is updated to contain the component descriptions. 3. Runtime type info of PDT instantiation is now always generated in the scope where the type is defined. If several PDT type instantiation are made in different scope with the same kind parameters, they will use the same runtime type info. Rational of the change: In lowering, derived type descriptors are not mapped when instantiating derived type objects. They are mapped later when symbol knowledge is not available anymore. This mapping is based on the FIR representation of derived types. For PDT, the FIR type information does not allow deducing the instantiation scope, it only allows retrieving the type name, the type _definition_ scope, and the kind parameter values. Therefore, in order to be able to retrieve the derived type descriptor from a FIR type, the derived type descriptor must be generated in the definition scope and must reflect the kind parameters. This justifies the need for changes 1. and 3. above (suffix and scope change). Changes 2. comes from the fact that all runtime type info of type without kind parameters can be generated from the type definition, and that because of the suffix change, the symbol name for type definition and type instantiation are the same. Although this change is first motivated by how lowering handles derived types, I believe it is also an improvement from a functional point of view since this change will allow reducing the number of generated runtime type info for PDTs, since redundant information (different instantiations with same kind parameters) will only be generated once. Differential Revision: https://reviews.llvm.org/D120801
2022-01-31[flang] Distinguish intrinsic from non-intrinsic modulesPeter Klausler1-3/+3
For "USE, INTRINSIC", search only for intrinsic modules; for "USE, NON_INTRINSIC", do not recognize intrinsic modules. Allow modules of both kinds with the same name to be used in the same source file (but not in the same scoping unit, a constraint of the standard that is now enforced). The symbol table's scope tree now has a single instance of a scope with a new kind, IntrinsicModules, whose children are the USE'd intrinsic modules (explicit or not). This separate "top-level" scope is a child of the single global scope and it allows both intrinsic and non-intrinsic modules of the same name to exist in the symbol table. Intrinsic modules' scopes' symbols now have the INTRINSIC attribute set. The search path directories need to make a distinction between regular directories and the one(s) that point(s) to intrinsic modules. I allow for multiple intrinsic module directories in the second search path, although only one is needed today. Differential Revision: https://reviews.llvm.org/D118631
2021-06-03[flang] Support known constant lengths in DynamicTypepeter klausler1-1/+1
The constexpr-capable class evaluate::DynamicType represented CHARACTER length only with a nullable pointer into the declared parameters of types in the symbol table, which works fine for anything with a declaration but turns out to not suffice to describe the results of the ACHAR() and CHAR() intrinsic functions. So extend DynamicType to also accommodate known constant CHARACTER lengths, too; use them for ACHAR & CHAR; clean up several use sites and fix regressions found in test. Differential Revision: https://reviews.llvm.org/D103571
2021-06-03[flang] Fix crashes due to failure to find a subprogrampeter klausler1-1/+1
In error recovery situations, the mappings from source locations to scopes were failing in a way that tripped some asserts. Specifically, FindPureProcedureContaining() wasn't coping well when starting at the global scope. (And since the global scope no longer has a source range, clean up the Semantics constructor to avoid confusion.) Differential Revision: https://reviews.llvm.org/D103567
2021-04-09[flang] Enforce a limit on recursive PDT instantiationspeter klausler1-1/+1
For pernicious test cases with explicit non-constant actual type parameter expressions in components, e.g.: type :: t(k) integer, kind :: k type(t(k+1)), pointer :: p end type we should detect the infinite recursion and complain rather than looping until the stack overflows. Differential Revision: https://reviews.llvm.org/D100065
2021-03-18[flang] Refine symbol sortingpeter klausler1-1/+1
Replace semantics::SymbolSet with alternatives that clarify whether the set should order its contents by source position or not. This matters because positionally-ordered sets must not be used for Symbols that might be subjected to name replacement during name resolution, and address-ordered sets must not be used (without sorting) in circumstances where the order of their contents affects the output of the compiler. All set<> and map<> instances in the compiler that are keyed by Symbols now have explicit Compare types in their template instantiations. Symbol::operator< is no more. Differential Revision: https://reviews.llvm.org/D98878
2021-03-16[flang] Order Symbols by source provenancepeter klausler1-3/+3
In parser::AllCookedSources, implement a map from CharBlocks to the CookedSource instances that they cover. This permits a fast Find() operation based on std::map::equal_range to map a CharBlock to its enclosing CookedSource instance. Add a creation order number to each CookedSource. This allows AllCookedSources to provide a Precedes(x,y) predicate that is a true source stream ordering between two CharBlocks -- x is less than y if it is in an earlier CookedSource, or in the same CookedSource at an earlier position. Add a reference to the singleton SemanticsContext to each Scope. All of this allows operator< to be implemented on Symbols by means of a true source ordering. From a Symbol, we get to its Scope, then to the SemanticsContext, and then use its AllCookedSources reference to call Precedes(). Differential Revision: https://reviews.llvm.org/D98743
2021-02-22Making FindCommonBlock a const memberRenaud-K1-1/+1
https://reviews.llvm.org/D97093
2021-01-29[flang] Support disabled alternative PARAMETER statementpeter klausler1-0/+43
Legacy Fortran implementations support an alternative form of the PARAMETER statement; it differs syntactically from the standard's PARAMETER statement by lacking parentheses, and semantically by using the type and shape of the initialization expression to define the attributes of the named constant. (GNU Fortran gets that part wrong; Intel Fortran and nvfortran have full support.) This patch disables the old style PARAMETER statement by default, as it is syntactically ambiguous with conforming assignment statements; adds a new "-falternative-parameter-statement" option to enable it; and implements it correctly when enabled. Fixes https://bugs.llvm.org/show_bug.cgi?id=48774, in which a user tripped over the syntactic ambiguity. Differential Revision: https://reviews.llvm.org/D95697
2020-11-11[flang] Fix CheckSpecificationExpr handling of associated namespeter klausler1-7/+0
Avoid a spurious error message about a dummy procedure reference in a specification expression by restructuring the handling of use-associated and host-associated symbols. Updated to fix a circular dependence between shared library binaries that was introduced by the original patch. Differential revision: https://reviews.llvm.org/D91286
2020-09-11[flang] Fix build issue with BUILD_SHARED_LIBS=ONRichard Barton1-8/+0
Define Fortran::Semantics::Scope::GetName in the header so it is available to Fortran::Evaluate::Tool::AttachDeclaration without a circular dependency introduced in 82edd42. Reviewed By: tskeith Differential Revision: https://reviews.llvm.org/D87505
2020-09-02[flang] Support multiple CookedSource instancespeter klausler1-8/+0
These are owned by an instance of a new class AllCookedSources. This removes the need for a Scope to own a string containing a module's cooked source stream, and will enable errors to be emitted when parsing module files in the future. Differential Revision: https://reviews.llvm.org/D86891
2020-07-26[flang] Fix implicit declarations in statement functionsTim Keith1-0/+4
If a symbol (that is not a dummy argument) is implicitly declared inside a statement function, don't create it in the statement function's scope. Instead, treat statement functions like blocks when finding the inclusive scope and create the symbol there. Add a new flag, StmtFunction, to symbols that represent statement functions. Differential Revision: https://reviews.llvm.org/D84588
2020-05-29[flang][NFC] Remove link-time dependency of Evaluate on SemanticsTim Keith1-10/+0
Summary: Some Symbol-related functions used in Evaluate were moved to Evaluate/tools.h. This includes changing some member functions that were replaced by non-member functions `IsDummy`, `GetUsedModule`, and `CountLenParameters`. Some member functions were made inline in `Scope`, `Symbol`, `ArraySpec`, and `DeclTypeSpec`. The definitions were preceded by a comment explaining why they are inline. `IsConstantShape` was expanded inline in `IsDescriptor` because it isn't used anywhere else After this change, at least when compiling with clang on macos, `libFortranEvaluate.a` has no undefined symbols that are satisfied by `libFortranSemantics.a`. Reviewers: klausler, PeteSteinfeld, sscalpone, jdoerfert, DavidTruby Reviewed By: PeteSteinfeld Subscribers: llvm-commits Tags: #flang, #llvm Differential Revision: https://reviews.llvm.org/D80762
2020-05-06[flang][NFC] Add accessors to equivalence and common blocksTim Keith1-5/+2
Add a way to get mutable equivalence sets to Scope so that they can have sizes and offsets assigned to them. Change CommonBlockDetails to have mutable symbols so that they can have sizes and offets assigned to them. This also allows the removal of some `const_cast`s. Add MutableSymbolRef and MutableSymbolVector as mutable analogs to SymbolRef and SymbolVector. Replace uses of equivalent types with those names. Differential Revision: https://reviews.llvm.org/D79346
2020-04-23[flang] Compute sizes and offsets for symbolsTim Keith1-0/+22
Summary: Add size and offset properties to symbols, representing their byte size and offset within their enclosing scope. Add size and align properties to scopes so that they are available for scopes representing derived types. Add ComputeOffsets pass over the symbol table to fill in those fields. Compute descriptor size based on rank and length parameters. Extract DerivedTypeSpec::NumLengthParameters from DynamicType::RequiresDescriptor to share the code. Add Scope::GetSymbols to get symbols in canonical order. compute-offsets.cpp and mod-file.cpp both need to process symbols in the order in which they are declared. Move the collecting of those symbols into Scope so that it can be shared. Add symbol size and offset to output of `-fdebug-dump-symbols` and use that in some tests. Still to do: - make size and alignment rules configurable based on target - use offsets to check EQUIVALENCE statements Differential Revision: https://reviews.llvm.org/D78680
2020-04-02[flang] Checks for constraints C731 through C740Pete Steinfeld1-0/+9
In most cases, I just added the contraint names to the code and tests. I implemented the following checks: - C736 A child type with a coarray ultimate component must have a parent with a coarray ultimate component. - C737 A child type with and EVENT_TYPE or LOCK_TYPE component must have a parent either which is EVENT_TYPE or LOCK_TYPE or a type with an EVENT_TYPE or LOCK_TYPE component. - C740 Sequence types must contain at least on component - C740 Data components of sequence types must either be of an intrinsic type or a sequenced derived type. After implementing these checks, some tests had new errors unrelated to their original purpose, so I fixed them. Original-commit: flang-compiler/f18@098f01bc474798ae03bd4dc7de6c929deec6f244 Reviewed-on: https://github.com/flang-compiler/f18/pull/1097
2020-03-28[flang] Reformat with latest clang-format and .clang-formatTim Keith1-6/+9
Original-commit: flang-compiler/f18@9fe84f45d7fd685051004678d6b5775dcc4c6f8f Reviewed-on: https://github.com/flang-compiler/f18/pull/1094
2020-03-19[flang] [LLVMify F18] Replace the use std::ostream with LLVM streams ↵Caroline Concatto1-3/+4
llvm::ostream This patch replaces the occurrence of std::ostream by llvm::raw_ostream. In LLVM Coding Standards[1] "All new code should use raw_ostream instead of ostream".[1] As a consequence, this patch also replaces the use of: std::stringstream by llvm::raw_string_ostream or llvm::raw_ostream* std::ofstream by llvm::raw_fd_ostream std::endl by '\n' and flush()[2] std::cout by llvm::outs() and std::cerr by llvm::errs() It also replaces std::strerro by llvm::sys::StrError** , but NOT in Fortran runtime libraries *std::stringstream were replaced by llvm::raw_ostream in all methods that used std::stringstream as a parameter. Moreover, it removes the pointers to these streams. [1]https://llvm.org/docs/CodingStandards.html [2]https://releases.llvm.org/2.5/docs/CodingStandards.html#ll_avoidendl Signed-off-by: Caroline Concatto <caroline.concatto@arm.com> Running clang-format-7 Signed-off-by: Caroline Concatto <caroline.concatto@arm.com> Removing residue of ostream library Signed-off-by: Caroline Concatto <caroline.concatto@arm.com> Original-commit: flang-compiler/f18@a3507d44b8911e6024033aa583c1dc54e0eb89fd Reviewed-on: https://github.com/flang-compiler/f18/pull/1047
2020-03-17[flang] Check module subprogram against separate module procedureTim Keith1-0/+3
When a module subprogram has the MODULE prefix the following must match with the corresponding separate module procedure interface body: - C1549: characteristics and dummy argument names - C1550: binding label - C1551: NON_RECURSIVE prefix SubprogramMatchHelper performs all of these checks. Rename separate-module-procs.f90 to separate-mp01.f90 so we can have separate-mp02.f90 (etc). Make ShapesAreCompatible public in characteristics.h. Add Scope::IsSubmodule. Original-commit: flang-compiler/f18@d121578af17109de3cea23617e4b8239971b5527 Reviewed-on: https://github.com/flang-compiler/f18/pull/1080
2020-03-17[flang] Create symbols for args of separate-module-subprogramTim Keith1-0/+12
A separate-module-subprogram is declared as `module procedure ...` and gets its characteristics from the declaration of that name as a separate module procedure. When we encounter one, we need to create symbols in the new subprogram scope for the dummy arguments and function return (if any). The failure to create these symbols led to the bug in issue flang-compiler/f18#1054: when a dummy argument was referenced, the compiler interpreted it as an implicit declaration because there was no symbol for the argument. Fixes flang-compiler/f18#1054. Original-commit: flang-compiler/f18@4d3c4bac843dcc6351fbe7538c6ce23bb9c1a215 Reviewed-on: https://github.com/flang-compiler/f18/pull/1080 Tree-same-pre-rewrite: false
2020-03-10[flang] Fix scope accessibility checkTim Keith1-2/+20
The check for whether a private component is accessible was depending on determining whether the source range of the current scope was within the source range of the module that the component was declared in. This could fail if the current scope was of kind `ImpliedDos` and had no source range. The fix is to add `Scope::Contains` to check the relationship by traversing the parent links. These are created when the Scope is so are always reliable. The source range of a scope is built up over time. Original-commit: flang-compiler/f18@d787108637adad358ccf8af3d200acb3f66ce099 Reviewed-on: https://github.com/flang-compiler/f18/pull/1060
2020-02-25[flang] [LLVMify F18] Compiler module folders should have capitalised names ↵CarolineConcatto1-0/+336
(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