source: src/SynTree/TupleType.cc @ 175eba6

ADTast-experimentalpthread-emulation
Last change on this file since 175eba6 was 07de76b, checked in by Peter A. Buhr <pabuhr@…>, 5 years ago

remove file TypeVar?.h* and put TypeVar::Kind into TypeDecl?, move LinkageSpec?.* from directory Parse to SynTree?

  • Property mode set to 100644
File size: 2.6 KB
Line 
1//
2// Cforall Version 1.0.0 Copyright (C) 2015 University of Waterloo
3//
4// The contents of this file are covered under the licence agreement in the
5// file "LICENCE" distributed with Cforall.
6//
7// TupleType.cc --
8//
9// Author           : Richard C. Bilson
10// Created On       : Mon May 18 07:44:20 2015
11// Last Modified By : Peter A. Buhr
12// Last Modified On : Fri Dec 13 23:44:38 2019
13// Update Count     : 4
14//
15
16#include <list>                  // for list
17#include <ostream>               // for operator<<, ostream, basic_ostream
18
19#include "Common/utility.h"      // for cloneAll, deleteAll, printAll
20#include "Declaration.h"         // for Declaration, ObjectDecl
21#include "Initializer.h"         // for ListInit
22#include "LinkageSpec.h"         // for Cforall
23#include "Type.h"                // for TupleType, Type, Type::Qualifiers
24
25class Attribute;
26
27TupleType::TupleType( const Type::Qualifiers &tq, const std::list< Type * > & types, const std::list< Attribute * > & attributes ) : Type( tq, attributes ), types( types ) {
28        for ( Type * t : *this ) {
29                // xxx - this is very awkward. TupleTypes should contain objects so that members can be named, but if they don't have an initializer node then
30                // they end up getting constructors, which end up being inserted causing problems. This happens because the object decls have to be visited so that
31                // their types are kept in sync with the types list here. Ultimately, the types list here should be eliminated and perhaps replaced with a list-view
32                // of the object types list, but I digress. The temporary solution here is to make a ListInit with maybeConstructed = false, that way even when the
33                // object is visited, it is never constructed. Ultimately, a better solution might be either:
34                // a) to separate TupleType from its declarations, into TupleDecl and Tuple{Inst?}Type, ala StructDecl and StructInstType
35                // b) separate initializer nodes better, e.g. add a MaybeConstructed node that is replaced by genInit, rather than what currently exists in a bool
36                members.push_back( new ObjectDecl( "" , Type::StorageClasses(), LinkageSpec::Cforall, nullptr, t->clone(), new ListInit( {}, {}, false ) ) );
37        }
38}
39
40TupleType::TupleType( const TupleType& other ) : Type( other ) {
41        cloneAll( other.types, types );
42        cloneAll( other.members, members );
43}
44
45TupleType::~TupleType() {
46        deleteAll( types );
47        deleteAll( members );
48}
49
50void TupleType::print( std::ostream &os, Indenter indent ) const {
51        Type::print( os, indent );
52        os << "tuple of types" << std::endl;
53        printAll( types, os, indent+1 );
54}
55
56// Local Variables: //
57// tab-width: 4 //
58// mode: c++ //
59// compile-command: "make install" //
60// End: //
Note: See TracBrowser for help on using the repository browser.