/[eiffelstudio]/branches/eth/eve/Src/Eiffel/API/evaluated_type/none_a.e
ViewVC logotype

Annotation of /branches/eth/eve/Src/Eiffel/API/evaluated_type/none_a.e

Parent Directory Parent Directory | Revision Log Revision Log


Revision 72419 - (hide annotations)
Sat Feb 23 00:45:27 2008 UTC (11 years, 11 months ago) by manus
Original Path: trunk/Src/Eiffel/API/evaluated_type/none_a.e
File size: 3977 byte(s)
Changed SUPPLIER_AS to only create the supplier on demands.

Merged TYPE_I and TYPE_A hierarchies in just TYPE_A one.
1-The major change is that now to compute the associated class type (CLASS_TYPE instance) of a TYPE_A
  one has to provide a context in which the TYPE_A instance appear. If no context is provided, then
  formal generics are not replaced. For example: LIST [G] alone will simply give you the LIST [G]
  CLASS_TYPE, but if you do it in the context of TEST [INTEGER], then it will return the
  LIST [INTEGER] CLASS_TYPE.
2-Updated all callers accordingly.
3-Simplified a few calls where before we did `type.associated_class_type.associated_class' to just
  `type.associated_class'.
4-Added new preconditions to the context provided, it really helped finding out when we were not doing
  things properly especially in code generation when regenerating code from parent into descendant.
5-Eventhough TYPE_I disappeared, I kept TYPE_C and its descendants since they are useful to have
  them for C code generation and quick discimination for TYPE_A instances.
6-Made validity of types better controled by checking more things in `{TYPE_A}.is_valid'. For example
  that if type used to represent a class which was expanded and that it is not expanded anymore, then
  the type is not valid anymore.
7-The most problematic change with TYPE_I/TYPE_A was that they had different notion of `is_external'
  we have added `is_true_external' to simplify the code in certain areas where the old TYPE_I semantic
  was needed.

Code generation change:
1-We now assume that the default context is always `{BYTE_CONTEXT}.context_class_type'. Then in
  `real_type' and `creation_type' we use `{TYPE_A}.evaluated_type_in_descendant' to properly evaluate
  a type from the ancestor code in the current context. Very useful for regeneration of inherited
  assertions and replicated features. Before it worked, but it was not clear how to do things properly,
  now it is clear.
2-Changed the way we generate the type information for like arguments: we simply nest calls to resolve
  the type of the arguments. This affects the interpreter and C code generation which includes a level
  ID for computing the type of generics.

C Code generation change:
1-Because debugging was too difficult at some point during that work and also because the name mapping
  we were using limited us to 32767 types and 131071 routines, I've changed the mechanism to not use
  the `encode.c' modules in C/bench and did everything in Eiffel. So now we simply write for a feature
  name FXXX_YYY where XXX is the type ID and YYY the body index. The same kind of changes have been
  done for other names (See ENCODER class for details.).
2-We also use `type_id' instead of `static_type_id' for names. The reason it is safe to do so is because
  `type_id' never changes in workbench mode and that in finalized mode, even if you have different
  incremental recompilation, 2 projects should generate more or less the same code at the ID levels
  making it easier to compare them.
3-Changed the way type are created. Instead of having a CREATE_INFO instance in the TYPE_I objects
  used to properly generate the type, we simply use the original TYPE_A instance. That way when we
  have an anchor, we either generate its `actual_type' or its anchor spec depending on the value of
  `use_info. We still use CREATE_INFO to generate the type information but instead of being an object
  in each TYPE_I, it is merely a once that we reinitialize each time we need it.
4-ONE CRITICAL ASPECT OF THE CHANGE #3 was that storable depends on the way type descriptions are generated
  and thanks to eweasel test#storable013 I was able to catch this much earlier in the process.
5-Generates less polymorphic tables for attributes and types specification. What happened before was
  that when we needed a polymorphic type specification for example to create `like x' where x is covariantly
  redefined, we were generating at the same time the polymorphic table for `x' even though if `x'
  was not actually used in the system. This reduces by a tiny amount only the size of the executable.
6-Made the DESCRIPTOR entries much smaller than they used to be by computing the number of ancestors
  instead of allocating for the numbers of routines which was really silly.

