llvm-project/flang/lib/Semantics/check-nullify.cpp

68 lines
2.9 KiB
C++
Raw Normal View History

//===-- lib/Semantics/check-nullify.cpp -----------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "check-nullify.h"
#include "assignment.h"
#include "flang/Evaluate/expression.h"
#include "flang/Parser/message.h"
#include "flang/Parser/parse-tree.h"
#include "flang/Semantics/expression.h"
#include "flang/Semantics/tools.h"
namespace Fortran::semantics {
void NullifyChecker::Leave(const parser::NullifyStmt &nullifyStmt) {
CHECK(context_.location());
const Scope &scope{context_.FindScope(*context_.location())};
const Scope *pure{FindPureProcedureContaining(scope)};
parser::ContextualMessages messages{
*context_.location(), &context_.messages()};
for (const parser::PointerObject &pointerObject : nullifyStmt.v) {
std::visit(
common::visitors{
[&](const parser::Name &name) {
const Symbol &symbol{DEREF(name.symbol)};
if (context_.HasError(&symbol)) {
[flang] Continue semantic checking after name resolution error When an error occurs in name resolution, continue semantic processing in order to detect other errors. This means we can no longer assume that every `parser::Name` has a symbol even after name resolution completes. In `RewriteMutator`, only report internal error for unresolved symbol if there have been no fatal errors. Add `Error` flag to `Symbol` to indicate that an error occcurred related to it. Once we report an error about a symbol we should avoid reporting any more to prevent cascading errors. Add `HasError()` and `SetError()` to simplify working with this flag. Change some places that we assume that a `parser::Name` has a non-null symbol. There are probably more. `resolve-names.cc`: Set the `Error` flag when we report a fatal error related to a symbol. (This requires making some symbols non-const.) Remove `CheckScalarIntegerType()` as `ExprChecker` will take care of those constraints if they are expressed in the parse tree. One exception to that is the name in a `ConcurrentControl`. Explicitly perform that check using `EvaluateExpr()` and constraint classes so we get consistent error messages. In expression analysis, when a constraint is violated (like `Scalar<>` or `Integer<>`), reset the wrapped expression so that we don't assume it is valid. A `GenericExprWrapper` holding a std::nullopt indicates error. Change `EnforceTypeConstraint()` to return false when the constraint fails to enable this. check-do-concurrent.cc: Reorganize the Gather*VariableNames functions into one to simplify the task of filtering out unresolved names. Remove `CheckNoDuplicates()` and `CheckNoCollisions()` as those checks is already done in name resolution when the names are added to the scope. Original-commit: flang-compiler/f18@bcdb679405906575f36d3314f17da89e3e89d45c Reviewed-on: https://github.com/flang-compiler/f18/pull/429 Tree-same-pre-rewrite: false
2019-04-26 04:18:33 +08:00
// already reported an error
} else if (!IsVariableName(symbol) && !IsProcName(symbol)) {
messages.Say(name.source,
"name in NULLIFY statement must be a variable or procedure pointer name"_err_en_US);
} else if (!IsPointer(symbol)) { // C951
messages.Say(name.source,
"name in NULLIFY statement must have the POINTER attribute"_err_en_US);
} else if (pure) {
CheckDefinabilityInPureScope(messages, symbol, scope, *pure);
}
},
[&](const parser::StructureComponent &structureComponent) {
evaluate::ExpressionAnalyzer analyzer{context_};
if (MaybeExpr checked{analyzer.Analyze(structureComponent)}) {
if (!IsPointer(*structureComponent.component.symbol)) { // C951
messages.Say(structureComponent.component.source,
"component in NULLIFY statement must have the POINTER attribute"_err_en_US);
} else if (pure) {
if (const Symbol * symbol{GetFirstSymbol(checked)}) {
CheckDefinabilityInPureScope(
messages, *symbol, scope, *pure);
}
}
}
},
},
pointerObject.u);
}
// From 9.7.3.1(1)
// A pointer-object shall not depend on the value,
// bounds, or association status of another pointer-
// object in the same NULLIFY statement.
// This restriction is the programmer's responsibilty.
// Some dependencies can be found compile time or at
// runtime, but for now we choose to skip such checks.
}
}