6c16aa4f67
In general all the basic functionality seems to work and removes some redundancy
and more complicated features in favor of borrowing infrastructure from LLVM
build configurations. Here's a quick summary of details and remaining issues:
* Testing has spanned Ubuntu 18.04 & 19.10, CentOS 7, RHEL 8, and
MacOS/darwin. Architectures include x86_64 and Arm. Without
access to Window nothing has been tested there yet.
* As we change file and directory naming schemes (i.e.,
capitalization) some odd things can occur on MacOS systems with
case preserving but not case senstive file system configurations.
Can be painful and certainly something to watch out for as any
any such changes continue.
* Testing infrastructure still needs to be tuned up and worked on.
Note that there do appear to be cases of some tests hanging (on
MacOS in particular). They appear unrelated to the build
process.
* Shared library configurations need testing (and probably fixing).
* Tested both standalone and 'in-mono repo' builds. Changes for
supporting the mono repo builds will require LLVM-level changes that
are straightforward when the time comes.
* The configuration contains a work-around for LLVM's C++ standard mode
passing down into Flang/F18 builds (i.e., LLVM CMake configuration would
force a -std=c++11 flag to show up in command line arguments. The
current configuration removes that automatically and is more strict in
following new CMake guidelines for enforcing C++17 mode across all the
CMake files.
* Cleaned up a lot of repetition in the command line arguments. It
is likely that more work is still needed to both allow for
customization and working around CMake defailts (or those
inherited from LLVM's configuration files). On some platforms agressive
optimization flags (e.g. -O3) can actually break builds due to the inlining
of templates in .cpp source files that then no longer are available for use
cases outside those source files (shows up as link errors). Sticking at -O2
appears to fix this. Currently this CMake configuration forces this in
release mode but at the cost of stomping on any CMake, or user customized,
settings for the release flags.
* Made the lit tests non-source directory dependent where appropriate. This is
done by configuring certain test shell files to refer to the correct paths
whether an in or out of tree build is being performed. These configured
files are output in the build directory. A %B substitution is introduced in
lit to refer to the build directory, mirroring the %S substitution for the
source directory, so that the tests can refer to the configured shell scripts.
Co-authored-by: David Truby <david.truby@arm.com>
Original-commit: flang-compiler/f18@d1c7184159
Reviewed-on: https://github.com/flang-compiler/f18/pull/1045
71 lines
2.9 KiB
Fortran
71 lines
2.9 KiB
Fortran
! RUN: %B/test/Semantics/test_errors.sh %s %flang %t
|
|
! Error tests for structure constructors.
|
|
! Errors caught by name resolution are tested elsewhere; these are the
|
|
! errors meant to be caught by expression semantic analysis, as well as
|
|
! acceptable use cases.
|
|
! Type parameters are used here to make the parses unambiguous.
|
|
! C796 (R756) The derived-type-spec shall not specify an abstract type (7.5.7).
|
|
! This refers to a derived-type-spec used in a structure constructor
|
|
|
|
module module1
|
|
type :: type1(j)
|
|
integer, kind :: j
|
|
integer :: n = 1
|
|
end type type1
|
|
type, extends(type1) :: type2(k)
|
|
integer, kind :: k
|
|
integer :: m
|
|
end type type2
|
|
type, abstract :: abstract(j)
|
|
integer, kind :: j
|
|
integer :: n
|
|
end type abstract
|
|
type :: privaten(j)
|
|
integer, kind :: j
|
|
integer, private :: n
|
|
end type privaten
|
|
contains
|
|
subroutine type1arg(x)
|
|
type(type1(0)), intent(in) :: x
|
|
end subroutine type1arg
|
|
subroutine type2arg(x)
|
|
type(type2(0,0)), intent(in) :: x
|
|
end subroutine type2arg
|
|
subroutine abstractarg(x)
|
|
class(abstract(0)), intent(in) :: x
|
|
end subroutine abstractarg
|
|
subroutine errors
|
|
call type1arg(type1(0)())
|
|
call type1arg(type1(0)(1))
|
|
call type1arg(type1(0)(n=1))
|
|
!ERROR: Type parameter 'j' may not appear as a component of a structure constructor
|
|
call type1arg(type1(0)(j=1))
|
|
!ERROR: Component 'n' conflicts with another component earlier in this structure constructor
|
|
call type1arg(type1(0)(1,n=2))
|
|
!ERROR: Value in structure constructor lacks a component name
|
|
call type1arg(type1(0)(n=1,2))
|
|
!ERROR: Component 'n' conflicts with another component earlier in this structure constructor
|
|
call type1arg(type1(0)(n=1,n=2))
|
|
!ERROR: Unexpected value in structure constructor
|
|
call type1arg(type1(0)(1,2))
|
|
call type2arg(type2(0,0)(n=1,m=2))
|
|
call type2arg(type2(0,0)(m=2))
|
|
!ERROR: Structure constructor lacks a value for component 'm'
|
|
call type2arg(type2(0,0)())
|
|
call type2arg(type2(0,0)(type1=type1(0)(n=1),m=2))
|
|
call type2arg(type2(0,0)(type1=type1(0)(),m=2))
|
|
!ERROR: Component 'type1' conflicts with another component earlier in this structure constructor
|
|
call type2arg(type2(0,0)(n=1,type1=type1(0)(n=2),m=3))
|
|
!ERROR: Component 'n' conflicts with another component earlier in this structure constructor
|
|
call type2arg(type2(0,0)(type1=type1(0)(n=1),n=2,m=3))
|
|
!ERROR: Component 'n' conflicts with another component earlier in this structure constructor
|
|
call type2arg(type2(0,0)(type1=type1(0)(1),n=2,m=3))
|
|
!ERROR: Type parameter 'j' may not appear as a component of a structure constructor
|
|
call type2arg(type2(0,0)(j=1, &
|
|
!ERROR: Type parameter 'k' may not appear as a component of a structure constructor
|
|
k=2,m=3))
|
|
!ERROR: ABSTRACT derived type 'abstract' may not be used in a structure constructor
|
|
call abstractarg(abstract(0)(n=1))
|
|
end subroutine errors
|
|
end module module1
|