IL code generation change:
1-Provided a implementation for creation of BIT constants in .NET however it does not completely work yet,
  it has to do with the manner we generate the BIT_REF class.
2-Changed the way we compare signatures, we store a CLASS_TYPE and a routine ID instead. And then when
  needed we refetch the FEATURE_I object to perform the signature comparions. The issue is that the previous
  solution would not work if NATIVE_ARRAY and TYPED_POINTER do not record all the possible genereric
  derivations in which they are present which is now the case for simplicity.
3-Fixed a bug in code generation for a TYPE_FEATURE_I that is instantiated as a basic type. We would
  generate its associated reference type instead of the basic type. It was not caught before because those
  routines where never called at runtime unless you had a formal generic parameter creation constraint.
4-Fixed an inconsistency shown by eweasel test#incr168 where a precondition check was generated eventhough
  none was needed because one inherited routine had a True precondition. The C code was doing it ok, but
  not .NET
5-Found out see eweasel test#final041 that we first generate inherited assertion and then precondition,
  which is the contrary of what is done in melted or C code generation.
6-Simplified creation of manifest ARRAYS and TUPLE by avoiding a local variable.


Debugger:
1-Updated the code accordingly to the TYPE_I/TYPE_A merge
2-Fixed bug in {DBG_EVALUATOR}.prepare_parameters so that we do not use BYTE_CONTEXT to resolve
  the type but `instantiation_in' instead. It seems to solve one case that the previous debugger did
  not handle (See updated comment).
3-Fixed precondition violation in
  {AST_DEBUGGER_EXPRESSION_CHECKER_GENERATOR}.expression_or_instruction_type_check_and_code where
  we were still trying to evaluate in the descendant if the parent evaluation failed. Causing some
  precondition violations since the AST was not completely annotated with IDs needed for resolution.

Bug fixes:
1-Fixed issue with the way we maintained {CLASS_C}.generic_features, because you could rebuild the list
  without recompiling descendants (case of modifying only a contract of the class) and the rebuilding
  would yield new routine IDs. Then during either type checking or code generation the evaluation of 
  `{TYPE_A}.evaluate_type_in_descendant' could fail because it is not find the new routine ID in the
  descendant class. Now we preserve the routine ID as long as we can, same with feature ID.
2-Made `feature_of_rout_id' works to find the invariant feature.
3-Made sure that when removing an ID from a server it is also removed from the TMP server. Added
  a `not_present' postcondition after calling `remove' to ensure that.

1 dinov 3375 indexing
2 manus 27398 description: "Actual type for NONE."
3 manus 56535 legal: "See notice at end of class."
4     status: "See notice at end of class."
5 manus 9656 date: "$Date$"
6 manus 27398 revision: "$Revision$"
7 dinov 3375
8 manus 9656 class
9     NONE_A
10 grator 18
11     inherit
12 manus 9656 TYPE_A
13 grator 18 redefine
14 manus 72419 is_none, dump, c_type, same_as, is_full_named_type, generated_id,
15     generate_gen_type_il, make_gen_type_byte_code
16 grator 18 end
17    
18 manus 57234 feature -- Visitor
19    
20     process (v: TYPE_A_VISITOR) is
21     -- Process current element.
22     do
23     v.process_none_a (Current)
24     end
25    
26 manus 9656 feature -- Comparison
27    
28     is_equivalent (other: like Current): BOOLEAN is
29     -- Is `other' equivalent to the current object ?
30     do
31     Result := True
32     end
33    
34 dinov 3078 feature -- Properties
35 grator 18
36 manus 9656 is_none: BOOLEAN is True
37 grator 18 -- Is the current type a none type ?
38    
39 manus 44539 is_full_named_type: BOOLEAN is True
40     -- Current is a full named type.
41    
42 dinov 3180 feature -- Access
43    
44 manus 72419 hash_code: INTEGER is
45     -- Hash code for current type
46     do
47     Result := {SHARED_HASH_CODE}.none_code
48     end
49    
50 dinov 3180 same_as (other: TYPE_A): BOOLEAN is
51     -- Is the current type the same as `other' ?
52     do
53 manus 9656 Result := other.is_none
54     end
55 dinov 3180
56 manus 11302 associated_class: CLASS_C is
57     do
58     -- No associated class
59     end
60    
61 dinov 3078 feature -- Output
62    
63 manus 9656 dump: STRING is "NONE"
64 grator 18 -- Dumped trace
65    
66 martins 67227 ext_append_to (st: TEXT_FORMATTER; c: CLASS_C) is
67 grator 296 do
68 manus 72419 st.add ({SHARED_TEXT_ITEMS}.ti_none_class)
69 manus 9656 end
70 grator 296
71 manus 72419 feature -- Generic conformance
72    
73     generated_id (final_mode: BOOLEAN; a_context_type: TYPE_A): NATURAL_16 is
74     -- Id of a `like xxx'.
75     do
76     Result := {SHARED_GEN_CONF_LEVEL}.none_type
77     end
78    
79     make_gen_type_byte_code (ba: BYTE_ARRAY; use_info : BOOLEAN; a_context_type: TYPE_A) is
80     -- Put type id's in byte array.
81     -- `use_info' is true iff we generate code for a
82     -- creation instruction.
83     do
84     ba.append_natural_16 ({SHARED_GEN_CONF_LEVEL}.none_type)
85     end
86    
87     feature -- IL code generation
88    
89     generate_gen_type_il (il_generator: IL_CODE_GENERATOR; use_info: BOOLEAN) is
90     -- `use_info' is true iff we generate code for a
91     -- creation instruction.
92     do
93     il_generator.generate_none_type_instance
94     end
95    
96 dinov 3180 feature {COMPILER_EXPORTER}
97 dinov 3078
98 manus 9656 create_info: CREATE_TYPE is
99     -- Byte code information for entity type creation
100     do
101 manus 72419 create Result.make (Current)
102 manus 9656 end
103    
104 manus 72419 c_type: REFERENCE_I is
105 grator 18 -- Void C type
106 manus 72419 do
107     Result := reference_c_type
108 manus 9656 end
109 grator 18
110 manus 41740 conform_to (other: TYPE_A): BOOLEAN is
111     -- Does Current conform to `other'?
112 manus 48130 local
113     l_type: TYPE_A
114 grator 18 do
115 alexk 70996 -- If `other' is attached, then NONE does not conform to it.
116 manus 48130 -- But it should not be `VOID_A' since VOID_A is only used as
117     -- return type for procedure
118 alexk 55786 l_type := other.conformance_type
119 alexk 70996 Result := not l_type.is_expanded and not l_type.is_void and then not l_type.is_attached
120 manus 9656 end
121 grator 18
122 manus 56535 indexing
123     copyright: "Copyright (c) 1984-2006, Eiffel Software"
124 manus 58027 license: "GPL version 2 (see http://www.eiffel.com/licensing/gpl.txt)"
125 manus 56535 licensing_options: "http://www.eiffel.com/licensing"
126     copying: "[
127     This file is part of Eiffel Software's Eiffel Development Environment.
128 manus 58027
129 manus 56535 Eiffel Software's Eiffel Development Environment is free
130     software; you can redistribute it and/or modify it under
131     the terms of the GNU General Public License as published
132     by the Free Software Foundation, version 2 of the License
133     (available at the URL listed under "license" above).
134 manus 58027
135 manus 56535 Eiffel Software's Eiffel Development Environment is
136     distributed in the hope that it will be useful, but
137     WITHOUT ANY WARRANTY; without even the implied warranty
138     of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
139     See the GNU General Public License for more details.
140 manus 58027
141 manus 56535 You should have received a copy of the GNU General Public
142     License along with Eiffel Software's Eiffel Development
143     Environment; if not, write to the Free Software Foundation,
144     Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
145     ]"
146     source: "[
147     Eiffel Software
148     356 Storke Road, Goleta, CA 93117 USA
149     Telephone 805-685-1006, Fax 805-685-6869
150     Website http://www.eiffel.com
151     Customer support http://support.eiffel.com
152     ]"
153    
154 dinov 3375 end -- class NONE_A

Properties

Name Value
svn:eol-style native
svn:keywords Author Date Id Revision

  ViewVC Help
Powered by ViewVC 1.1.23