mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-08 07:42:33 +01:00
Code Issues Packages Projects Releases Wiki Activity

create 19.12 branch

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2229 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
2019-12-28 20:04:57 +00:00
parent 4e06893808
commit 8ce4fd738c
2943 changed files with 62386 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/VD81.wiki Normal file
View File

@@ -0,0 +1,6 @@
[[Property:modification_date|Wed, 24 Apr 2019 12:32:11 GMT]]
[[Property:publication_date|Wed, 24 Apr 2019 12:32:11 GMT]]
[[Property:uuid|996CC0DA-B3E9-4555-A121-BAB15C9BEC81]]
[[Property:weight|0]]
[[Property:title|VD81]]
In EiffelStudio [[/doc/uuid/4452B417-C538-49AF-960F-C3C2473A3AF8|18.11]] and earlier, comparison of real numbers could be controlled by the setting "Total Order on REALs".

27
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/VWMA--1-.wiki Normal file
View File

@@ -0,0 +1,27 @@
[[Property:modification_date|Mon, 19 Nov 2018 16:49:36 GMT]]
[[Property:publication_date|Fri, 06 Jul 2018 13:19:54 GMT]]
[[Property:uuid|26E32CD7-7C68-4CDD-A29A-81343EC0DD3B]]
[[Property:weight|0]]
[[Property:title|VWMA(1)]]
[[Property:link_title|VWMA(1)]]
In legacy code, before EiffelStudio [[/doc/uuid/73F20392-AB22-4CD6-BFE5-83296B8BD64B|18.07]], the target of a reattachment could be used to determine the type of a manifest array. For example, with the declaration
```eiffel
x: ARRAY [READABLE_STRING_GENERAL]
```
the reattachment
```eiffel
x := <<"abc", "def">>
```
led to creation of an array of type <eiffel>ARRAY [READABLE_STRING_GENERAL]</eiffel> with elements <eiffel>"abc"</eiffel> and <eiffel>"def"</eiffel> of type <eiffel>STRING_8</eiffel>.
In Eiffel, manifest arrays were the only expressions whose type depended on the type of the target. Starting from EiffelStudio [[/doc/uuid/61F63EE2-58B1-4061-927B-35D4F66EDD9B|18.01]] this is no longer the case, and, by default, the type of a manifest array does not depend on the context where the manifest array is used.
Taking the rules into account, the type of the manifest array object from the example above is <eiffel>ARRAY [STRING_8]</eiffel>.
For projects that were developed before EiffelStudio [[/doc/uuid/61F63EE2-58B1-4061-927B-35D4F66EDD9B|18.01]], the compiler checks whether a computed manifest array type is the same as the type of the target of reattachment and reports the warning {{Inline-Warning|VWMA(1)}} to simplify adaptation of legacy code to the new semantics. If the old semantics has to be preserved, an explicit manifest array type has to be used, for example:
```eiffel
x := {ARRAY [READABLE_STRING_GENERAL]} <<"abc", "def">>
```
The code above would have the behavior identical to the behavior of projects created by the versions before EiffelStudio [[/doc/uuid/61F63EE2-58B1-4061-927B-35D4F66EDD9B|18.01]].
After updating all code to follow the standard rules, the project option '''Manifest array type''' can be set to '''standard''' to switch to the standard behavior and to disable comparing types of a manifest array and the target of the attachment. To make sure all occurrences of reattachment of manifest arrays to targets of non-matching types are fixed, the option can also be set to '''mismatch error'''. That would trigger errors instead of warnings for manifest array type mismatches.

5
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/index.wiki Normal file
View File

@@ -0,0 +1,5 @@
[[Property:modification_date|Thu, 05 Jul 2018 16:23:57 GMT]]
[[Property:publication_date|Thu, 05 Jul 2018 16:23:57 GMT]]
[[Property:uuid|D7B6372C-C63E-441A-BD5C-4E74387C9561]]
[[Property:weight|0]]
[[Property:title|Legacy code]]

9
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/index.wiki Normal file
View File

@@ -0,0 +1,9 @@
[[Property:modification_date|Thu, 05 Jul 2018 16:23:17 GMT]]
[[Property:publication_date|Thu, 05 Jul 2018 16:22:54 GMT]]
[[Property:uuid|2C8A219A-D88E-4E7C-8F48-AC3C641C81E7]]
[[Property:weight|50]]
[[Property:title|Errors and warnings]]
[[Property:link_title|Errors, warnings]]
For some error or warning, you will find an English description of the purpose of the error (or warning).
In addition you may find an example that reproduces the error (or warning) as well as a suggested fix when available.

168
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/Eiffel-compatibility-options.wiki Normal file
View File

@@ -0,0 +1,168 @@
[[Property:weight|0]]
[[Property:title|Eiffel compatibility options]]
[[Property:uuid|66673f5d-bc21-563a-b228-e663ea1326f5]]
=Introduction=
Over the course of several releases, Eiffel Software has introduced a number of options and settings which allow users of EiffelStudio and the Eiffel command line compiler to choose the appropriate level of forward progress and/or backward compatibility for a particular application.
This is a summary of the motivation behind and the meanings of the various compatibility options.
=Quick guide to project settings affecting compatibility with older Eiffel code=
The table below shows project settings that, depending upon their values, can affect the compilation of Eiffel code produced under older standards. That is, certain values for some of these settings may cause older code to fail to compile due to non-compliance. However, other values may allow you to compile non-compliant code during a period in which you convert that code to the current Eiffel implementation.
{| border="2" style="border-collapse: collapse; border-style: solid;"
|+
|-
! style="text-align: center; valign: center;" | Setting
! style="text-align: center; valign: center;" | Allowable values
! style="text-align: center; valign: center;" | Meaning
! style="text-align: center; valign: center;" | Default value in version:
|-
| colspan="4" style="background: #E8E8E8" |
|-
| rowspan="5" style="text-align: center" | [[Setting the syntax variant|Syntax]]
|-
| [[Syntax level variant settings by version|Obsolete syntax]]
| Favor obsolete syntax over standard.
| [[Release notes for EiffelStudio 6.3 | 6.3]], [[Release notes for EiffelStudio 6.4 | 6.4]]
|-
| [[Syntax level variant settings by version|Transitional syntax]]
| Favor standard syntax, but allow obsolete syntax when determinable by context.
| [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]]
|-
| [[Syntax level variant settings by version|Standard syntax]]
| Enforce current standard syntax.
| [[Release notes for EiffelStudio 7.0 | 7.0]] and [[EiffelStudio release notes | more recent]]
|-
| [[Syntax level variant settings by version|Provisional syntax]]
| Like Transitional syntax, but also allow not-yet-approved constructs.
|
|-
| colspan="4" style="background: #E8E8E8" |
|-
| rowspan="3" style="text-align: center" | [[Creating a new void-safe project#Project settings for void-safe projects|Full class checking]]
|-
| True
| Features of parent classes are rechecked for validity in heir classes.
| [[Release notes for EiffelStudio 7.3 | 7.3]] and [[EiffelStudio release notes | more recent]]
|-
| False
| No recheck performed.
| [[Release notes for EiffelStudio 7.2 | 7.2]], [[Release notes for EiffelStudio 7.1 | 7.1]], [[Release notes for EiffelStudio 7.0 | 7.0]], [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]]
|-
| colspan="4" style="background: #E8E8E8" |
|-
| rowspan="3" style="text-align: center" | [[Creating a new void-safe project#Project settings for void-safe projects|Are types attached by default?]]
|-
| True
| <code>x: T</code> is treated like <code>x: attached T</code>
| [[Release notes for EiffelStudio 7.0 | 7.0]] and [[EiffelStudio release notes | more recent]]
|-
| False
| <code>x: T</code> is treated like <code>x: detachable T</code>
| [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]]
|-
| colspan="4" style="background: #E8E8E8" |
|-
| rowspan="6" style="text-align: center" | [[Creating a new void-safe project#Project settings for void-safe projects|Void-safety]]
|-
| No
| No checking against any void-safety validity rules.
| [[Release notes for EiffelStudio 7.2 | 7.2]], [[Release notes for EiffelStudio 7.1 | 7.1]], [[Release notes for EiffelStudio 7.0 | 7.0]], [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]]
|-
| Conformance
| The attachment marks are not ignored for type conformance checks (with respect to VJAR/VBAR and related validity rules).
|
|-
| Initialization
| Validity rules are selectively checked. The initialization rule (VEVI) and the target rule (VUTA) are checked only for attached entities and attached call targets -- i.e., detachable cases are not checked.
|
|-
| Transitional
| Checking against all void-safety validity rules using some potentially unsafe CAPs, assuming that all assertions are satisfied, and ignoring some complex cases like passing incompletely initialized Current from a creation procedure or creating agents when Current is not completely initialized.
| [[Release notes for EiffelStudio 13.11 | 13.11]], [[Release notes for EiffelStudio 7.3 | 7.3]]
|-
| Complete
| Complete checking against all void-safety validity rules ignoring any unsafe CAPs.
| [[Release notes for EiffelStudio 14.05 | 14.05]] and [[EiffelStudio release notes | more recent]]
|}
=Discussion of compatibility issues=
==Eiffel Software and the wheels of progress==
The Eiffel analysis, design, and programming language has remained relatively static since its original specification in the mid-1980's. However, periodically it has become necessary to make certain changes in order to make certain language improvements and to enable new facilities. It is the policy of Eiffel Software, when such changes are made, to ensure that the changes have minimum impact upon existing software. For some changes, that means no impact at all, but for others it means that the new Eiffel is incompatible with the old Eiffel (the so-called "breaking changes" … those changes that break existing code). And that means that existing software will have to be changed to take advantage of the recent changes to Eiffel. Even so, Eiffel Software has been able to ease the transition from old to new by implementing certain compatibility options which allow existing software still to run as in previous versions during periods of transition.
==Sources of changes==
The Eiffel programming language is standardized under the [http://www.iso.org/iso/catalogue_detail.htm?csnumber=42924 ISO] and [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA] standardization organizations. So, it is not surprising that many of the changes that are implemented by Eiffel Software are driven by the work of the Eiffel standardization committee.
Still, the standard itself is a moving target, and there are always differences between what is in the current standard and what has been implemented by Eiffel Software. Also, only immediately after publication of the standard might there be complete agreement between the standard document itself and the perception of Eiffel by the standard committee. That is to say that a new version of the standard may be published once every few years, but the process of moving the language forward continues in the committee in the meantime.
The diagram below attempts to characterize the relationship among the various factors that define Eiffel.
[[Image:Eiffel implementation venn diagram]]
It is easy to see the overlapping areas. The centermost represents that part of Eiffel that is at once implemented by Eiffel Software, exists in the current published version of the standard, and is anticipated to remain in the standard for the next version.
The other areas represent Eiffel features that are supported by only one or a combination of two of these factors.
==Types of changes==
There are many different types of changes that can effect existing code. Here are some examples of these.
# '''Changes to the Eiffel library classes'''
## Removal or obsoleting of classes or features. Example: <code>{SPECIAL}.make</code> is removed as void-unsafe.
## Changing conformance. Example: <code>ARRAYED_LIST</code> no longer conforms to <code>ARRAY</code>.
## Changing feature types. Example: <code>{ARRAYED_LIST}.count</code> and <code>{ARRAYED_LIST}.area</code> were changed from attributes to functions.
# '''Language keyword changes'''
## A word that was once a keyword is no longer a keyword (potentially allowing the word to be used as an identifier, and affecting software using it as a keyword). Example: <code>indexing</code> is no longer a keyword.
## A word that was not a language keyword in previous versions, becomes one in the current version (potentially breaking any code that used that word as an identifier). Example: <code>attached</code>
## A keyword (or notation) used in a particular context is retired from that context in favor of a more appropriate keyword. (potentially affecting all software using the old keyword in that context). Example: <code>indexing</code> is retired in favor of <code>note</code>.
## The usage of an existing keyword in a new context (usually has no effect on existing software). Example: <code>as</code> used in <code>attached</code> syntax for object test (in addition to its traditional role in the <code>rename</code> part of the <code>inherit</code> clause.)
# '''Language construct changes'''
## Addition of new constructs or extensions to existing constructs. Example: [[ET: Instructions#Loop|iteration form]] of the loop construct.
## Changes to existing constructs. Example: Object test syntax change: <code>attached {T} expr as u</code> versus <code>{u: T} expr</code>
## Removal of obsolete constructs.
==Types of compatibility options==
===EiffelStudio and Eiffel compiler options===
These "mode" options are selected when EiffelStudio is started up or when the command line Eiffel compiler is invoked. The following two mode options were introduced in version 6.3 on the eve of implementing [[Void-safe programming in Eiffel|void-safety]] as an integral feature of Eiffel. The mode options were intended to help developers deal with the [[Void-safe changes to Eiffel libraries|changes to the Eiffel libraries for void-safety]].
* '''-compat''' runs EiffelStudio or the Eiffel compiler in "compatibility mode" so that compilation will use libraries that are compatible with older versions of Eiffel.
* '''-experiment''' runs EiffelStudio or the Eiffel compiler in "experimental mode" so that compilation will use libraries based on an upcoming version of Eiffel.
Implicit here is that there is also a "default" mode which is invoked when neither of compatibility nor experimental mode is used. Default mode assumes a "current" set of libraries.
Also, implied by these modes is a progression of their meanings over time. That is, as time passes and language changes are reflected in Eiffel Software's products, the "experimental" mode of today will likely be the "default" mode of tomorrow. And the "default" mode of today may become the "compatible" mode of tomorrow.
===Project settings===
These options are set in the EiffelStudio Project Settings dialog box.
The most important of these is the '''[[Setting the syntax variant|Syntax]]''' level variant setting. You can choose among a set of syntax level variants that let you control how the compiler views certain language changes. So, for example, if you are compiling classes that contain obsolete keywords, you would set the '''Syntax''' setting to the '''Obsolete syntax''' variant.
Bear in mind that the detail meanings of the various syntax variants may change from version to version. So, it's a good idea periodically to check the [[Syntax level variant settings by version|syntax level variant settings by version]].
==Compatibility tools==
===The syntax updater===
The syntax updater is located in the EiffelStudio "tools" folder. It is a command line utility that will update certain syntax elements from obsolete syntax to current syntax. The syntax updater was introduced with EiffelStudio version 6.4.
The tool makes the following updates to existing code:
# Replaces obsolete "<code>!!</code>" syntax with <code>create</code> keyword syntax.
# Replaces obsolete keyword <code>creation</code> with <code>create</code>.
# Removes obsolete keyword <code>is</code> after routine signatures.
# Replaces obsolete keyword <code>is</code> in constants with "<code>=</code>" (e. g., "<code>i: INTEGER is 5</code>" becomes <code>i: INTEGER = 5"</code>).
# Replaces obsolete keyword <code>indexing</code> with <code>note</code>.
# Replaces the June 2006 Standard object test syntax (e. g., "<code>{x: T} exp</code>") with the committee-approved provisional standard syntax (e. g., "<code>attached {T} exp as x</code>").
# Replaces obsolete non-object feature call syntax with current syntax (e. g., "<code>feature {X}.f</code>" becomes "<code>{X}.f</code>").
# Replaces attached and detachable type markers from June 2006 Standard with committee-approved provisional standard syntax (e. g., "<code>x: !T</code>" becomes "<code>x: attached T</code>" and "<code>x: ?T</code>" becomes "<code>x: detachable T</code>").

47
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki Normal file
View File

@@ -0,0 +1,47 @@
[[Property:title|Batch compilation]]
[[Property:weight|2]]
[[Property:uuid|18958db6-dafc-57b7-cdef-aca01bc13661]]
In order to launch a compilation without user intervention you need to specify the `-batch` switch in the '''ec''' command line, otherwise the Eiffel compilation will be blocked. We will present below a typical example of batch processing on both Unix and Windows platforms where we want to compile a project in both frozen and finalized mode, then to launch the C compilations. At the same time we want to save the output of '''ec''' and the C compilations.
===Unix===
In a file called `launch_ec` you can have the following:
<code lang=text>
#!/bin/sh
output_file="/output_path/OUTPUT"
cd /your_project_path
#Launch Eiffel compilation
ec -batch -config config.ecf -finalize -c_compile 2> $output_file
#Since only C compilation for finalized code is done
#Launch C compilation for frozen code
cd EIFGENs/target_name/W_code
finish_freezing > $output_file</code>
It will go the directory where your project is located and compile your Eiffel code using the `config.ecf` file located in your project directory and compile automatically the C code. All outputs will be stored in the file `/output_path/OUTPUT`.
{{note|All output from '''ec''' are going to the error output, so do not forget to redirect the error output when you want to see the result. }}
===Windows===
In a file called `launched_ec.bat` you can have the following:
<code lang=text>
rem Launch Eiffel compilation
ec -batch -config config.ecf -finalize -c_compile > c:\output_path\OUTPUT
rem Since only C compilation for finalized code is done
rem Launch C compilation for frozen code
cd EIFGENs\target_name\W_code
finish_freezing > c:\output_path\OUTPUT</code>
It will go the directory where your project is located and compile your Eiffel code using the `config.ecf` file located in your project directory and compile automatically the C code. All outputs will be stored in the file `c:\output_path/OUTPUT`.
{{seealso|<br/>
[[EiffelStudio: Using command line options|Using command line compiler options]] }}

72
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki Normal file
View File

@@ -0,0 +1,72 @@
[[Property:title|Class menu]]
[[Property:weight|2]]
[[Property:uuid|441d6cbb-2c48-5d44-8cb1-0884ade26b98]]
The Class command (c or C) in the main menu will only work if the system has been successfully compiled, and will give you information based on the result of the last successful compilation. It produces the following menu:
<code lang=text>
(A) Ancestors : show the ancestors of a class.
(B) Attributes : show the attributes of a class.
(C) Clients : show the clients of a class.
(E) Deferred : show the deferred features of a class.
(D) Descendants : show the descendants of a class.
(V) Edit : edit the text of a class.
(P) Exported : show the exported features of a class.
(X) Externals : show the external features of a class.
(F) Flat : show the flat form of a class.
(I) Flatshort : show the flat-short form of a class.
(O) Once : show the once & constant features of a class.
(R) Routines : show the routines of a class.
(S) Short : show the short form of a class.
(U) Suppliers : show the suppliers of a class.
(T) Text : show the text of a class.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
Each command will prompt you for the name of a class and a filter to use; you can also include the class name and the filter name after the command, separated by a space, as in:
<code>
Command => a linked_list ascii</code>
to obtain the ancestors of the <eiffel>LINKED_LIST</eiffel> class:
<code>
-- Automatic generation produced by ISE Eiffel --
LINKED_LIST [G]
DYNAMIC_LIST [G]
LIST [G]
CHAIN [G]
CURSOR_STRUCTURE [G]
ACTIVE [G]
BAG [G]
COLLECTION [G]
CONTAINER [G]
ANY
INDEXABLE [G, H -> INTEGER]
TABLE [G, H]
BAG [G]...
SEQUENCE [G]
ACTIVE [G]...
BILINEAR [G]
LINEAR [G]
TRAVERSABLE [G]
CONTAINER [G]...
LINEAR [G]...
FINITE [G]
BOX [G]
CONTAINER [G]...
SEQUENCE [G]...
DYNAMIC_CHAIN [G]
CHAIN [G]...
UNBOUNDED [G]
FINITE [G]...
DYNAMIC_CHAIN [G]...
-- Generated by ISE Eiffel --
-- For more details: http://www.eiffel.com --
Command =></code>

29
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki Normal file
View File

@@ -0,0 +1,29 @@
[[Property:title|Compile (and run) menu]]
[[Property:weight|1]]
[[Property:uuid|58af783e-7fc4-9fa3-2374-4143204948bb]]
The Compile command (i or I) in the main menu yields the following item menu:
<code lang=text>
(A) Arguments : set the arguments.
(C) F-compile : (re)compile the C code generated by finalize.
(Z) Finalize : finalize the system (discard assertions by default).
(F) Freeze : freeze the system.
(L) Melt : melt the system.
(K) Quick melt : quick melt the system.
(R) Run : execute the system.
(W) W-compile : (re)compile the C code generated by freeze.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
The most common compiling option is L (Melt): recompile the system, melting recent changes. The other compilation possibilities are F (Freeze) and Z (Finalize). After a Freeze you will need to C-compile the result using the W (W-compile) command; similarly, you can C-compile the result of a Finalize using C (F-compile).
{{caution|You cannot select a different project from within ec loop; also, you cannot select a different configuration file from within the command, although you may of course change the contents of the configuration file (for example by using an editor in an other window). }}
The R option (Run) runs the application. You will be prompted for the arguments if the application needs any.

21
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki Normal file
View File

@@ -0,0 +1,21 @@
[[Property:title|Documentation menu]]
[[Property:weight|7]]
[[Property:uuid|4ed93bc4-07eb-57ed-b339-4890b5f58fcc]]
The Documentation Menu enables you to generate documentation about the classes of your system:
<code lang=text>
(I) Documentation (Flat/Short): Generate flat/short form of all classes in system.
(S) Documentation (Short): Generate short form of all classes in system.
(F) Documentation (Flat): Generate flat form of all classes in system.
(T) Documentation (Text): Generate text form of all classes in system.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
The four documentation commands will trigger the creation of documentation files corresponding to requested information using the specified filter. These files will then be located in the Documentation subdirectory of your project directory.

45
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki Normal file
View File

@@ -0,0 +1,45 @@
[[Property:title|Feature menu]]
[[Property:weight|3]]
[[Property:uuid|a662251b-777d-5e28-0e52-ba4932195528]]
The Feature Menu enables you to find properties of a feature:
<code lang=text>
(A) Ancestors : show the ancestor versions of a feature.
(C) Callers : show the callers of a feature.
(D) Descendants : show the descendant versions of a feature.
(F) Flat : show the flat form of a feature.
(O) Homonyms : shown the homonyms of a feature.
(I) Implementers : show the classes implementing a feature.
(T) Text : show the text of a feature.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
Each command will prompt you for the name of a class, the name of a feature in that class and a filter name; you can specify these names (or just the class name) after the command.
{| border="1"
|-
| <center>'''Command'''</center>
| <center>'''Description'''</center>
|-
| <code>Ancestors</code>
| All the versions of a feature that appeared in ancestors.
|-
| <code>Callers</code>
| The list of classes which contains calls to the feature. Modifiers:
* <code>All senders</code> - include all callers rather than only those in the specified class
* <code>Only assigners</code> - restrict callers to those that use given feature only as a target of an assignment instruction
* <code>Only creators</code> - restrict callers to those that use given feature only as a target of a creation instruction
|-
| <code>Descendants</code>
| All the versions of a feature that appeared in descendants.
|-
| <code>Implementers</code>
| The list of classes where the feature is redeclared.
|}

25
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki Normal file
View File

@@ -0,0 +1,25 @@
[[Property:title|Command line interactive mode]]
[[Property:weight|3]]
[[Property:uuid|3a0acea6-c6d1-c7b9-c2f9-88021cad26b6]]
If you need to use '''ec''' to execute a number of successive operations on a system, you do not need to restart the command each time; instead you may use the '''-loop''' option, which will interactively prompt you for successive operations.
If you launch '''ec''' with this option, you will get the interactive version's Main Menu:
<code lang=text>
==== ISE EiffelStudio - Interactive Batch Version (v5.5.0926 Enterprise Edition) ===
(C) Class : class formats and information.
(I) Compile : compile or run the system.
(F) Feature : feature formats and information.
(S) System : Config and cluster details.
(T) Testing : manage and run tests.
(P) Profile : information about a profiled run.
(D) Documentation: create documents from the system.
(H) Help : show list of commands.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
Command =></code>
<br/>
The revision number in the first line may be different in your case to indicate that you have a more recent delivery. In this menu, and in all subsequent ones, the commands appear in two groups.
* commands in the first group are specific to each menu
* commands in the second group H (Help) to repeat the list of choices, Y (Yank) to save the output of the last command to a file that you will be prompted to name, and Q (Quit) to quit appear in all menus, and will be complemented in the Item Menus below by the M (Main) command which returns to the main menu.
By typing one of the letters shown in the Main Menu's first group, you can go to one of the Item Menus: [[Class menu|Class]], [[Compile (and run) menu|Compile]], [[Feature menu|Feature]], [[System menu|System]], [[Profile menu|Profile]], and [[Documentation menu|Documentation]]. [[Compile (and run) menu|Compile]] enables you to compile a system and execute the result; the next three enable you to obtain information about your project. [[Profile menu|Profile]] will enable you to exploit profiling information. Finally, [[Documentation menu|Documentation]] will enable you to generate HTML documentation about your project.

167
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki Normal file
View File

@@ -0,0 +1,167 @@
[[Property:title|Profile menu]]
[[Property:weight|6]]
[[Property:uuid|09c424b0-8ba1-626c-0658-32e5d5e1f81b]]
An execution of an instrumented system will generate a file that contains profiling information. This file (named profinfo) is located in the same directory as your compiled system. You must process it through a profile converter to produce the Execution Profile.
The profile menu will enable you to produce the Execution profile and to extract information from it.
The menu (obtained by selecting (P) Profile in the main menu) looks like this:
<code lang=text>
(S) Switches : show the output switches
#Call-E Name-E Total-D
Self-D Desc-D %Time-D.
(U) Query : manipulate subqueries.
(I) Input : specify input file (filename or last_output)
[*.pfi].
(L) Language : specify language (eiffel, c, cycles)
[eiffel].
(R) Run : run the query.
(G) Generate : generate profile information for latest run.
(E) Defaults : reset all values to their defaults.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
==Switches submenu==
The (S) Switches submenu enables you to set global options. It leads you to the following set of choices:
<code lang=text>
(N) Calls : disable output of number of calls to a feature [enabled].
(F) Feature name : disable output of feature names [enabled].
(T) Total : enable output of time spent in both the function and its descendants [disabled].
(S) Self : enable output of time spent in a function itself [disabled].
(D) Descendants : enable output of time spent in descendants of a function [disabled].
(P) Percentage : enable output of percentage of time spent in a feature [disabled].
(H) Help : show list of commands.
(M) Main : go back to main menu.
(U) Parent menu : go back to parent menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
Each one of these commands switches on or off the corresponding column output. The default is set on for the first two, off for the others. To enable or disable a column, type the name with a toggle effect.
==Query submenu==
The (U) Query submenu enables you to define a set of queries. The result will be a Total Query; by default it is the boolean and all the queries you have entered individually, but you may deactivate some of these and choose other boolean operators.
<code lang=text>
(A) Add : add a sub query.
(I) Inactivate : inactivate sub query.
(R) Reactivate : reactivate sub query.
(C) Operator : change the boolean operator.
(S) Show : show the list of queries.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(U) Parent menu : go back to parent menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
To get useful information, you should add the appropriate queries through (A) Add. Each individual query has the following form: ''attribute operator value'', where ''attribute'' is one of:
* feature name
* calls
* total
* self
* descendants
* percentage
''operator'' is one of:
* <
* >
* <=
* >=
* =
* /=
* in <br/>
and ''value'' is one of:
* An integer (for calls)
* A string (for feature name). The string may contain wild card characters: ?, standing for arbitrary characters, and *,standing for arbitrary substrings.
* A real value (for other attributes)
* An interval, of the form a-b for two values a and b.
* max
* min
* avg
The (S) Show command will display the current queries, each with an associated number. The output includes the total query, explained next.
To inactivate a query, use (I) Inactivate. You will be prompted for a query index, which you may retrieve from (S) Show. This is useful if you make a change about a query, or want to set it aside for future use.
To reactivate a query, use (R) Reactivate. Again you will have to provide a query index.
The Total Query resulting from a succession of (A) Add commands, possibly with some (I) Inactivate and (R) Reactivate commands, is a boolean query resulting by default from adding all the currently active queries. For example after the following set of commands(note that commands output help lines, which have been skipped here):
<code lang=text>
Command => a
--> Subquery: featurename = put*
Command => a
--> Subquery: calls = 3
-- Here we change our mind and deactivate the second query
-- to replace it by calls = 3:
Command => s
[1] featurename = put* is active
[2] calls = 3 is active
The total active query:
featurename = put* and
calls >
Command => i
--> Subquery index: 2
Command =&gt; a
--> Subquery: calls > 5</code>
<br/>
The (S) Show command will show the following result:
<code lang=text>
Command => s
All subqueries:
[1] featurename = put* is active
[2] calls = 3 is inactive
[3] calls > 5 is active
The total active query:
featurename = put* and
calls > 5</code>
To change the boolean operator to 'or' rather than 'and', use the (C) Operator command. It will prompt you for the index of the operator and the new value:
<code lang=text>
Command => c
--> Operator index followed by operator ('and' or 'or'): 1 or
Command => s
All subqueries:
[1] featurename = put* is active
[2] calls = 3 is inactive
[3] calls > 5 is active
The total active query:
featurename = put* or
calls > 5</code>
==Input command==
The (I) Input command serves to load Execution Profiles. It is initially set to *.pfi meaning that it will load all files with extension pfi. By calling the command repeatedly with new arguments, you are able to load more Execution Profiles. If you use the command without any argument, and the set of input files contained just one file, then the queries will use the last generated output. This avoids explicitly loading a file.
==Language command==
The (L) Language command enables you to specify the languages to which profiling should be applied. You can specify Eiffel only, C only, or both. If you specify only one language, the query results will not contain any information about routines written in the other language.
The default is Eiffel only. To switch to both Eiffel and C, use
<code lang=text>
Command => L eiffel and c</code>
To return to just Eiffel, simply type <code>L</code> .
==Run Command==
To run the current total query, use (R) Run.
==Generate command==
To run the profile converter under the command-line interface, use the (G) Generate command. This will generate an Execution Profile, stored in a file with the extension .pfi.
When running the Generate command with no arguments, you will be prompted for the following information:
* Name of file to be converted (default: profinfo).
* Compilation mode: workbench or finalized (default: workbench).
* Name of profiler tool (default: eiffel).
You can also type in the arguments directly without waiting to be prompted, as in
<code lang=text>
Command => g profinfo finalize eiffel </code>
{{seealso|<br/>
[[Profiler Wizard|Profiler wizard]] }}

24
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki Normal file
View File

@@ -0,0 +1,24 @@
[[Property:title|System menu]]
[[Property:weight|4]]
[[Property:uuid|c1450c9b-a5d3-3709-1176-9c5c49def362]]
The System Menu gives general information about the system:
<code lang=text>
(A) Config : show the config file.
(L) Classes : show the classes in alphabetic order.
(S) Cluster hierarchy: display the cluster hierarchy of the system.
(C) Clusters : show the system's classes, cluster by cluster.
(V) Edit : edit the config file.
(I) Indexing : show indexing clauses of classes.
(O) Modifications: show classes modified since last compilation.
(T) Statistics : show system statistics.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.</code>
The A (Config) command shows the configuration file; the E (Edit) command enables you to edit the configuration file; the C (Clusters) command is useful to display the entire list of classes, cluster by cluster.

21
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/testing-menu.wiki Normal file
View File

@@ -0,0 +1,21 @@
[[Property:title|Testing menu]]
[[Property:weight|5]]
[[Property:uuid|a6a0cf9d-ac10-4473-80e1-470acd461610]]
The AutoTest Menu gives information about the autotest entries:
<code lang=text>
(L) List view : Display tests in a list.
(T) Tree view : Display tests in a tree structure.
(E) Execute : run tests.
(A) AutoTest : AutoTest.
(H) Help : show list of commands.
(M) Main : go back to main menu.
(Q) Quit : terminate session.
(Y) Yank : yank (save) output of last command to a file.
</code>
The L and T displays the test cases in list or tree.
The E execute the existing test cases.

405
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki Normal file
View File

@@ -0,0 +1,405 @@
[[Property:modification_date|Mon, 24 Dec 2018 08:49:05 GMT]]
[[Property:publication_date|Mon, 24 Dec 2018 08:45:22 GMT]]
[[Property:title|EiffelStudio: Using command line options]]
[[Property:link_title|Using command line options]]
[[Property:weight|1]]
[[Property:uuid|a6b6a676-8660-ce2d-6f37-03de7f23a78e]]
==Compiling and viewing==
The Eiffel Compiler line mode command '''ec''' has many options, as you can see from the tables below. It may be helpful to think of any one '''ec''' command as either a command to compile or a command to view software text.
==Getting help==
You can get details of the usage and options of the '''ec''' command by executing the command with the '''-help''' option.
<code lang="text">
ec -help
</code>
The usage and options display gives you information about which options are valid in a particular command context. Use this display along with the table below to choose the options that meet your needs.
Usage and options of the command line compiler vary from version to version in order to accommodate new and changed features. Here is an example of the command line help from the latest version of EiffelStudio:
<code lang="none">
ISE EiffelStudio version 18.11.10.2549 GPL Edition - win64
Usage:
ec [-help | [-compat | -experiment] | -version | -full
-batch | -clean | -verbose | -use_settings |
-freeze | -finalize [-keep] | -precompile [-finalize [-keep]] | -c_compile |
-loop | -debug | -quick_melt | -melt | -clients [-filter filtername] class |
-suppliers [-filter filtername] class |
-flatshort [-filter filtername] [-all | -all_and_parents | class] |
-flat [-filter filtername] [-all | -all_and_parents | class] |
-short [-filter filtername] [-all | -all_and_parents | class] |
-pretty input_filename [output_filename] |
-filter filtername [-all | class] |
-descendants [-filter filtername] class |
-ancestors [-filter filtername] class |
-aversions [-filter filtername] class feature |
-dversions [-filter filtername] class feature |
-implementers [-filter filtername] class feature |
-callers [-filter filtername] [-show_all] [-assigners | -creators] class feature |
-callees [-filter filtername] [-show_all] [-assignees | -creators] class feature |
[[-config config.ecf] [-target target] [-config_option option]|
[class_file.e [-library library_name]] |
-stop | -no_library |
-project_path Project_directory_path | -file File |
-ca_class (-all | class) | -ca_default | -ca_rule rule | -ca_setting file |
-gc_stats]
Options:
default (no option): quick melt the system.
-ancestors: show the ancestors of a class.
-aversions: show the ancestor versions of a feature.
-batch: launch the compilation without user request.
-c_compile: launch C compilation if needed.
-ca_class: analyze code of a class or of all non-library classes (-all).
-ca_default: restore default code analyzer preferences.
-ca_rule: activate code analyzer rule(s) (with settings).
-ca_setting: load code analyzer preferences from a file.
-callees: show the callees of a feature.
-callers: show the callers of a feature.
-class_file.e: specify a class file for single file compilation.
-clean: delete existing project if any and perform a fresh compilation.
-clients: show the clients of a class.
-compat: enable pre-attached type compatibility.
-config: specify the configuration (ECF) file.
-config_option: override configuration options of a target.
-debug: debug the system as a command loop.
-descendants: show the descendants of a class.
-dversions: show the descendant versions of a feature.
-experiment: enable experimental functionalities.
-file: save the output to a file.
-filter: show a filtered form (troff, ...) of the class text.
-finalize: finalize the system (discard assertions by default).
-flat: show the flat form of a class.
-flatshort: show the flat-short form of a class.
-freeze: freeze the system.
-full: with full class checking regardless of ECF settings.
-gc_stats: Show GC statistics.
-gui: start the graphical environment.
-help: show this help message.
-implementers: show the classes implementing a feature.
-library: specify a library for single file compilation.
-loop: run ec as a command loop.
-melt: melt the system.
-no_library: do not convert clusters into libraries.
-overwrite_old_project: overwrite any existing old project.
-precompile: precompile the system.
-pretty: show the pretty form of a class.
-project: specify the project file to load (obsolete).
-project_path: specify the compilation directory.
-quick_melt: quick melt the system.
-short: show the short form of a class.
-stop: stop on error.
-suppliers: show the suppliers of a class.
-target: specify the target.
-use_settings: use settings for project location.
-version: show compiler version number.
</code>
==Commands for compiling==
The simplest compiling command you can enter is:
<code lang="text">
ec
</code>
The command does not include any of the ''Compiling options'' shown below, so the default option "-melt" is used. The "-config" is omitted, so '''ec''' will try to find a configuration file named <code lang="text">Ace.ecf</code> in the current directory.
The command:
<code lang="text">
ec -config my_config_file.ecf
</code>
melts the system having the configuration file in the current directory <code lang="text">my_config_file.ecf</code> .
To freeze or finalize that system, you would just include the appropriate ''Compiling option'':
<code lang="text">
ec -freeze -config my_config_file.ecf
</code>
You can specify the name of a file which contains the root class of a system in the current directory:
<code lang="text">
ec application.e
</code>
This command will compile a system with the class in <code>application.e</code> as its root. If there is no configuration file named <code>application.ecf</code> in the current directory, then '''ec''' will create one. It will also use any classes in the current working directory and by default the library EiffelBase.
{{tip|This "configuration-less" form of compilation is convenient to use for a quick compile. But you should understand that because it does create a configuration file with default names for the configuration file itself, the project, and the root cluster, using it against a root class file in a folder in which a configuration file with another name already exists could lead to confusion. }}
You can add additional libraries to the configuration by using the "-library" option and specifying either the short name of one of the EiffelStudio libraries or a path to a library configuration file. To include EiffelTime in the compilation of <code>application.e</code>, you could use this command:
<code lang="text">
ec application.e -library time
</code>
This immediately adds the EiffelTime library to the configuration file <code>application.ecf</code>, so if you compile again, it is not necessary to respecify the library.
==Commands for viewing==
By selecting certain options on the '''ec''' command, you can generate advanced views of your software much like those provided by EiffelStudio. In the table below you will see the set of ''Viewing options''. These options take arguments that are either a class name or a class name and feature name. The following examples will give you an idea of how to use the ''Viewing options''.
To see the "flat" form of class <code>APPLICATION</code> in the example used above:
<code lang="text">
ec -flat application -config application.ecf
</code>
To save the output, add the "-file" option with a file name:
<code lang="text">
ec -flat application -config application.ecf -file application_flat_form.txt
</code>
Feature-oriented options, like "-implementers", take a class name and feature name:
<code lang="text">
ec -implementers application some_feature -config application.ecf
</code>
===Commands for generating documentation===
You can use variations of the viewing commands to generate documentation for your Eiffel system much like [[Producing and Exporting Documentation|you can from EiffelStudio]].
The following command will produce the ''Chart'', ''Relations'', and ''Text'' documentation for the "application" system in html-stylesheet format in the "Documentation" subfolder of the project folder.
<code lang="text">
ec -filter html-stylesheet -all -config application.ecf
</code>
To produce documentation for a view other than ''Text'', use its option in the command. The following generates ''Chart'', ''Relations'', and ''Flat Short'' documentation:
<code lang="text">
ec -flatshort -filter html-stylesheet -all -config application.ecf
</code>
==Commands for the Code Analyzer==
The Code Analyzer is invoked when an option to analyze the whole system or a particular class is specified in the command line. Additional command-line options are used to specify some preferences and to enable specific rules:
<code lang="shell">
ec -config project.ecf [-ca_class (-all | <CLASS_NAME(S)>) | -ca_default | -ca_rule <RULE_SPEC(S)> | -ca_setting <FILE_NAME>]
</code>
;<code lang="shell">-ca_default</code>: Requests to reset all Code Analyzer preferences to their default values before the analysis is run. For example, this enables all rules that are enabled by default, no matter whether they have been disabled before.
;<code lang="shell">-ca_setting</code>: Requests to use preferences from the specified file. The file is generated by exporting the current preferences from the GUI.
;<code lang="shell">-ca_class</code>: Asks to analyze a given class or a set of classes. Several class names can be specified, separated either by spaces or semicolons. In that case, the argument may need to be enclosed in double quotes (e.g., `"CLASS1; CLASS2"`). A special value `-all` triggers analysis of the whole system.
;<code lang="shell">-ca_rule</code>: Followed by a list of rules, enables those rules for the analysis and disables all the others, overriding the current preferences. Specific rule preferences can also be provided in parentheses. Preferences are separated by commas. The rule names can optionally be separated by semicolons. Example:
<code lang="shell">
-ca_rule "CA001; CA033 (maximum_feature_count=10; maximum_instruction_count=100); CA066 (enforce_prefix=False)"
</code>
==Command options==
The table below lists the available ''options'', the arguments they require, and their effect:
{| border="1"
|-
| width="175pt" | '''OPTION'''
| '''ARGUMENTS'''
| '''EFFECT'''
|-
| ''Compiling options''
|-
| -melt
|
| [[Melting Ice Technology#Melting|Melt]] compilation. This is the default option, if no other compiling or viewing option is specified.
|-
| -freeze
|
| [[Melting Ice Technology#Freezing|Freeze]] system.
|-
| -finalize
|
| [[Melting Ice Technology#Finalizing|Finalize]] system. See note below.
|-
| -precompile
|
| [[Melting Ice Technology#Precompiling|Precompile]] system, treating it as a library.
|-
| -full
|
| Full class checking. Rechecks features of the parent classes for validity in heirs. See example in [[Converting existing software to void-safety#Enable full class checking|Converting existing software to void-safety]]. NOTE: Full class checking increases compile times, which may be noticeable in large systems.
|-
| -compat
|
| Compile using facilities that are [[Eiffel compatibility options#EiffelStudio and Eiffel compiler options|compatible with older versions]] of Eiffel.
|-
| -experiment
|
| Compile using facilities that are [[Eiffel compatibility options#EiffelStudio and Eiffel compiler options|compatible with an upcoming version]] of Eiffel.
|-
| ''Viewing options''
|-
| -ancestors
| class_name
| Print the ancestors of the class.
|-
| -aversions
| class_name, feature_name
| Print the ancestor versions of the feature.
|-
| -callers
| class_name, feature_name
| Print all the routines that call the feature.
|-
| -clients
| class_name
| Print the clients of the class
|-
| -descendants
| class_name
| Print the descendants of the class.
|-
| -dversions
| class_name, feature_name
| Print all the versions of the feature in the descendant versions of the class.
|-
| -flat
| class_name
| Print the flat view of the class.
|-
| -flatshort
| class_name
| Print the Flat Contract view (previously called flat-short form) of the class.
|-
| -implementers
| class_name, feature_name
| Print all the classes that declare or redeclare the feature.
|-
| -short
| class_name
| Print the Contract view (previously called short form) of the class.
|-
| -suppliers
| class_name
| Print all the suppliers of the class.
|-
| ''Other options''
|-
| -batch
|
| Launch the compilation without user request.
|-
| -clean
|
| Delete project if already compiled and compile project as if it was the first time.
|-
| -config
| file_name
| Use the file as configuration.
|-
| -c_compile
|
| Launch C compilation, if needed, after Eiffel compilation.
|-
| -file
| file_name
| Save the output to the file.
|-
| -filter
| filter_file_name
| Print text as processed by the [[Appendix: Writing Documentation Filters with EFF, the Eiffel Filter Format|filter]] defined in the file named "''filter_file_name''.fil"
|-
| -help
|
| Print the help.
|-
| -keep
|
| Keep assertions in final mode. Useful with -finalize only.
|-
| -library
| library_name
| Library is included in the configuration when a file name for the root class is given.
|-
| -loop
|
| Enter interactive mode. See: [[Command line interactive mode]].
|-
| -metadata_cache_path
| directory_name
| Specify location of Metadata Cache used for .NET compilation. This overrides any settings from your configuration file.
|-
| -no_library
|
| When converting an old configuration file format, do not convert clusters into libraries.
|-
| -project_path
| directory_name
| Use this directory as compilation directory. (Default: current directory.)
|-
| -stop
|
| Stop on errors. (Default: no.)
|-
| -target
| target_name
| Act on the system target named ''target_name''.
|-
| -use_settings
|
| Use the project global settings to retrieve the project location for the last compilation of this project.
|-
| -verbose
|
| Display detail progress report during compile.
|-
| -version
|
| Print compiler version number.
|}
{{note|In the third column, to '''print''' means to produce the requested information on the default output of the '''ec''' command.}}
{{note|When using '''-finalize''', assertions will be discarded (unlike in EiffelStudio which asks first). The assertion disposition specified in the project configuration file can be retained in finalization by combining the '''-keep''' option with '''-finalize'''.}}
Some options can have modifiers that can affect their results. The modifiers are listed in the table below:
{| border="1"
|-
| <center>'''Option'''</center>
| <center>'''Modifier'''</center>
| <center>'''Effect'''</center>
|-
| -callers
! colspan="2" |
|-
|
| -show_all
| Include all callers rather than only those in the specified class.
|-
|
| -assigners
| Restrict callers to those that use given feature only as a target of an assignment instruction.
|-
|
| -creators
| Restrict callers to those that use given feature only as a target of a creation instruction.
|}
{{seealso|<br/>
[[Batch compilation|Batch compilation]] }}

64
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/finish-freezing-utility.wiki Normal file
View File

@@ -0,0 +1,64 @@
[[Property:title|finish_freezing utility]]
[[Property:weight|4]]
[[Property:uuid|bfc362f4-9187-ea47-baf6-46880ed43fdd]]
=Introduction=
The command line utility finish_freezing is used to compile external code generated by the Eiffel compiler. Most of the time finish_freezing gets executed behind the scenes as you freeze and finalize Eiffel systems, so you don't really need to be aware of it. However, finish_freezing can be run standalone, and is useful, for example, when [[Porting an Eiffel application from UNIX to Windows or vice-versa|porting systems to other platforms]].
=Usage of finish_freezing=
<code lang="text">
finish_freezing [-location <directory>] [-generate_only] [-nproc <n>] [-low]
[-x86] [-library] [-version] [-nologo]
</code>
Options:
:Options should be prefixed with: '-' or '/'
{| border="1"
|-
! style="text-align: center" | Option
! style="text-align: center" | Arguments
! style="text-align: center" | Effect
|-
|-
| -location
| ''directory''
| Alternative location to compile C code in.
|-
| -generate_only
|
| Informs tool to generate only a Makefile.
|-
| -nproc
| ''n''
| Maximum number of processors to use.
|-
| -low
|
| Executes finish freezing in low-execution priority mode.
|-
| -x86
|
| Generate 32bit lib DLLs for .NET projects.
|-
| -library
|
| Compiles the C code of an Eiffel library.
|-
| -?
|
| Display usage information.
|-
| -version
|
| Displays version information.
|-
| -nologo
|
| Supresses copyright information.
|}

11
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki Normal file
View File

@@ -0,0 +1,11 @@
[[Property:title|Command line]]
[[Property:weight|-13]]
[[Property:uuid|e1a93995-38bf-14fa-421e-e6fe1f07b9f6]]
==Using the command line compiler==
It is possible to compile from outside of the graphical environment, by using the command '''ec'''. The form of compilation's results are the same in both cases. You may therefore alternate between the two techniques. '''ec''' will enable you to [[EiffelStudio: Using command line options|melt or freeze]] a project and therefore to use [[Batch compilation|batch compilation]] . It will also enable you to produce [[EiffelStudio: Using command line options|information about a class]] such as its Flat and Flat Contract views.
The [[EiffelStudio: Using command line options|-loop option]] makes it possible to start '''ec''' just once and then repeatedly request any of the available operations.

40
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.01-and-ISE-Eiffel-15.08.wiki Normal file
View File

@@ -0,0 +1,40 @@
[[Property:uuid|C86C3894-2FBC-443E-8E19-FD4A442642CA]]
[[Property:weight|6]]
[[Property:title|Major changes between ISE Eiffel 15.01 and ISE Eiffel 15.08]]
[[Property:link_title|15.08]]
==What's new==
* Supported a new inline separate instruction that allows making feature calls on uncontrolled separate targets inline rather than calling dedicated routines:
<code>
separate
some_expression_of_separate_type as x,
other_expression_of_separate_type as y
do
x.foo
y.bar
end
</code>
* Supported creation of passive regions in SCOOP that execute all logged calls on caller's processors:
<code>
create <NONE> foo.make -- Creation instruction.
bar := create <NONE> {separate BAZ}.make -- Creation expression.
</code>
A side effect is that all calls on passive regions are synchronous.
==Improvements==
* runtime: Improved memory management by performing O(log N) lookups when looking for a large block of memory instead of O(N). This would occur after allocating many large objects whose size is greater than 512 bytes (on 32-bit platform) and 1024 bytes on 64-bit platform and then freeing all those objects. Next time you look for a large object it might have to go through all those large objects without finding one that is large enough.
* code generation: Made code slightly more compact (2 to 6% size reduction on some platform).
* Optimized `expr and False` and `expr and then False` to just False if `expr` is a local, a argument, Result, Current, an attribute access or if it is the `and` boolean op.
==Changes==
==Bug fixes==
===Compiler issues===
* Fixed eweasel test#final122 and bug#19028 where we would incorrectly optimize `expr and False` or `expr and then False` into just `expr` which is wrong if `expr` is True (as the whole expression would be True and not False).
===SCOOP issues===
* The SCOOP runtime is now fully written in C to avoid portability issues.
* Corrected access to tuple fields in SCOOP mode that now follow the validity rules and the semantics of ordinary attributes of a class.
* test#scoop034 - Fixed a code generation bug in finalized mode for a generic derivation with an actual generic of a basic type.
* test#term216 - Fixed a crash when processing conversion queries defined as constant attributes.
* Changed agent creation rules for separate targets. This change makes it possible to introduce library features that help users to avoid writing small little wrapper features in SCOOP to control an object. It is now possible to create agents on separate, uncontrolled target. The newly created agent object is placed on the same processor as the target, and it inherits the 'is_controlled' status.

27
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.08-and-ISE-Eiffel-15.12.wiki Normal file
View File

@@ -0,0 +1,27 @@
[[Property:uuid|A4F3EBA0-0E2B-4CF4-86A9-4757F7401A63]]
[[Property:weight|5]]
[[Property:title|Major changes between ISE Eiffel 15.08 and ISE Eiffel 15.12]]
[[Property:link_title|15.12]]
==What's new==
* Agents have a new type declaration. Instead of <eiffel>PROCEDURE [X, TUPLE [Y]]</eiffel>, one can now write <eiffel>PROCEDURE [Y]</eiffel> where the first generic actual parameter is not considered anymore and the TUPLE declaration omitted. The compiler accepts both syntaxes but only one at a time based on the project's ECF (in other words, you cannot mix both syntaxes within the same project). Meaning that an Eiffel project can use libraries with mismatched syntaxes. The choice of the accepted syntax is based on the version associated to the project's ECF. The new version generated by EiffelStudio will use the new syntax, while existing ECFs will use the old syntax. To upgrade your projects to use the new syntax, use the '''syntax_updater''' tool and using the '''-a''' argument.
==Improvements==
* Introduced options to select the number of types being generated in each C directory via the general.cfg located in $ISE_EIFFEL/studio/eifinit. The first option is workbench_c_basket_limit for workbench code (defaulting at 33) and the other is finalized_c_basket_limit (defaulting at 50).
* Fixed incrementality performance issues on large system. Instead of taking a few minutes at the end of degree 3 before jumping to degree 2, it will now take about 10 to 15 seconds.
==Changes==
==Bug fixes==
===Compiler issues===
* Fixed bug#19120 (test#tuple019) by reporting the tuple field name that violated VUAR(2) for the corresponding assigner command.
* Fixed test#attach049 by checking target type of boolean operators when computing scopes of variables.
* Fixed test#attach114 by checking that parenthesis may be used as parenthesis alias calls.
* Fixed test#anchor012.
* Fixed bug#17907 (test#incr417), bug#17913 (test#incr418), (in assertion-enabled mode) bug#17942 (test#incr419), test#incr432 by making sure any changes after an error fix are taken into account.
* Fixed test#attach115 by recording a qualified call as soon as there is an iteration form of a loop.
* Fixed improper type of like argument in generics (test#exec364).
===SCOOP issues===
* Fixed test#scoop074 by propagating the controlled status of an object test expression to an object test local to avoid unnecessary wrapping for this local.
* Fixed test#scoop075 by allocating a separate call data structure register before message processing and by freeing it at the end of a call so that the register does not get incorrectly reused.

116
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.12-and-ISE-Eiffel-16.05.wiki Normal file
View File

@@ -0,0 +1,116 @@
[[Property:uuid|54814BE5-3591-46C0-B883-42F1FC265873]]
[[Property:weight|0]]
[[Property:title|Major changes between ISE Eiffel 15.12 and ISE Eiffel 16.05]]
[[Property:link_title|16.05]]
==What's new==
* Change the default behavior of attachment of local entities and Result. They are treated as if they were detachable. We instead apply the rules of void-safety to check that all usages are properly typed. In the case of Result, it has to be attached at the end of the routine.
This is achieved as follows:
# If a local (or Result) is a target of an assignment, it's type is considered detachable.
# If a local (or Result) of a type that required initialization (this includes attached and formal generic types, possibly through anchors) is not set, it's value is considered detachable.
# If a local (or Result) is considered attached due to an assignment or a CAP, it is also considered set (even though it might have never been assigned).
# If a local (or Result) is assigned a value that requires initialization (i.e. of an attached or formal generic type), it is considered set, but may be detachable.
# If a local (or Result) is assigned a value of a detachable type that does not require initialization, it is considered unset and detachable.
# A target of an assignment attempt may not be of an attached type or a type that requires initialization.
# At routine end Result is required to be set if it is of a type that requires initialization.
The change allows dropping explicit detachable marks in local declarations and simplifying the code that uses Result, e.g.
<code>
foo: X
local
r: detachable X
do
r := something
if not attached r then
r := something_else_attached
end
Result := r
end
foo: X
do
if attached something as r then
Result := r
else
Result := something_else_attached
end
end
</code>
into
<code>
foo: X
do
Result := something
if not attached Result then
Result := something_else_attached
end
end
</code>
The change does not allow previously void-unsafe code to be treated as void-safe, but may affect errors reported by the compiler, in particular:
# VEVI errors may be now reported as VUTA(2) when a local of an attached type is used as a target of call before it is attached.
# VEVI errors may be now reported as VJAR (or the counterpart for argument passing) when a local of an attached type is used as a source expression before it is attached.
==Improvements==
* Improve reporting for errors in regular expressions used in include and exclude file rules in ECF by adding position information and providing error description all the time.
* Improve performance of code using across iterator. {{Inline-Warning|Breaking change:}} custom descendants of <code>READABLE_INDEXABLE</code> may need to be updated in one of the following ways:
*# By removing <code>index_set</code>, if no backward compatibility with earlier versions of EiffelStudio is required
*# By adding an explicit redeclaration clause for <code>index_set</code>, if backward compatibility with [[Release notes for EiffelStudio 15.12|EiffelStudio 15.12]] is required:
<code>
inherit
READABLE_INDEXABLE
redefine
index_set
end
</code>
*:The specific changes in the compiler and cursor classes include:
** Optimized code generation for iteration instruction calls to <code>after</code> and <code>forth</code> by rechecking the code with the actual type of a cursor variable.
** Added <code>lower</code> and <code>upper</code> to <code>READABLE_INDEXABLE</code> to be used instead of <code>index_set</code> by iteration cursor.
** Marked <code>{READABLE_INDEXABLE}.index_set</code> as obsolete in favor of <code>lower</code> and <code>upper</code> to avoid object creation, especially when implementing external cursors for iterative forms of a loop.
** Provided implementation of <code>index_set</code> in <code>READABLE_INDEXABLE</code> so that it can be removed in descendants.
** Made <code>lower_defined</code> and <code>upper_defined</code> in <code>INTEGER_INTERVAL</code> always <code>True</code> because this was the case for all created objects and clients almost never checked if boundaries were defined.
** Provided specialized versions of iteration cursors for <code>SPECIAL</code>, <code>ARRAY</code>, <code>ARRAYED_LIST</code>, <code>READABLE_STRING_8</code>, <code>READABLE_STRING_32</code> to improve performance of across loops for these containers.
==Changes==
* Change code analysis command-line arguments to report errors immediately instead of trying to run code analysis and improve error reporting by providing more details (such as option name, rule name, kind of syntax error).
* Add support of position-independent code analysis options (still retaining old code analysis options) that act like regular EiffelStudio command-line options:
** <span style="font-family: monospace;">-ca_default</span>
** <span style="font-family: monospace;">-ca_setting ''preference_file_name''</span>
** <span style="font-family: monospace;">-ca_class <nowiki>(</nowiki> -all <nowiki>|</nowiki> ''class_name'' <nowiki>)</nowiki></span>
** <span style="font-family: monospace;">-ca_rule ''rule_name_with_optional_setting''</span>
* Add a more efficient way to perform access on void target in non-void-safe mode by making the check only once for side-effect free entities.
* Avoid checks for voidness for object test locals because they are always attached.
==Bug fixes==
* Fix crash during documentation generation via the Generate documentation dialog when the project contains library that are not actually part of the system because they are conditionnaly included (see bug#19173)
* Fix code analysis issue by resetting the internal data between checks (see eweasel test#codeanalysis019)
* Fix .NET code generation failure causing a stack overflow.
* Fix spurious compilation error when involving conversions between attached and detachable types.
* Fix invalid type checking error when using a manifest array in an across loop when some special crafted code appears before (see eweasel test#valid288) as in:
<code>
failure
local
i: INTEGER
do
-- Comment out next line to fix the bug.
bar (Void).make_from_array (Void)
across
<<1, 2, 3>> as c_i
loop
i := c_i.item -- Error here.
end
end
</code>
* Fix .NET code generation to generate verifiable code when converting a manifest integer constant compatible with a <code>NATURAL_64</code> (see eweasel test#dotnet118)
* Fix invalid .NET code generation when you inherit from a .NET class where one of the following routines is frozen: <code lang="cs">Equals</code>, <code lang="cs">Finalize</code>, <code lang="cs">ToString</code> and/or <code lang="cs">GetHashCode</code> (see eweasel test#dotnet119)
* Fix invalid inlining of routine involving an object test local, an iteration cursor or a separate instruction local (see bug#18028, test#final114, test#final123, test#bench019).
* Fix test#scoop077 by applying SCOOP semantics rules and checking SCOOP validity rules for iteration cursors.
* Fix an issue when extracting a type ID from a string involving the separate keyword.

6
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-with-ISE-Eiffel-18.07.wiki Normal file
View File

@@ -0,0 +1,6 @@
[[Property:modification_date|Wed, 04 Jul 2018 09:15:02 GMT]]
[[Property:publication_date|Wed, 04 Jul 2018 09:13:19 GMT]]
[[Property:uuid|C7E5CC3E-D942-4970-A6C3-CCF560F84E1F]]
[[Property:weight|-1]]
[[Property:title|Major changes with ISE Eiffel 18.01 and 18.07]]
[[Property:link_title|18.07]]

6
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/index.wiki Normal file
View File

@@ -0,0 +1,6 @@
[[Property:title|EiffelStudio 5 compiler history]]
[[Property:link_title|5.x]]
[[Property:weight|15]]
[[Property:uuid|6fc4449c-889f-521d-4f80-69245fbd5f54]]

24
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki Normal file
View File

@@ -0,0 +1,24 @@
[[Property:title|Assertions checking configuration changes]]
[[Property:weight|0]]
[[Property:uuid|45e5cc54-cc3d-9f21-b73f-462430ae845e]]
One of the major differences between 4.5 and 5.0 is how to specify the assertion checking in the ace file or in the project settings window. In 4.5, assertions of a certain type where checked if their level was below the requested level. Here is what the level hierarchy looked like:
# require
# ensure
# loop
# check
# invariant
# all
Meaning that you could not just check one type of assertions. With 5.0 this is now possible and we changed the presentation to follow the cost to evaluate a given type of assertions, the first one being the less expensive:
# check
# require
# ensure
# loop
# invariant
# all
The default assertion level has changed too. Not specifying any assertion level used to be equivalent to selecting the 'require' level. This is not the case any more in 5.0 it will be not checking assertions.

32
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki Normal file
View File

@@ -0,0 +1,32 @@
[[Property:title|Compiler differences from 4.5 to 5.0]]
[[Property:weight|1]]
[[Property:uuid|0937ae2f-0959-ca89-e851-2c8ccbf4f3aa]]
==What's new==
* Implementation of new external syntax.
* Implementation of verbatim strings.
* Implementation of agents.
* Implementation of agent creations on `Result` and `Current` object.
* Improved incrementality of the C compilation: fewer directories will have their C files changed after a freeze.
* New MSIL generation.
* Introduction of 4 new basic classes: INTEGER_8, INTEGER_16, INTEGER_64, WIDE_CHARACTER.
* Changed the storable mechanism so that we do not store POINTER objects with their value, instead we store a NULL value. As a consequence it is safe to store on disk objects that have references to C objects. Upon retrieval those references will be equal to `default_pointer`. This is now the default behavior, if someone wants to have the previous behavior, simply call `set_keep_pointer_value` from STORABLE.
==Improvements==
* New run-time speed improvement (between 30 to 100% faster than the 4.5 release).
* Compiler that is much faster (between 200 and 300% faster than 4.5).
* Compiler now detects unused local variables (at freeze/finalize time only)
==Bug fixes==
* Compiler now fixes incrementality issues with frozen/melted code.
* Degree 4/Degree 3 crash on *_SERVER when doing an incremental recompilation has been fixed.
* Fixed crash when using creation expression that includes a feature call.
* Fixed creation of an ARRAY of BIT type.
* CHARACTER has been extended to support the extended ASCII which means that the following expressions are now True instead of being False as it was in our previous version:
** '%/127/' < '%/128/'
** '%/127/' < '%/128/'
** When using `independent_store`, in case of retrieval error due to a name change in one of the class attributes we will display the original attribute name that was used to make the storable file. This will help when managing many storable files.

17
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/eiffelthread-differences-45-50.wiki Normal file
View File

@@ -0,0 +1,17 @@
[[Property:title|EiffelThread differences from 4.5 to 5.0]]
[[Property:weight|0]]
[[Property:uuid|f95360f9-3b02-5f1b-9667-68846d0e0a7d]]
Users of EiffelThread in 4.5 will notice a few changes that we made to make their life easier.
==Object sharing==
Indeed one aspect of EiffelThread in 4.5 that was not easy to implement was object sharing between threads. Most of the difficulty came from our special implementation of the Eiffel Software GC (Garbage Collector) where each thread had its own GC.
A consequence was that an object in thread A referencing an object in thread B needed to let the GC of B that it had a reference to an object that belongs to him. This was done by using the PROXY class and instead of referencing the object directly you were referencing the PROXY object. Another limitation of this approach was that the referred object could not hold reference to other objects, it could only hold values of basic expanded types (also previously called flat objects)
Now, there is a global GC and therefore you do not need to use the PROXY class anymore and you can reference any kind of objects. The PROXY class is still available for backward compatibility, but it is now obsolete and its implementation has been reduced to a bare minimum.
The class OBJECT_CONTROL has been removed altogether and the class OBJECT_OWNER is now obsolete as well.
==Global onces==
In 4.5, you would have to use a special tricky way to create once per process feature by using an existing once per thread feature and an external C feature that we were providing to achieve a once per process behavior.
In 5.0, this has been simplified and you can now specify at the level of the source code if it will be a once per process or once per thread. Click [[Once features in multithreaded mode|here]] for more details on how this is done.

11
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki Normal file
View File

@@ -0,0 +1,11 @@
[[Property:title|Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0]]
[[Property:link_title|5.0]]
[[Property:weight|-7]]
[[Property:uuid|82179716-24e3-0aa1-7562-bf0a87c05749]]
* [[Assertions checking configuration changes|Assertions checking]]
* [[EiffelThread differences from 4.5 to 5.0|EiffelThread]]
* [[Compiler differences from 4.5 to 5.0|Miscellaneous]]

62
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki Normal file
View File

@@ -0,0 +1,62 @@
[[Property:title|Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1]]
[[Property:link_title|5.1]]
[[Property:weight|-8]]
[[Property:uuid|bdb0c46b-2774-f348-f8e8-9932cda47722]]
==What's new==
* .NET generation now includes:
** Support for multiple inheritance.
** Support for generics.
** Partial implementation of generic conformance (same as what was supported up to and including ISE Eiffel 4.2).
** Support for tuples and agents.
** Support for any existing Eiffel code that does not use C externals.
** Partial support for compiling Eiffel libraries using C externals (e.g. WEL)
And the following limitations:
** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients).
** The compiler performances are rather poor now (both in terms of memory usage and speed)
Those limitations should disappear with 5.2 which will be the official release that fully supports .NET
** Support for INTEGER_64 constants. Now a manifest integer value that is written in decimal or hexadecimal format that can't fit into an INTEGER_32 will be automatically promoted to an INTEGER_64 constant value.
** New feature access syntax for accessing constants, C/C++ externals and IL static externals. [[Differences between ETL 2nd printing and Eiffel Software implementation|Check out more here]] .
==Improvements==
* Compiler that is about 20% faster than 5.0.
==Bug fixes==
* Fixed <code>VAPE</code> errors that were not previously reported. Now <code>VAPE</code> errors are checked against arguments of a feature used in a precondition and are also checked for a qualified call.
* Fixed a conformance bug that made a manifest array not conform to ANY.
* Fixed a generic conformance bug where an assignment attempt would change the behavior of the execution.
* Fixed a wrongly reported error by the compiler in the following case:
In a system that has a generic class CLIENT with constraint `G -> SUPPLIER create make end', where the creation procedure of SUPPLIER is exported to {CLIENT}. If another class has an attribute `x: CLIENT [SUPPLIER]' the compiler reports a <code>VTCG</code> error, though it should accept the classes.
* Fixed a crash when one of the following command lines was used in a directory with no existing project that contains no default configuration file:
<code>ec -flat -all
ec -short -all
ec -flatshort -all
ec -flat -all_and_parents
ec -short -all_and_parents
ec -flatshort -all_and_parents</code>
* Fixed a bug in output display between standard output and error output. Doing the following:
<code>io.put_string ("foo%N")
io.error.put_string ("bar%N")</code>
you get the following output when simply launched from the command line:
<code>foo
bar</code>
however if you do:
<code>my_program >& RESULT</code>
to redirect both standard and error outputs to RESULT you get in the RESULT file this incorrect content:
<code>bar
foo</code>
* Fixed a non reported <code>VTEC</code> or <code>VTCG</code> error when an invalid type used as actual generic parameters in an explicit type in a creation instruction.

37
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki Normal file
View File

@@ -0,0 +1,37 @@
[[Property:title|Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2]]
[[Property:link_title|5.2]]
[[Property:weight|-9]]
[[Property:uuid|f08242d4-d472-142c-7f92-f2c043bc5fa6]]
==What's new==
* .NET generation now includes support for the following language features:
** Support for multiple inheritance.
** Support for generics.
** Partial implementation of generic conformance
** Support for tuples and agents.
** Support for any existing Eiffel code that does not use C externals.
** Support for compiling Eiffel libraries using C externals that are not related to the Eiffel Software C runtime.
And the following limitations:
** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients).
** No support for `expanded` keyword.
* .NET generation now supports assembly signing in enterprise edition.
* .NET generation now supports precompiled libraries.
* Supports for manifest integer constants of different sizes, i.e. you can now assign for example the value `8` to a location of type <eiffel>INTEGER_8</eiffel>, <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER</eiffel> or <eiffel>INTEGER_64</eiffel>, however you can only assign the value `254` to a location of type <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER</eiffel> or <eiffel>INTEGER_64</eiffel>.
==Improvements==
* Compiler that is about 20% faster than 5.1.
* Runtime is about 10-20% faster than 5.1
==Changes==
* One cannot create an instance of a basic expanded class ( <eiffel>BOOLEAN</eiffel>, <eiffel>CHARACTER</eiffel>, <eiffel>INTEGER_8</eiffel>, <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER</eiffel>, <eiffel>INTEGER_64</eiffel>, <eiffel>POINTER</eiffel>, <eiffel>REAL</eiffel>, <eiffel>DOUBLE</eiffel>), you will now get a <code>VGCC(6)</code> error. Instead directly assign to it, or create an instance of its corresponding _REF class.
==Bug fixes==
* Fixed memory corruption issue when trying to access an <eiffel>INTEGER_64</eiffel> value.
* Fixed a problem with manifest <eiffel>INTEGER_64</eiffel> constants whose values were incorrectly interpreted.
* Fixed <code>VAPE</code> errors that were not previously reported in 5.1. Now <code>VAPE</code> errors are checked against call to infix and prefix features.

165
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki Normal file
View File

@@ -0,0 +1,165 @@
[[Property:title|Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3]]
[[Property:link_title|5.3]]
[[Property:weight|-10]]
[[Property:uuid|c4a7cbf4-da42-791d-cc80-862692233ed9]]
==What's new==
* Finalized executable with option `exception trace' enabled will now display the instruction number (usually equivalent to the line number in the routine) being executed when a failure occurred. It was already displaying this information in workbench/melted mode, we have just extended this feature to finalize mode.
* Incremental compilation is now available for .NET code generation. Meaning that if you modify one class, only this class is being recompiled. It dramatically improves development time when targeting .NET.
* In .NET code generation, assertions can be turned on or off on a class per class basis without having to recompile those classes.
* Implemented [[EiffelBase, The Kernel|recoverable storable]] to enable the retrieval of slightly different version of an object. It only applies for classic Eiffel.
==Improvements==
* Enabled support for Borland C compiler in .NET.
* Removed too many warnings during C compilation on Tru64.
* Improved formatting of exception traces so that class names, feature names, exception tags are not truncated. Display limit has been pushed at about 256 characters.
==Changes==
* Made `\\' follow the balancing rules for various integer types.
* Precompiled libraries now precompiles all classes reachable from clusters defined in project settings only if root class is ANY, otherwise it will only precompile classes reachable from the root class. In 5.1 and prior version it was precompiling all classes reachable from clusters.
==Bug fixes==
===Language issues===
* Fixed semantic of object creations to strictly follow definition given in "Eiffel: The Language". Namely, if you have x of type <eiffel>X</eiffel>:
<code>create x.make is equivalent to x := create {X}.make</code>
It implies some bug fixes which might break existing code. For example:
<code>
x: X is
once
-- If make calls back to x then it used to return
-- a non-Void value for x, where it should have been Void.
create Result.make
end
x: X
-- If make accesses back the x attribute then it used to return
-- new value of x rather than the old value.
create x.make</code>
Or in melted code only the following code now works properly, i.e. <eiffel>make</eiffel> gets the old value of x, not the new one <br/>
<code>create x.make (x)</code>
* Fixed undetected <code>VDRD(3)</code> errors: compiler was not strict enough and accepted <code> ensure </code> where only <code> ensure then </code> was valid.
===Store/Retrieve issues===
* Fixed issue in storable mechanism when retrieving expanded objects.
* Fixed issue with independent_store where storing arrays of objects whose count was greater than 65536 will cause a memory corruption.
* Added <eiffel>correct_mismatch</eiffel> on <eiffel>HASH_TABLE</eiffel> to enable retrieval of the 5.1 and older version of <eiffel>HASH_TABLE</eiffel>.
===Runtime/code generation issues===
* Fixed incorrect C code generation in final mode when creating an <eiffel>ARRAY</eiffel> of expanded type.
* Fixed incorrect C code generation in final mode when creating a complex object which contains expanded objects that have expanded objects.
* Fixed random crash issue in finalized applications due to incorrect memory management when you have code similar to:
<code> f (g: STRING): ANY is
do
Result := create {STRING}.make_from_string (g)
end</code>
* Fixed issue with <eiffel>deep_equal</eiffel> on <eiffel>ARRAY</eiffel> of expanded types which was returning <code> False </code> where it should have returned <code> True </code>.
* Fixed code generation issue with double constants where code below was not producing the expected result of 1e+030:
<code> value: DOUBLE is 1.0e15
print (value * value) </code>
* Fixed issue in melted code where computation such as <eiffel>INTEGER_X</eiffel> // <eiffel>INTEGER_Y</eiffel> will either crash or give an incorrect computation where X and Y represents integers that are either 8, 16, 32 or 64 bits long and X < Y.
* Fixed incorrect C code generation of finalized code when your project configuration includes a precompiled library and that you cancel finalization process at degree -2, and then restart a finalization.
* Fixed issue with incorrect C code generation of inspect instruction based on character values above 128.
* Fixed compilation crash at degree 3 with following code:
<code> local
i: INTEGER
do
i := << 1 >> @ 2
end</code>
* Fixed a crash in finalized mode with invariant checking enabled with following code and when checking the invariant triggers a garbage collection cycle: <br/>
<code> value: INTEGER
is_value_required: BOOLEAN is
do
Result := value = 1
end
</code>
* Fixed crash of compiler at degree 4 while trying to compile this incorrect class:
<code>class CRASH
inherit
CHAIN -- Missing generic parameter
create
make
feature -- Initialization
make is
do
end
index: INTEGER is
do
end
duplicate (n: INTEGER): like Current is
do
end
end</code>
* Fixed issue with pathological memory allocation scheme that could trigger an `out of memory' exception where enough memory is still available.
* Fixed incorrect allocation of expanded arrays where creation routine of expanded class was not called on all items of the newly created array.
* Fixed incorrect creation type of attribute where attribute's type has some generic parameter. In some cases, instead of creating an <eiffel>ARRAY [B2 [C]]</eiffel> it would create an <eiffel>ARRAY [B2 [STRING]]</eiffel>.
===.NET issues===
* Fixed issue in IL code generation where having a class that inherits from a non-Eiffel .NET class. And the class has the following features:
<code> a: ARRAY [like f]
f: STRING is
do
end</code>
Then you could neither load nor execute the generated code.
* Fixed incorrect C file naming when generating a .NET system that uses a C++ external (it should be .cpp, not just .c).
* Fixed incorrect .NET code generation with following assignment attempts whose source is expanded:
<code> local
a: ANY
o: SYSTEM_OBJECT
do
a ?= 12
o ?= 12
end</code>
* Fixed incorrect code generation in .NET for assertions checking with following code where precondition of <eiffel>test</eiffel> will not be checked although it should:
<code> make is
do
test_which_fail_and_rescued
test
end
test is
require
should_be_checked: False
do
end
test_which_fail_and_rescued is
local
retried: BOOLEAN
do
if not retried then
failure
end
rescue
retried := true;
retry
end
failure is
require
should_be_checked: False
do
end</code>
* Fixed .NET verification issue where sometimes you could get the following message when checking an Eiffel assembly against peverify: [IL]: Error: Unverifiable PE Header/native stub.
* Fixed incorrect code generation when creating and accessing a <eiffel>NATIVE_ARRAY</eiffel> of expanded type.
* Fixed incorrect metadata heap generation to use standard CLI tables.
* Fixed bug where content of <eiffel>NATIVE_ARRAY</eiffel> could not be looked up in .NET debuggers (cordbg, DbgClr or Visual Studio)

80
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki Normal file
View File

@@ -0,0 +1,80 @@
[[Property:title|Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4]]
[[Property:link_title|5..4]]
[[Property:weight|-11]]
[[Property:uuid|2fa36c0f-5b6a-f3f8-67a6-6bd73f63732d]]
==What's new==
* Support for assertion checking on external routines.
* Removed limitation about implementing or redefining a non-external routine by an external one and vice versa.
* Support for new C/C++ inline specification.
* For .NET, allow calling of overloaded features for a .NET classes to be called without using disambiguated names. Disambiguated names are still needed when redefining inherited features from .NET classes.
* Support for inclusion of .NET resources within Eiffel assemblies.
* Launch C compilation when needed if "-c_compile" option is specified on the "ec" command line.
* Added ability to define custom attributes on assembly. One as to define custom attributes under the new `assembly_metadata` index clause of the root class.
* Limited support for new <code> convert </code> keyword (only on argument passing and assignments. Not supported when used with infix routines).
==Improvements==
* Improved speed of compilation by about 20-30%
* Improved run-time memory allocation speed and footprint so that it has a 15%-20% faster allocation scheme and takes less memory than before.
* Reduced waiting time at the end of the degree 6 when performing a compilation from scratch (reduced to about 50% or more of the time it used to take)
* Improved speed of <eiffel>TUPLE</eiffel> creation and <eiffel>TUPLE</eiffel> access which generates more compact C code.
* Improved speed of agent calls by a factor of 2 to 3.
* Improved speed of Eiffel calls from C (CECIL and use of $ operator on routines). It also makes generated executables smaller (about 1-5% smaller depending on number of routines used in this context)
==Changes==
* Changed the way we generate calls to C/C++ external routines. It is possible that because of this change, code that used to C compile, will not compile anymore. This happens mostly when mixing C and C++ code and the C call being made is incorrect but was not previously checked against the C header files if provided.
* In multithreaded mode, all C externals that could potentially block the execution of the system should be marked `blocking` as in: <br/>
<code> sleep (m: INTEGER) is
external
"C blocking"
end</code>
Not doing it could generate dead-lock during the execution of a multithreaded system.
* Static access on externals is now only authorized when external is a frozen external without assertions.
* Compiler will now report a warning for assignments like those: <br/>
<code>td: TUPLE [DOUBLE]
ti: TUPLE [INTEGER]
td := ti</code>
The warning will help you correct code using this pattern, because in the next release this will be rejected in order to conform to the Eiffel programming language specification.
* Now we do not generate by default the .NET attribute <eiffel>ComVisibleAttribute</eiffel> with a False value. If needed it has to be done through the new compiler functionality to add custom attributes on assembly.
* Changed indexing clause tag for specifying custom attributes for .NET systems. Now `attribute` is replaced by `metadata`. Now you can have:
** metadata: generated for both interface and implementation classes
** assembly_metadata: generated for assembly only when specified in root class of system
** class_metadata: generated only for implementation class
** interface_metadata: generated only for interface class
==Bug fixes==
===Language issues===
* Now checks for valid export status in agent creation. Meaning that in class <eiffel>MY_CLASS</eiffel>, the following agent creation <code> agent </code> <eiffel>target</eiffel>. <eiffel>call</eiffel> is valid if and only if <eiffel>call</eiffel> is exported to <eiffel>MY_CLASS</eiffel>.
* Allowed type specification for open operands in agent creation, i.e. one can now write: <code> agent </code> <eiffel>f</eiffel> ({ <eiffel>A</eiffel>}).
* Fixed bug which allowed compiler to accept the following incorrect code: <eiffel>char</eiffel>: <eiffel>CHARACTER</eiffel> <code> is </code> <code> "rdsf" </code>
* Fixed bug in error reporting for incompatible <eiffel>BIT</eiffel> types involving bit manifest constants. It would always report <eiffel>BIT 0</eiffel>, instead of the actual number of bits in the bit manifest constant.
===Compiler issues===
* Fixed non-detection of changes when changing code from <code> agent </code> <eiffel>call </eiffel>to <code> agent </code> <code> Current </code>. <eiffel>call</eiffel>. Which should check for the validity of export of <eiffel>call </eiffel> to current class.
* Fixed creation and assignment attempts on generic types that have anchored types in their generic parameter, and the anchor is itself generic.
===Runtime/code generation issues===
* Fixed issue when shared library definition file did not exist or was invalid. Now it will not produce any C compilation errors.
* Fixed bug in recoverable storable when there is a mismatch. The first assignment attempt in <eiffel>internal_correct_mismatch</eiffel> from <eiffel>ANY</eiffel> would crash.
* Fixed issue when retrieving storable files that contain TUPLE instances.
* Fixed issues when using agents in a multithreaded application, they will sometimes disable the garbage collector and the application might quickly run out of memory.
* Fixed random crashes when EIF_MEMORY_CHUNK, EIF_MEMORY_SCAVENGE and EIF_STACK_CHUNK environment variables had an incorrect value. Instead the runtime will now fix the value to an appropriate one.
===.NET issues===
* Fixed bug in code generation with following statement: <br/>
<code>l_time: TIME_SPAN
print (l_time.total_milliseconds.out)</code>
* Fixed incorrect code generation with code accessing attributes of .NET expanded types.
* Fixed incorrect computation of equal when used with basic types, e.g. equal (1, 1) would return False instead of True.
===Store/Retrieve issues===
* Fixed memory corruption bug with recoverable storable when a mismatch was detected
* Fixed issue where mismatch was not detected if attributes were dropped
* Fixed issue with independent store when storing <eiffel>TUPLE</eiffel> objects where it would crash if storable did not include a reference to <eiffel>ANY</eiffel>.

149
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki Normal file
View File

@@ -0,0 +1,149 @@
[[Property:title|Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5]]
[[Property:link_title|5.5]]
[[Property:weight|-12]]
[[Property:uuid|1d8b9ba7-0609-b664-a4cf-16be1132b071]]
==What's new==
* Full support for new <code>convert</code> keyword.
* Made <code>Void,</code> previously a feature of <eiffel>ANY</eiffel>, a keyword. This prevents the renaming of <eiffel>Void</eiffel> into <eiffel>not_void</eiffel> previously possible when it was a routine of <eiffel>ANY</eiffel>.
* Addition of the <code>reference</code> keyword used in generic constraints (See next point).
* Added support for reference and expanded constraints on a formal generic parameter. In other word, one can now write:
<code>class A [reference G] ... end
class B [expanded G] ... end</code>
to say that the valid actual generic parameters for <eiffel>A</eiffel> are always reference types, and for <eiffel>B</eiffel> are always expanded types.
* Added support for Microsoft .NET 2.0 runtime.
* Allowed agent creation on infix or prefix routines.
==Improvements==
* Reduced, in classic mode, size of finalized executables by 10 to 50%.
* Improved speed of evaluation of global onces, in a multithreaded system, by having a lock-free mechanism after a once has been evaluated.
* Reduced memory usage of special of expanded which do not have any reference attributes. Before there was a 8 bytes (or 16 bytes depending on the platform) overhead per item in the special.
==Changes==
* Compiler is now checking that you cannot redeclare a formal generic parameter into a reference type unless the formal generic parameter is being constraint to be always a reference type (See the '''What's new''' section above).
* Removed obsolete <eiffel>eifcid</eiffel>, <eiffel>eif_expand</eiffel> and <eiffel>eifexp</eiffel>from the CECIL interface, one has to use <eiffel>eif_type_id</eiffel>instead.
* In .NET, changed the naming conventions of resources included in an assembly. The extension `.resources` is appended for resources that are originally provided as `.resx` or `.txt` files. Other files are embedded as is in the assembly and the name of the resource is the name of the file.
* In .NET, now all classes inherit from <eiffel>ANY</eiffel>. Before all classes inherited from <eiffel>SYSTEM_OBJECT</eiffel>. The consequences are:
** You can write an Eiffel generic classes where the actual generic parameter is a .NET class.
** If you used to inherit from .NET classes and Eiffel classes you can replace the inheritance clause below:
<code>class A
inherit
APPLICATION_EXCEPTION
undefine
finalize,
equals,
to_string,
get_hash_code
end
ANY</code>
by the much simpler inheritance clause:
<code>class A
inherit
APPLICATION_EXCEPTION
</code>
** If you were using a feature of <eiffel>SYSTEM_OBJECT</eiffel> directly on Eiffel classes, now you need to assign the value to a variable entity of type <eiffel>SYSTEM_OBJECT</eiffel>. In other word:
<code>e: EIFFEL_CLASS
o: SYSTEM_OBJECT
...
o := e
o.feature_of_system_object</code>
** The following assignment attempt will succeed whereas it failed before because <eiffel>SYSTEM_OBJECT</eiffel> did not inherit from <eiffel>ANY</eiffel>:
<code>a: ANY
o: SYSTEM_OBJECT
...
check o /= Void and a = Void end
a ?= o
check o /= Void and a /= Void end</code>
* New format of the independent storable files which takes into account internal changes made for a better generic conformance in classic mode.
* New validity rule for expanded types: It is valid to use an expanded type of base class <eiffel>C</eiffel> in the text of a class <eiffel>B</eiffel> if and only if it satisfies the following conditions:
** <eiffel>C</eiffel> is not a deferred class
** <eiffel>C</eiffel>'s version of the procedure <eiffel>default_create</eiffel> (inherited from <eiffel>ANY</eiffel>) is one of the creation procedures of <eiffel>C</eiffel> available to <eiffel>B</eiffel> for creation.
* New validity rule for expanded class: An expanded class <eiffel>C</eiffel> needs to have the version of the procedure <eiffel>default_create</eiffel> (inherited from <eiffel>ANY</eiffel>) as one of its creation procedure.
==Bug fixes==
===Language issues===
* Fixed issue about conformance checking of type containing a formal generic parameter. We would always evaluate the formal to its constraint, thus allowing the code below to be accepted where it should not have been:
<code>
class A [G]
feature
bug is
local
l_any: LIST [ANY]
l_g: LIST [G]
do
l_any := l_g
l_g := l_any
end
</code>
The workaround is to use the <code>reference</code> keyword to guarantee that the formal generic parameter will always be instantiated with a reference type. For example the code below is correct:
<code>
class A [reference G]
feature
bug is
local
l_any: LIST [ANY]
l_g: LIST [G]
do
l_any := l_g
l_g ?= l_any
end
</code>
===Compiler issues===
* Enabled creation of <eiffel>SPECIAL</eiffel> instances, no need to create an instance of <eiffel>TO_SPECIAL</eiffel>or <eiffel>ARRAY</eiffel> to get a <eiffel>SPECIAL</eiffel>instance. Now you can simply do:
<code>my_special: SPECIAL [INTEGER]
create my_special.make (10)</code>
* Fixed incrementality issues with <code>strip</code> and static calls on external routines which could fail after a class has been added to or removed from the system.
===Runtime/code generation issues===
* Fixed incorrect code generation which would result in a C compiler error in classic mode when assigning a Void entity to a formal generic parameter that will be instantiated as a basic type.
* In multithreaded mode, fixed dead lock on Unix platforms when evaluating global onces.
* In multithreaded mode, prevented dead lock when a thread is exiting.
* In multithreaded mode, prevented memory corruption which could occur if the first thing that a thread performs when launched is to trigger a GC collection.
* Fixed incorrect generic conformance data when manipulating expanded generic types. For example, the following code:
<code>class A [G, H]
feature
item: H
end
class C [G]
end
class ROOT_CLASS
create
make
feature
make is
local
l_a: A [STRING, expanded C [ANY]]
do
create l_a
io.put_string (l_a.item.generating_type)
end
end
</code>
would print
<code>expanded C [STRING]</code>
instead of
<code>expanded C [ANY]</code>
* Fixed issue where you could get a bogus reference when trying to get a reference to the object associated to an ID (obtained through the <eiffel>IDENTIFIED</eiffel> class).
===.NET issues===
* Fixed incorrect code generation of native arrays which would cause the code to be rejected in newer version of the .NET Framework.
* Fixed incorrect computation of `max_stack` for a routine body which could make the generated code not verifiable.
===Store/Retrieve issues===
* Fix some issues related to the use of recoverable storable when manipulating generic types.

161
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki Normal file
View File

@@ -0,0 +1,161 @@
[[Property:title|Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6]]
[[Property:link_title|5.6]]
[[Property:weight|-13]]
[[Property:uuid|c22fad22-3dce-cf2c-1d24-4e70fc29f3f3]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Implemented once manifest strings. They can be used at the same places where normal manifest strings can be used, e.g.:
<code>s := once "abc"
io.put_string (once "Hello World!")</code>
Once manifest strings are not created every time they are accessed. Instead one instance is created at the first access and then it is reused for subsequent accesses.
==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Implemented once manifest strings. They can be used at the same places where normal manifest strings can be used, e.g.:
<code>s := once "abc"
io.put_string (once "Hello World!")</code>
Once manifest strings are not created every time they are accessed. Instead one instance is created at the first access and then it is reused for subsequent accesses. In multithreaded application one instance is created for one thread.
* Supported aligned and non-aligned verbatim strings. Aligned verbatim strings use characters <code>[</code> and <code>]</code> in opening and closing sequence respectively, non-aligned verbatim strings use <code>{</code> and <code>}</code>.
* Added support for manifest type expression "{<eiffel>MY_TYPE</eiffel>}" which gives an instance of <eiffel>TYPE</eiffel> [<eiffel>MY_TYPE</eiffel>].
* New syntax for manifest constants. Now they can be preceeded by a manifest type expression. For example <code>1</code> is of type <eiffel>INTEGER</eiffel>, whereas {<eiffel>INTEGER_8</eiffel>} 1 is of type <eiffel>INTEGER_8</eiffel>.
* Support for <eiffel>NATURAL_XX</eiffel> types which are unsigned integers.
* Supported new feature alias syntax to specify operator and bracket names:
<code>negate alias "-": like Current ...
multiply alias "*" (other: like Current): like Current ...
item alias "[]" (index: INTEGER): G ...</code>
The first two declarations can be used similar to features <code>prefix "-"</code> and <code>infix "*"</code>. The last one can be used to make feature calls with bracket expressions like
<code>letter := letters [i]</code>
Operator and bracket aliases can also be used in <code>rename</code> subclause to change an alias name associated with a feature.
* Supported new feature assigner syntax to associate feature with an assigner command:
<code>item alias "[]" (index: INTEGER): G assign put ...
put (value: G; index: INTEGER) ...</code>
Given the declaration above the following instructions become equivalent:
<code>x.put (x.item (i + 1), i)
x.item (i) := x.item (i + 1)
x [i] := x [i + 1]</code>
==Improvements==
* Optimized .NET code generated for <code>inspect</code> instruction.
* Optimized access to process-relative once routines to avoid heavy-weight synchronization primitives when possible.
* Speed-up access to once routines in finalized multi-threaded applications.
* Improved some error messages to be more precise.
* Removed the requirement to freeze code that declares process-relative once routine.
* Improved multi-threaded application performance in classic mode by using built-in support for thread-local storage provided by some ''C'' compilers.
* Allowed underscores in hexadecimal literals.
* Provided syntax highlighting for hexadecimal literals in editor.
* Slightly improved reporting of syntax errors.
* Made keyword operator names clickable in flat view.
==Changes==
* Void does not conform to expanded types. As a consequence, assignments of Void to expanded entities will be rejected rather than throwing an exception at run-time. And comparison of expanded entities to Void will cause a <code>VWEQ</code> validity error.
* Changed default behavior of once routines in .NET mode from once-per-process to once-per-thread to match behavior in classic mode.
* Provided project options (<code>old_verbatim_strings</code> and <code>old_verbatim_strings_warning</code>) to support semantics of verbatim strings as in previous versions when they were not left-aligned.
* Changed processing of hexadecimal integer literals to be consistent for different integer types. For example, <code>0xFF</code> gives <code>255</code> when assigned to a variable of type <eiffel>INTEGER</eiffel> rather than <code>-1</code> as before.
* Due to the new {} syntax, a few older syntax constructs have been removed:
** "{<eiffel>X</eiffel>} <code>Precursor</code> (..)" is rejected and should be replaced by "<code>Precursor</code> {<eiffel>X</eiffel>} (...)".
** "<code>agent</code> <eiffel>f</eiffel> (?, {<eiffel>A</eiffel>})" is now rejected, as it would conflict with a manifest type expression, instead you should write "<code>agent</code> <eiffel>f </eiffel>(?, {<eiffel>A</eiffel>} ?)".
* In .NET, all usage of <eiffel>INTEGER_8</eiffel> from .NET libraries have been changed to <eiffel>NATURAL_8</eiffel>.
* In .NET, renamed <eiffel>TYPE</eiffel>, <eiffel>ATTRIBUTE_</eiffel> and <eiffel>VOID_</eiffel> from the mscorlib assembly into <eiffel>SYSTEM_TYPE</eiffel>, <eiffel>SYSTEM_ATTRIBUTE</eiffel> and <eiffel>SYSTEM_VOID</eiffel>.
* Changed exception handling for once routines so that exception raised during the first call is raised during any subsequent call to this routine.
* Introduced upper limit for value of integer constant used in <code>BIT</code> type declaration and extended <code>VTBT</code> rule to cover this change.
* To evaluate the type of a manifest array we now use the first item of the manifest array instead of the last one as a first guessed type.
* Allowed for integer literals with intermediate underscores at arbitrary positions.
* To ensure same behavior on various platforms, the standard output is now unbuffered (it previously was unbuffered on Windows and line buffered on Unix platforms).
==Bug fixes==
===Language issues===
* Used <code>'%N'</code> as an end of line in verbatim strings regardless of the end of line sequence in source code.
* Fixed incorrect handling of negative hexadecimal integer literals when sign before the literal was not taken into account. For example, <code>-0x1</code> could be interpreted as <code>1</code>.
* Implemented checks for input ranges of integer constants and fixed issue with inability to assign minimum integer values to variables of the corresponding integer types.
{|
|+ Allowed integer values
|-
| Type
| Integer interval
| Unsigned hexadecimal representation
|-
| <eiffel>INTEGER_8</eiffel>
| <code>-128 .. 127</code>
| <code>0x0 .. 0xFF</code>
|-
| <eiffel>INTEGER_16</eiffel>
| <code>-32768 .. 32767</code>
| <code>0x0 .. 0xFFFF</code>
|-
| <eiffel>INTEGER_32</eiffel>
| <code>-2147483648 .. 2147483647</code>
| <code>0x0 .. 0xFFFFFFFF</code>
|-
| <eiffel>INTEGER_64</eiffel>
| <code>-9223372036854775808 .. 9223372036854775807</code>
| <code>0x0 .. 0xFFFFFFFFFFFFFFFF</code>
|}
* Excluded nonsignificant leading zeroes from determination of allowed integer constant type, so that <code>00000000000000123</code> is now a valid <eiffel>INTEGER_8</eiffel> value.
* Shared the same data accross once routines and string constant attributes from different generic derivations of the same class. Added a warning for once routines that appear in a generic class to notify about this change in semantics.
* Correctly supported replication of once features when compiling for .NET.
* Changed order of evaluation of once routines to check precondition with class invariant even when once routine has already been called.
* Added a check that length of identifier, manifest string and free operator does not exceed a maximum value of 32767 bytes.
===Compiler issues===
* Fixed crash of the compiler at the very end of a finalization of a system which has an assignment of a manifest type into a variable of type <eiffel>ARRAY</eiffel> [<code>like</code> <eiffel>anchor</eiffel>] where <eiffel>anchor</eiffel> is a feature being redefined with a different type in a descendant class.
* Fixed an issue where compiler would report more than once the same error in an incremental recompilation.
* Fixed issue where changing a normal routine to an external and having a compile error, and then reverting back to a normal routine while fixing the error would cause the compiler to crash.
* Fixed some cases where project could be corrupted after a recompilation.
* Now compiler reports <code>VTCT</code> errors at the end of degree 5, rather than during degree 5, so that you can collect all the <code>VTCT</code> errors at once.
* Thanks to the improvement in <code>VTCT</code> errors reporting, now compiler will not generate an incorrect <code>VTCT</code> errors during an incremental recompilation for a class which has actually been removed from the system.
* Supported recompilation of once routines when their status is changed from "process-relative" to "thread-relative" or back.
* Supported output of multi-line obsolete messages.
* Fixed a recompilation bug that resulted in incorrect (or even, in case of .NET, in invalid) generated code when incrementally finalizing a system without explicitly specified root creation procedure.
* Fixed a bug with resolving some generic-like types (i.e., types that are processed in a special way: tuple, native array, typed pointer) that depend on anchored types: before they were converted to "normal" generic types thus loosing their special properties.
* Fixed a bug that caused compiler to crash when finalizing a code that looks like
<code>if true then [else(if) ...] end</code>
i.e. has empty compound for a primary condition which is a constant <code>true</code>.
* Fixed a bug in processing configuration option <code>precompiled</code> that caused a compiler to crash when no option value was provided.
* Fixed a bug in incremental recompilation when multi-branch validity rules are violated in one class because constant attribute used in the multi-branch instruction is changed in another class, that declares them, into a non-constant feature.
* Fixed multiple bugs in feature basic text view that caused truncated or extraneous output.
* Fixed bug where if an actual generic parameter was an anchor, then if the type containing this actual was used for assignment attempt or for creation we would use an incorrect type for the actual generic. We were using the type of the anchor in the class were the code was written, instead of actually re-evaluating the type of the anchor for each descendant class.
===Runtime/code generation issues===
* Fixed bug in <eiffel>deep_twin</eiffel> from <eiffel>ANY</eiffel> in .NET which would cause a call on Void target when applied on object of type <eiffel>STRING</eiffel> and possibly other types.
* Corrected C code on Windows for constants of type <eiffel>INTEGER_64</eiffel>. Before constants of this type between <code>-2147483648</code> and <code>-1</code> could be processed as positive 64-bit values.
* Fixed incorrect C and IL code generation for <eiffel>INTEGER_8</eiffel> and <eiffel>INTEGER_16</eiffel> arithmetic and shift operations that might produce incorrect result when combined in two or more operations in a row. For example,
<code>i := (i + i) |>> 1</code>
assigned <code>-128</code> to <code>i</code> of type <eiffel>INTEGER_8</eiffel> if the initial value of <code>i</code> was <code>-128</code>. Now this instruction assigns <code>0</code>.
* Synchronized access to data of process-relative once routines to avoid race conditions when two or more threads simultaneously access the same once routine.
* Avoided permanent blocking of a thread accessing process-relative once routine when this routine is concurrently evaluated in some other thread and raises an exception.
* Fixed bugs in memory allocation in C code for result of a once function that returns basic type:
** it might cause memory corruption when memory size required to store the result is greater than size of a pointer;
** there was a memory leak.
* Fixed a bug in classic mode that caused last exception to be cleared after returning from a routine that has a rescue clause but returns normally.
* Fixed several bugs related to handling of nested exceptions in classic mode.
* Changed a limit of maximum class name length in melted byte code from 256 bytes to 32767 bytes.
* Changed C code generation for long strings (that result from long manifest strings, identifiers, etc.) to avoid restrictions imposed by some C compilers on long string literals (in particular, by the Microsoft C compiler <code>cl</code> that issued error C2026).
* Fixed a bug in finalized C code generation when calling <code>Precursor</code> in a routine which is recursively calling itself before the call to <code>Precursor</code>. Instead of generating the call to <code>Precursor</code> we would generate a recursive call to the routine.
* Fixed a bug where calls to <eiffel>standard_is_equal</eiffel> from <eiffel>ANY</eiffel> on objects whose type is generic would yield <code>False</code> where it should have been <code>True</code>.
===.NET issues===
* Corrected processing of literal floating point fields from external assemblies (such as <eiffel>System</eiffel><code>.</code><eiffel>Math</eiffel><code>.</code><eiffel>PI</eiffel>) to obtain proper values.
* Fixed a bug where the value -1 was actually 255 on .NET.
* Fixed issue where declaring a <eiffel>NATIVE_ARRAY</eiffel> of a .NET expanded type would be rejected by the compiler.
* Fixed issue where assigning a .NET expanded type to an entity of type <eiffel>ANY</eiffel> would be rejected by the compiler.
* Fixed a crash in the compiler when generating the code for a class which inherits from a .NET class and from an Eiffel class which has some anchored types.
* Fixed a bug in assertion monitoring that could lead to wrong monitoring of assertions that are evaluated concurrently in different threads.
* Fixed a bug in code generation for entry point of executable when root procedure is a redeclaration of a deferred feature that caused an exception <code>MissingMethodException</code> to be raised on startup of such an application.
* Fixed a bug in code generation when solely inheriting from a .NET interface.
* Fixed a bug in code generation when inheriting from a .NET class which has a routine whose name is identical to one of the routine of <eiffel>ANY</eiffel>.
* Fixed a bug in code generation of custom attributes encoding in the case of a named argument whose base type is a .NET enum type.
* Improved <eiffel>conforms_to</eiffel> from <eiffel>ANY</eiffel> so that even though full generic conformance is still not yet supported, it checks it properly when the base class are the same.
===Store/Retrieve issues===
* Fixed an issue where the GC would be disabled after a failure in a retrieval operation.

68
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki Normal file
View File

@@ -0,0 +1,68 @@
[[Property:title|Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7]]
[[Property:link_title|5.7]]
[[Property:weight|-14]]
[[Property:uuid|fc50f98f-4dfd-0173-23d4-9db219dde0cf]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Support for new expanded semantics defined in ECMA-367. The current limitations are: no copy semantics in the .NET code generation, and still no generic conformance.
* Inline agents as defined in ECMA-367 with the limitation to only accept the do form.
* Added possibility to define agents on attributes or externals.
* Named tuples as defined in ECMA-367.
* Added <eiffel>PREDICATE</eiffel> class for agent based on boolean queries.
* Added <eiffel>CHARACTER_32</eiffel> for Unicode support.
==Improvements==
* Improved memory management:
** Ensure that if a block of allocated memory is not used it will eventually be freed. Before it will only be freed if it was the last allocated block.
** Compaction is actually working. Before it was working if you had a lot of dead objects, now it will compact even if all you have is alive objects and that the memory is fragmented.
** For large memory heap (i.e. larger than 1GB) improved speed of collections where there is a lot of dead objects.
* Changed the way we search melted file, it is done in the following order:
** Directory specified by environment parameter MELT_PATH
** Current working directory
** Directory where application is launched
** Original directory where .melted file was generated the first time.
* Improved speed of initial compilation of .NET projects as well as the speed for incremental compilation at degree 6 which went from a few seconds to no time if no new assemblies have been added to the system.
* No freeze is required when adding an agent, saving you time since C compilation can be long for very large project.
* Reduced the required disk space for a workbench compilation in classic mode (went from 1.8 GB to 1GB for a very large project).
* Improved speed of agent calls in classic mode.
* Support use of IL enumerations with underlying integer types different from System.Int32. In particular, the built-in features `to_integer` and `from_integer` now use the underlying type rather than System.Int32.
* Support generation of IL properties as well as custom attributes for them.
* Support the new syntax without the <code>is</code> keyword in the feature declaration.
* Allowed bracket expressions to be used as a target of a qualified feature call (this is an extension to ECMA standard that does not permit this syntax at the moment).
* Added checks for <code>VYCP(2,3)</code> and <code>VYCQ(2,3)</code> (validity rules for conversion features to prohibit conversion to conforming types).
==Changes==
* <code>VWEQ</code> is not an error, but a warning that can be triggered or not depending on your configuration.
* Inherited assertions are rechecked each time that a feature is redefined, meaning that some errors that were not previously detected by the compiler can now be found.
==Bug fixes==
* Fixed an issue with x2c if you had inlined C code which contains comments with single or double quote. Then it will not properly convert .x into .c file.
* Fixed bugs in code generation for once manifest strings that caused "index out of bounds" exception, void results.
* Fixed a bug in processing synonyms of a routine with an indexing clause that might cause a compiler crash, in particular this could happen for synonyms of a global once routine.
* Fixed a bug in recompilation of a once routine that changes its process-relative status into thread-relative one or back in multithreaded finalized mode that can cause C compilation to fail due to unresolved externals.
* Corrected inlining of routines redeclared into attributes or into routines with a different internal/external status.
* Fixed a bug in incremental recompilation of queries with assigner commands.
* Added detection of a <code>VUEX</code> error for static feature calls used in intervals of a multibranch instruction.
===Compiler issues===
* Added a new validity error <code>VTEC(3)</code> to report unsupported inheritance hierarchy under .NET when an expanded type is based on a class with an external ancestor.
* Not supported reverse attachment of boxed built-in .NET value types to Eiffel reference types such as <eiffel>NUMERIC</eiffel>, <eiffel>HASHABLE</eiffel>, etc.
===Runtime/code generation issues===
* Ensured that our runtime is async-safe for signals for all the runtime routines using some locking mechanisms.
* Fixed a memory corruption issue in <eiffel>arycpy</eiffel> if a GC cycle was triggered as part of the processus of reallocating the SPECIAL object.
* Fixed a bug with allocating memory for once routines that caused "no memory" exception at program startup when Borland run-time is used.
===.NET issues===
* Removed limitation to inherit an Eiffel class which inherited from a .NET class.
===Store/Retrieve issues===
* Fixed a memory leak in the recoverable retrieval when an exception is raised from a <eiffel>correct_mismatch</eiffel> routine call.
* Fixed test#store008 regarding a crash when retrieving a type that does not exist in retrieved system.

6
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/index.wiki Normal file
View File

@@ -0,0 +1,6 @@
[[Property:title|EiffelStudio 6 compiler history]]
[[Property:link_title|6.x]]
[[Property:weight|14]]
[[Property:uuid|62e7ba4a-0db5-1e46-0097-73313657a7ca]]

72
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki Normal file
View File

@@ -0,0 +1,72 @@
[[Property:title|Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0]]
[[Property:link_title|6.0]]
[[Property:weight|-7]]
[[Property:uuid|83f6c19c-b0da-6acb-0333-a92d445cfe56]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Added support for multiple constraints in formal generic parameters.
* The root class can now be a generic class, and thus one can now specify a root type.
* The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented.
* Added experimental option for full class checking. It can be enabled at the system, cluster or class level. However not all our code has been compiled with this option so don't be surprised if you get errors in our libraries. The next release should fix all the remaining issues.
* Integers can now also be specified with binary and octal representation.
* Manifest characters can now also be specified with binary, octal and hexadecimal representation. Manifest characters can be specified up to 32 Bit.
* Supported reattachment of generic derivations with expanded parameters to generic derivations with reference parameters.
==Improvements==
* The command line compiler doesn't need a configuration file to compile a system, one can simply provide a root class and the compiler will automatically use the current directory and EiffelBase. You can also add more libraries if needed.
* Improved backup mechanism so that overridden classes are copied in the library where they are defined (they were previously copied in the library where the override cluster was defined).
* Possibility for hidden/implementation clusters in libraries, i.e. clusters that are not accessible if the library is used (like libraries in libraries are not accessible).
* Class names which don't match the source filename emit a warning.
* The unique keyword will yield a syntax warning if enabled.
* Static access on external routines is allowed even if not marked frozen (this simply applies a relaxed rule that was adopted by ECMA).
* When an environment variable is being used to compile a system and if this environment variable value changes next time you use a project, you will get a prompt asking whether or not you want to update the value or keep the initial one.
* Externals (includes, objects, resources, ...) can now be relative to the ecf file by using the new replacement $ECF_CONFIG_PATH.
* UUID is not needed for non library systems. If no UUID is specified a random one will be generated.
==Changes==
* Added supplier_precondition assertion level that enables to only check preconditions of trusted libraries. By default when importing an old project they are not enabled, thus assertions on the library you are using are most likely going to be disabled.
* Added the platform value as part of the version info of the compiler. This will prevent trying to load a project compiled for a different platform instead of failing with a retrieval error.
* The compiler can be compiled against the original EiffelBase version or with the FreeELKS version which is now the default one for EiffelBase.
==Bug fixes==
* Fixed eweasel test#tuple006 showing a failure when calling <eiffel>deep_copy</eiffel> on a <eiffel>TUPLE</eiffel> instance.
* Fixed bug#12782 where compiler would crash at degree 1 when removing a formal generic parameter of class (eweasel test#incr249 and test#incr284).
* Fixed bug#12823 where specifying in the command line a target in a different case than the lower case version of the actual target name would fail to find the target in your configuration file.
* Fixed bug#12698 where compiler was not processing the target extension properly if not specified in lower case.
* Fixed bug#12591: compiler would not find classes from library referenced deeply using relative path. This also removes the extra `.` or `..` in the displayed path for a class.
* Fixed issue with incorrect labeled tuples which were not detected in signature of features (see eweasel test#tuple008).
* Fixed crash when checking an incorrect labeled tuple (e.g. <eiffel>TUPLE</eiffel> [a, a: <eiffel>INTEGER</eiffel>]) (see eweasel test#tuple009).
* Fixed issue with inline agents where if you have one and during a compilation from scratch you have a compiler error, then fixing this error and recompiling, it would crash when melting or freezing (test#incr277).
* Fixed issue with C compilation linking error when a generic class which have an invariant clause has its formal generics changed (test#incr278).
* Fixed C compilation error on Windows for trying to compile empties Cxxx directories (test#ccomp061).
* Fixed incorrect code generation of agents on attribute when target is open (test#exec264).
* Fixed incremental bug when an agent creation based on a feature whose signature changes for less arguments (test#incr276).
* Fixed a backup creation bug when two classes from the same cluster/library have the same original file name, the backup would only contain one or the other because we use the original file name. Now we use the original class name.
* Fixed various issues with the processing of the Eiffel Configuration File.
===Compiler issues===
* Adapted the compiler so that ISE_EIFFEL does not need to be defined with a short path name on Windows, since some file systems can disable support for short path.
* Fixed incrementality bug with agents where finalizing and then freezing would cause some unresolved externals.
===Runtime/code generation issues===
* Fixed a memory corruption which would occur once an invariant has been violated.
* Fixed a memory corruption which could occur when performing a deep_twin on an object whose graph contains a TUPLE object. See test#tuple006.
===.NET issues===
* Speed up consumer cache synchronization so working with large .NET caches or large assembly sets is much faster.
* Fixed bug#12565 where a wrong EIFFEL_NAME_ATTRIBUTE custom attribute would be generated on .NET for Eiffel generic class where the actual generic parameter is a .NET value type..
* Fixed bug in .NET resx to resource generation when using resx files with relative paths.
* .NET Enums can be automatically converted to INTEGERs.
* Indexing tags ''interface_metadata'' and ''class_metadata'' are supported on feature level like this is done on class level and allow to specify custom attributes for associated methods only in interface type or only in implementation type.
* All versioned COM import interfaces now have versioned interface member names based on the trailing version number of the interface name, as this meta information is not available in any other way. This greatly improves the versioned names and makes implementing interfaces much easier.
* Fixed various issues in the .NET consumer that would prevent the usage of certain .NET assemblies.
* Added configurable (project to class-level) optimization for .NET project that will mark all classes frozen if they are not descended by another.
===Store/Retrieve issues===
* Now the retrieval of objects is done with the GC (garbage collector) disabled.
* Fixed issue when retrieving 64-bit storables on 32-bit machines. It requires a regeneration of the 64-bit storables if one wants to retrieve them on 32-bit machines. Fixed bug#11744.

51
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki Normal file
View File

@@ -0,0 +1,51 @@
[[Property:title|Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1]]
[[Property:link_title|6.1]]
[[Property:weight|-8]]
[[Property:uuid|32beeca8-08df-4918-b231-8a14114fdd62]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Multiple errors are reported for each compilation degree.
* Experimental support for Non-conforming Inheritance has been added (Classic only). Classes may now be inherited (using inherit {NONE} but no conformance of that class is implied.
* Attachment marks are supported. Now it's possible to specify whether an entity is attached or detachable:
<code>a: !A -- a cannot be used before it is attached
b: ?A -- b can be used before it is attached</code>
Default attachment status (for types without an attachment mark) is controlled by the option ''is_attached_by_default''.
* Object test expression is a replacement for the reverse assignment construct with a new notion of scope:
<code>if {o: !A} e then do_something_with (o) end</code>
* Attached variables are subject to the new check that they are properly set before use, in particular, attached attributes must be set by a creation procedure and all attached local variables must be set before they are used. The checks are performed when the option ''is_void_safe'' is turned on.
* A feature call can be performed only on an attached target if the option ''is_void_safe'' is turned on.
* Certified attachment patterns (CAP) are used to identify additional cases when an entity is attached (controlled by the option ''is_void_safe''). In particular, the following code is considered void-safe:
<code>f (a: ?ANY)
do
if a /= void then
x := a.out
end
end</code>
==Improvements==
* Improved speed of degree 3. Improvements are even more visible when the checking of inherited features in their descendants is enabled.
==Changes==
* No major known changes.
==Bug fixes==
* Fixed an issue where the version of <eiffel>default_create</eiffel> from <eiffel>ANY</eiffel> would not yield a dynamic binding if statically it had an empty body (See test#exec280).
===Compiler issues===
* The options ''is_void_safe'' and ''is_attached_by_default'' are not tracked during recompilation, so in order to take any changes in their settings, the project has to be recompiled from scratch.
* Object test is not permitted inside a precondition or a check instruction.
* Object tests inside a feature should use different names for the corresponding locals.
===Runtime/code generation issues===
* Non-conforming inheritance dynamic conformance only works with Classic compilations, for .Net non-conforming inheritance has no effect on code generation
* Implemented time accounting on Windows.
===Store/Retrieve issues===
* Fixed a potential dead lock when an exception occurs while retrieving an object in a multithreaded environment (See test#store012).

53
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki Normal file
View File

@@ -0,0 +1,53 @@
[[Property:title|Major changes between ISE Eiffel 6.1 and ISE Eiffel 6.2]]
[[Property:link_title|6.2]]
[[Property:weight|-9]]
[[Property:uuid|20122f4c-22c6-d0ee-c38b-36908ca86ad2]]
==What's new==
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Exceptions as objects are now implemented.
* Added support for new ~ operator which can compare 2 objects safely regardless of their type.
* Added detection of harmful catcall at runtime (harmless ones are currently ignored).
* Added support for `note` keyword with a migration path in case `note` is being used as an identifier in your code.
* Added `-gc_stats` option to get some information on how much CPU time is spent in GC during an Eiffel compilation.
* Introduced several new much more powerful CAPs that now can be applied not only to read-only entities, but also to local variables (including <code>Result</code>), and can take into account execution paths as well as some obvious void-safe patterns.
==Improvements==
* Improved speed of compiler by a significant factor for large system.
* Generated code is about 3-4% faster with a size reduction of about 2-3%.
* Improved number of dynamic to static bindings in finalized code. Improved quality of inlined code for reducing even more of the dynamic calls.
* Reduced the size of the AST stored in memory during a compilation by 20/25% which results in a memory usage reduction for EiffelStudio of about 15%. For example when compiling EiffelStudio on Windows 64-bit, it was taking 920MB with the previous version, and now it would be 800MB.
* Fixed performance issue with {<eiffel>SPECIAL</eiffel>}.<eiffel>clear_all</eiffel> when handling a special of reference.
* Removed <code>VUOT(2)</code> that required that the type of an object test local is attached.
==Changes==
* Protected several calls to `eif_wean` on the same EIF_OBJECT. This will prevent a memory corruption for people using it incorrectly with a minor slow down since in a typical application there should not be too many protected objects.
* Removed <code>VFAV(4)</code> validity error that is no longer specified in the standard.
* Due to new meaning of ~, the old syntax for agents is not being supported anymore. If you still have some code using the old agent syntax, compile it with 6.1 with syntax warning enabled to fix your code before upgrading to 6.2.
==Bug fixes==
===Language issues===
* Fixed various limitations with support of attached types in 6.1, including support for
** attachment marks for tuple types and formal generics
** object tests in class invariants
===Compiler issues===
* Fixed eweasel test#final046 by avoiding useless creation of temporary objects during dynamic dispatch. It can also dramatically speed up certain kinds of code; on the compiler itself, the speed up is about 8-10%. In the worst case scenario it is 400% or more. Note this bug was introduced in version 6.0. Compared to 5.7, in 6.2 the worst case scenario is still about 10% slower.
* Fixed an incorrect code generation for `is_equal` in ANY when exception trace is off which could cause a memory corruption.
* Fixed various issues with compiler when inlining is enabled.
* Fixed compiler crash when compiling a class where a type used in a signature of a feature has the wrong number of generic parameters. Fixed eweasel test#incr285.
* Fixed an incorrect code generation for the dynamic binding of routines defined in generic classes and attribute access in general. Fixed eweasel test#exec272 and test#final039.
* Fixed eweasel test#melt081 where having a redefined routine involving an anchor to a non-existing feature would crash the compiler instead of reporting a VEEN error.
* Various bug fixes with respect of handling of expanded generic classes used in generic classes.
===Runtime/code generation issues===
* Changed the usage of `eif_adopt`, `eif_protect`, `eif_wean`, `eif_freeze` and `eif_unfreeze` so that they can be used in concurrent thread, meaning that it is safe to use them as long as the argument is different in various threads.
===Store/Retrieve issues===
* Fixed some issues with the storing or retrieving of generic expanded types.

62
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-62-and-ise-eiffel-63.wiki Normal file
View File

@@ -0,0 +1,62 @@
[[Property:title|Major changes between ISE Eiffel 6.2 and ISE Eiffel 6.3]]
[[Property:link_title|6.3]]
[[Property:weight|-10]]
[[Property:uuid|55a1c34d-5313-1bcc-924e-3a3a68905665]]
==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Implemented proper runtime conformance for attached types, that is to say A [!ANY] will conform to A [!ANY] or A [?ANY], but A [?ANY] will only conform to A [?ANY].
* Added support for the new <eiffel>attribute</eiffel> keyword (support is enabled when using the standard syntax option, i.e. the same option that allows you to use the <eiffel>note</eiffel> keyword.
==Improvements==
* Improved speed of compiler by about 10% overall.
* Reduced memory usage at runtime of Eiffel applications (on EiffelStudio itself it is about 30MB over 100MB).
==Changes==
* Changed the way files are opened on Windows by ensuring that they cannot be inherited by child processes. This was necessary since one would need to wait for the child process to exit to remove files owned by the parent process.
* Compiler now accepts the new syntax for variant in a loop (i.e. before the <eiffel>end</eiffel> keyword).
* Fixed missing detection of VREG and VRFT errors for labels of a named tuples which is used as an actual generic parameter of a type (fixes eweasel test#tuple012 and test#tuple013), thus some of your code might be broken since the compiler failed to check this before.
* Fixed eweasel test#valid222 where compiler properly detects VDRS-4 errors when you redefine a repeatedly inherited routine in at least one but not all branches, but fail to provide a local definition.
* Now a formal generic parameter only conforms to a formal generic parameter, that is to say assignment to a formal generic parameter where the source is of type NONE (i.e <eiffel>Void</eiffel>) will now be rejected by the compiler.
* Dropped support for older Microsoft C/C++ compilers on Windows platforms. We only support VS 2005 or greater.
==Bug fixes==
===Language issues===
* Fixed compiler issues with handling of attached types.
===Compiler issues===
* Renamed `eif_com.h` from the compiler delivery into `eif_com_exception.h` as it conflicts with `eif_com.h` from the EiffelCOM library.
* Fixed eweasel test#final061 and test#final063 where some kind of code could cause a crash of the compiler during degree -3 with inlining enabled.
* Fixed eweasel test#final063 which caused a C compiler error when your code uses an inline agent in an assertion and the routine in which it is defined is deferred.
* Fixed Makefile code generation issue on machine with many cores which could cause a C compilation error because some dependencies are missing in the Makefile targets.
* Fixed bug#13881 where if you have a VKCN error when using a routine whose return type is a like argument then it would crash instead of reporting the VKCN error. Improved VKCN error reporting by providing the instruction or expression which causes the problem.
* Fixed eweasel test#rdtp001 and test#term158 where if TUPLE is not written using upper case characters, then the compiler will crash when trying to analyze the type.
* Fixed the issue found with GCC 4.x series where an assignment of the form *(a + x) = f() would first evaluate (a+x) and then `f` which could cause a memory corruption if `f` triggers a GC cycle. As far as we could tell, this kind of code generation was only done when `f` would return a basic type. See eweasel test#runtime007.
* Fixed eweasel test#ccomp076 where C/C++ inlines did not get the protected object if any, but only the unprotected one which could cause some issue if the C/C++ inline code uses `eif_access` or `eif_adopt`.
* Fixed various issues with the `full class checking` option that would not work for inherited code involving conversion or labeled tuples (see eweasel test#svalid001, test#svalid007, test#svalid009 and test#svalid010).
* Fixed bug#14856 and test#final064 where if before generating the agent call/item routine we generated a call to a deferred routine without implementation we would not generate the arguments of the agent causing a C compilation error in finalized mode.
* Fixed improper runtime semantics for creation of manifest tuples, arrays and agents (see eweasel test#tuple011, test#tuple014 and test#agent006)
* Fixed eweasel test#term159 where the compiler would crash if there is a conversion for one of the closed argument of an agent creation.
* Fixed some inlining problem of routines that may return an expanded type (fixes eweasel test#final065 and test#exec147).
* Fixed C compilation error when using CECIL on system using gcc 3.4 or greater as the later generated an abort sequence rather than calling a feature. Partially improves eweasel test#ccomp063 behavior.
* Fixed eweasel test#agent005 where some large agent signature would cause a crash in the compiler.
* Fixed eweasel test#syntax050 where the compiler incorrectly valid code using an assigner where the target is a parenthesized expression (e.g. <eiffel>(create {A}).item := b</eiffel>).
* Fixed an issue with the DLL specification which would not allow hyphen in the name of a DLL.
* Fixed eweasel test#exec287 where if you assigned a basic type (INTEGER, CHARACTER, ...) to a TUPLE entry expecting a reference type and that you were assigning it via its assigner (<eiffel>t.field := value</eiffel>) then it would generate incorrect code causing a crash at runtime.
===Runtime/code generation issues===
* When registering externally created threads, make sure that the runtime does not exit them when no more Eiffel code needs to be run as it must be done by the code that created it. Also made sure that the runtime per thread data are reset to 0 to ensure that we can register/unregister the external thread as many times as needed.
* Fixed a buffer overflow that would occur on some Unix platforms when a signal was received by the application.
* Fixed eweasel test#thread006 where if many threads allocate small objects which are quickly dying then we could break the runtime synchronization and cause a crash.
* Added a cast to ensure that `eif_globals` can compile properly in C++ mode.
* Fixed eweasel test#runtime008 where we have a leak on each created thread if invariants are monitored.
* Fixed eweasel test#runtime009 where a reallocation of a SPECIAL object could cause a memory corruption.
* Fixed various issues with exceptions (performance, failure when reporting invariant, added I/O reason to exception object, extended stack traces up to the root class, rather than stopping at the first rescue clause).
===Store/Retrieve issues===
* Fixed a dead lock in a multithreaded application when a store operation fails to store data to a stream.
* Changed the independent store version number due to the usage of ! and ? in Eiffel code. Meaning that storables created by 6.3 cannot be read by older versions of EiffelStudio.

78
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-63-and-ise-eiffel-64.wiki Normal file
View File

@@ -0,0 +1,78 @@
[[Property:title|Major changes between ISE Eiffel 6.3 and ISE Eiffel 6.4]]
[[Property:link_title|6.4]]
[[Property:weight|-11]]
[[Property:uuid|08206c9f-42fc-d007-ca09-4cf6a42207c2]]
==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Added new compiler command line options: '''-experiment''' and '''-compat'''. The '''-compat''' option has no effect in 6.4. The '''-experiment''' option changes the internal value of $ISE_LIBRARY to look for libraries under $ISE_EIFFEL/experimental/library. Those libraries are truly void-safe with respect to ARRAY/SPECIAL and because of that change, might break your existing code. In 6.5, the experimental libraries will become the default libraries. So, you are encouraged to take steps to ensure that your code will compile with the experimental libraries. We have made it possible to compile the same code under both sets of libraries. This should facilitate testing.
* Added support for iPhone platform.
* Added support for the new syntax for object test, i.e. "<eiffel>attached {T} expr as u</eiffel>" instead of "<code>{u: T} expr</code>".
* Added free syntax for '''stable''' attributes; the final syntax is being discussed by the ECMA committee. Stable attribute is an attribute of a detachable type that is never assigned void. This property makes it possible to apply to it most of the CAP rules suitable for read-only entities. The stable attributes can be declared using value '''stable''' of the <eiffel>note</eiffel> tag option, for example:<eiffel>
a: detachable MY_TYPE note option: stable attribute end
</eiffel>
==Improvements==
* Added support for multiple object tests using the same object test local name in a single feature, provided that their scopes do not intersect.
* Made precompilations work on Mac OS X.
* Improved inlining of deferred routines implemented as attributes or constants in INLINER by allowing their inlining.
* Added support for detecting Mac OS X and VxWorks target compilation.
* Improved C compilation speed of E1/eskelet.c in workbench mode when using VS 2005 C++ for 64-bit. We went from a benchmark of 3 minutes down to 1 minute. This is definitely caused by a bug in VS, because the 32-bit version compiles the same code in just a matter of a few seconds. Microsoft reports having a fix for this in VS 2010.
* Fixed bug#15343 where backups were very large if you referenced many .NET assemblies even when not compiling for .NET.
* Attached attribute initialization in creation procedures is now detected not only by inspecting the top-level instructions, but also the nested complex instructions with several possible execution paths, like conditional instruction, multi-branch, etc.
* Improved degree 6 performance by not examining the content of all .e files to determine the associated class name. We now assume on the first pass that the file name is the class name. On EiffelStudio, if none of the files were buffered, we went from about 1 minute spent to just less than 3 seconds. The improvement should be even more visible when classes are on a remote drive.
* Fixed eweasel test#runtime010 where certain allocation patterns could cause a major slow down during a garbage collection cycle.
==Changes==
* Ensured that particular options specified in a library cannot be overridden in a project, because they apply to the source code (e.g., specify a variant of a syntax) rather than to the code generation (e.g., specify which assertions have to be monitored).
* Removed usage of infix/prefix in most of the libraries. To ease transition, added a compatibility option that allows existing code using the infix/prefix notation to continue to compile.
* Attachment status of formal generic constraints are now taken into account when checking conformance and detecting VUTA errors when target type is a formal generic. '''Important''': default attachment status of the constraints follows the "attached-by-default" setting, so the code might need to be updated by adding a detachable mark in front of the formal generic constraints if the actual generic parameters can be detachable types.
* The compiler does not produce the class progress output in batch mode. The old behavior is available by using the '''-verbose''' option.
* Fixed incorrect display of NATURAL_32 attributes when calling `out` (fixes eweasel test#exec298 and bug#13862.)
==Bug fixes==
===Language issues===
* Renamed VUPR errors to their ECMA name VDPR.
* Better explanation for VDPR(3) errors when two or more precursors are available, by listing all the precursors.
* Non-void arguments are now detected not only when they are specified in the voidness tests in immediate preconditions, but also in inherited ones.
* Fixed missing detection of VRFT errors in cases like "<eiffel>a: TUPLE [a: TUPLE [out: INTEGER]]</eiffel>".
===Compiler issues===
* Incremented ECF XML schema version to reflect the recent changes.
* Replaced ECF schema attribute syntax_level of an integer type with syntax of a string type that contains one of the three possible values.
* Replaced ECF schema attribute is_void_safe of a boolean type with void_safety of a string type that contains one of the three possible values ('''none''': no void-safety checks; '''all''':all void-safety checks; '''initialization''': on-demand void-safety checks, i.e. only for entities that are attached).
* Fixed eweasel test#syntax042 and test#syntax047 as well as bug#15514 that allowed invalid characters in new C external specification. Removed generation of error when trying the old syntax, the syntax error will be based in the new syntax now.
* Fixed eweasel test#agent004 and test#agent010 by ensuring the result type of the agent is properly instantiated in the agent target type context.
* Fixed missing reporting of VEVI error for attributes initialized from a creation procedure by calling a once routine because the latter is not guaranteed to be executed on subsequent calls.
* Fixed eweasel test#incr322 and test#final079 where compiler would crash when a routine was implemented as an attribute that can be access statically in final mode.
* Fixed eweasel test#incr322 and test#final079 which caused a crash during finalization of a call to a deferred routine implemented as an attribute with a body or some assertions.
* Fixed eweasel test#melt085 and test#melt086 where using Precursor in a manifest array, manifest tuple or expression of an object test would cause a crash at runtime.
* Fixed multiple issues with validity checks involving multi-constraint formal generics and "like Current" types.
* Fixed system validity errors which were not previously detected or on the other hand rejected when it was correct. Fixes eweasel tests test#svalid019, test#svalid020 and test#multicon051.
* Fixed eweasel test#exec310 and bug#14477 where if you have a class name that is longer than 512 bytes or an attribute name longer than 512 bytes and you call `out` it would cause a buffer overflow.
===Runtime/code generation issues===
* Fixed broken generation of single threaded DLL.
* Fixed a bug on Windows where including some Eiffel multithreaded code in a DLL would cause a crash. This was due to the way we compiled our Thread Local Storage using a Microsoft optimization that only works for normal binaries, not DLLs.
* Fixed some interpreter crashes when handling manifest strings or agent expressions.
* Fixed eweasel test#final077 where the arguments passed to a creation expression where not properly processed when analyzing expressions. This caused the following instruction: "l_x := x.y.z (create .make (l_x))" to override the value of `l_x` with the value of `x.y` which is wrong.
* Fixed eweasel test#incr321 when if you finalize after removing a class from the system, then execution of workbench code fails.
* Fixed eweasel test#attach047 where type of array of string passed as argument to the creation procedure of the root class should have an attached actual argument type.
* Fixed eweasel test#expanded008 and bug#15693 where if you had an expanded with references attributes then the garbage collector would not update the internal references of the expanded and cause some memory corruption.
* Fixed a non-detection of stack overflow in a multithreaded application on Linux.
* Fixed test#thread002 where early termination of parent threads could corrupt memory if children thread are still alive.
* Fixed eweasel test#thread003 and test#thread007 where you could have a memory corruption at runtime when calling {THREAD}.join and no children threads have been launched yet.
* Fixed test#thread008 where you could have a memory corruption at runtime when calling {MEMORY}.find_referers.
* Fixed eweasel test#thread010 where a child thread would crash if its parent has already terminated and that child thread never started a thread.
* Improved signal handling to use more recent APIs when available. It especially fixes issue on Solaris where a signal handler was not reinstated after a SIGSEGV signal. It fixes eweasel test#except029.
* Fixed a bug with exception generated during the evaluation of a once in melted mode. This fixes eweasel test#except014 and test#except030.
* Worked around a bug in the Sun C compiler which caused the creation of SPECIAL in melted code to always fail when runtime is compiled with optimizations. It fixes eweasel test#melt070, test#melt081, test#term139, test#store014 and test#tuple006.
* Fixed a potential infinite loop when exiting a crash application when while quitting a signal is received which cause our last print statement to also fail (case of SIGPIPE), then it will infinitely repeat that sequence. This fixes the issue where eweasel test#vsrp208, although it was passing, ec was still using 100% CPU.
===Store/Retrieve issues===
* When handling a mismatch instead of generating the _REF classes for basic types, we generate directly an instance of the basic type so that one can do an object test on the basic type directly.
* Improved compatibility of storables between void-safe and non-void-safe systems so that a non-void-safe system can retrieve a storable created by a void-safe system by ignoring all the attachment marks.
* Fixed an unnoticeable performance issue with the C storable/retrieval mechanism (bug#14495).

49
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-64-and-ise-eiffel-65.wiki Normal file
View File

@@ -0,0 +1,49 @@
[[Property:title|Major changes between ISE Eiffel 6.4 and ISE Eiffel 6.5]]
[[Property:link_title|6.5]]
[[Property:weight|-12]]
[[Property:uuid|c4cf1874-cb2b-1034-704b-a537c1d5cd68]]
==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
*Added support for transient attribute. A transient attribute is an attribute which is not stored at runtime and for which its absence in the retrieval system has no effect. Only implemented for C based storable.
* New loop constructs implementation per a draft specification of the next ECMA standard. Although the compiler supports the new construct, the library counterpart was not included in this release. It will be available as a separate download a few weeks after the 6.5 release.
==Improvements==
No major improvements in 6.5 as this release was mostly focused on quality improvements.
==Changes==
* All the void-safe project configuration files have been removed from the non-experimental version. The rationale is that the usage of ARRAY and SPECIAL would not be void-safe and you need to switch to the experimental version to ensure complete void-safety.
* The command line compilation has been fixed to use the current working directory unless -project_path is specified (restoring pre-ecf behavior)
* When an ecf file has been specified with -config, the previously compiled target is chosen as the first option in the compilable target list.
==Bug fixes==
===Language issues===
* Ensured that code generation in .NET mode with experimental compiler worked properly. The current limitation is that manifest type instances are not unique unlike their classic counterpart and that {ANY}.generating_type cannot be applied on .NET types.
===Compiler issues===
* Fixed eweasel test#incr313, test#incr317 and test#incr318 where removal of a convert clause was not taken into account by the compiler.
* Fixed eweasel test#svalid022 where conversion to a target of a detachable type was not accepted, and also now the compiler will verify that the source of the conversion is always attached. Ensured that the source or the target type mentioned in a convert clause is attached.
* Fixed eweasel test#svalid024 where using an inspect clause with static constant access would failed to compile in a descendant class when `full class checking` is enabled.
* Fixed eweasel test#term156 and test#svalid025 where compiler would crash while compiling code that needs to be regenerated in descendant classes (e.g. code from precondition) involving anchors or formal generic parameters.
* Supported tracking changes made to a shared library definition file to trigger freeze automatically when there are any modifications to this file.
* Fixed bug on Unix platforms where spaces in project/installation paths failed to create the necessary symbolic links, when using precompiles.
* Fixed eweasel test#final083 where compiler would crash when inlining certain type of code involving generic classes.
===Runtime/code generation issues===
* Fixed eweasel test#final086 where an object test could evaluate the expression more than once.
* Fixed bug#13969 where an Eiffel generated DLL trying to print something to the console would cause a crash.
* Fixed bug#15553 where querying <eiffel>{FILE}.is_socket</eiffel> and some other file properties would not work properly on some Unix platforms (Solaris in particular).
* Fixed bug#13852 and bug#13816 where allocating large arrays would cause a memory corruption.
* Improved runtime protection of certain routines if a signal is delivered to avoid either corruption or memory leak (Fixes bug#13851, bug#13842, bug#13849, bug#13850 and bug#13840).
* Fixed bug#15241 where finalizing with assertions enabled would cause a C compilation error when freezing later in the same EiffelStudio session.
* Fixed a bug in CECIL macros which would cause a segmentation violation on some platforms at the first GC cycle.
* Fixed creation of manifest array with an attached actual generic parameter to not throw a precondition violation in void-safe mode.
* Fixed eweasel test#array006 where creating a manifest array would trigger an unjustified invariant violation.
* Fixed eweasel test#final084 where compiler would generate incorrect type at run-time causing some memory corruption or a general failure.
===Store/Retrieve issues===
* Fixed bug#16395 and eweasel test#store026 to avoid mismatch if the metadata stored in `eskelet` is simplified or not (i.e. for class A[G] feature g: B[G], and then having A [INTEGER] could either describe `g` as either `B[G]` or `B[INTEGER]`, even though different they are the same type and should not yield a mismatch).
* Fixed eweasel test#store028 where retrieving an object whose type involves a TUPLE type without a TUPLE instance could corrupt the retrieval system.

52
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-65-and-ise-eiffel-66.wiki Normal file
View File

@@ -0,0 +1,52 @@
[[Property:title|Major changes between ISE Eiffel 6.5 and ISE Eiffel 6.6]]
[[Property:link_title|6.6]]
[[Property:weight|-13]]
[[Property:uuid|4ff759ff-c389-f765-0252-2d844b69fa54]]
==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* Added support for [[ET: Other Mechanisms#Adjusting once semantics with "once keys"|new once syntax and once per object]]. However support for once object is still experimental in this release.
* Added support for [[ET: Inheritance#Qualified Anchored Declarations|RAT/QAT]], with the following limitations:
** Qualified anchored types that involve formal generics with multiple constraints are not supported.
** When an attribute of type `like a.b.c' yields a formal generic parameter in the chain, then the creation of such attributes would not yield the proper type.
** Creation and object tests with the type depending on qualified anchored types that involve deferred intermediate types are not supported on .NET.
* Added a new option Total Order on REALs which let you have NaN equal to NaN and NaN being the smallest number of all. This option is disabled by default as it could break existing code. The rationale for this option is to have contracts work properly when manipulating the NaN value and not getting spurious contract violation.
* Added the ability to version a class for storable. It is done via the note clause of a class, i.e. <e>note storable_version: tag</e>. When the storing and retrieving system have a different version a mismatch is triggered even if they look to have the same content.
* Supported new variant of a check instruction that is not subject for assertion monitoring settings (in other words the check cannot be turned off) and can be used to introduce a new void safe scope of a read-only or object test local:
<e>check Assertion then
Compound
end
</e>
* Now the compiler will report usage of is keyword as obsolete in transitional mode and will reject it in standard mode.
==Improvements==
* Added support of [[ET: The Dynamic Structure: Execution Model#Transient attributes|transient attributes]] for .NET. Added queries in INTERNAL to find out the transient attributes. Extended the Eiffel serialization SED to support them.
* Redone some of the multithreading internals of the Eiffel runtime to make it easier to add platforms and to ensure the same behavior on various platforms, namely that mutex should be recursive.
* On Windows, the MUTEX class is now internally using a CRITICAL_SECTION object which is much more efficient especially on multiprocessors.
==Changes==
* The experimental mode available in 6.5 and earlier version has become the default mode. To have access to the default mode of 6.5, one has to use the compatible version. It can be accessed on Windows via the Start menu shortcut or by using "-compat" on the command line.
* Allowed manifest real constants to be assigned to REAL_32 entities without having the need to type the constant, that is to say `r_32 := 4.5' will now be accepted whereas before one had to do `r_32 := {REAL_32} 4.5'. This is to simplify migration from code that compiled fine under 6.5 and would not under 6.6 due to the removal of the conversion routine from REAL_64 to REAL_32.
* When twinning a <e>SPECIAL</e> instance where <e>capacity</e> is much higher than its <e>count</e> the new copy will have its <e>capacity</e> set to <e>count</e>.
* The storable format has changed to support versioning. This new format is only available in the default mode. When using the compatible mode it will store using the old format and no version information will be stored.
==Bug fixes==
===Language issues===
* Fixed in void-safe mode conformance of detachable COMPARABLE to attached ANY. Fixes updated eweasel test#conform001.
===Compiler issues===
* Fixed test#incr168 when recompilation did not regenerate the code in some complex cases when features are modified deep in inheritance tree. It also fixes eweasel test#exec283 and addresses a consistency issue with the order of merging inherited assertion clause that would not trigger the same output if recompiled from scratch after some incrementality changes (see eweasel test#incr124).
* Fixed bug#16545 when compiler did not detect that a new file does not contain an expected class after referencing it in a system (see test#incr340).
* Fixed several recompilation bugs (bug#16546, bug#16547, bug#16553) for cases when a feature with assertions is removed from a parent class while a child class remains unchanged (see test#incr341, test#incr342, test#incr343).
* Fixed recompilation bugs (bug#14525, bug#16052) that caused compiler crash or incorrect error message when checking inherited code of a client that refers to a feature that is (re)moved (see test#incr293, test#incr338).
* Fixed bug#16593 where finalizing twice in the same sessions with many changes in the system could cause the compiler to crash during degree -3.
===Runtime/code generation issues===
* Fixed test#runtime016 due to an improper optimization of the call {SPECIAL}.copy_data when inlining is enabled. It could cause a memory corruption.
* Fixed bug#16626 bug that occurred when melted code called frozen code that called a melted agent triggering exception (see test#incr348).
* Fixed eweasel test#agent001 and test#agent013 by preventing wrong optimization when call to `{ROUTINE}.call' or `{FUNCTION}.item' are subject to dynamic binding.
* Fixed eweasel test#exec323 where comparison using <= or >= in melted mode which involved NaN was not yielding the same result as in workbench mode.
===Store/Retrieve issues===
* Fixed eweasel test#store029 where retrieving a storable made by 6.3 or older could fail with a mismatch error when there is actually no mismatch.

39
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-66-and-ise-eiffel-67.wiki Normal file
View File

@@ -0,0 +1,39 @@
[[Property:title|Major changes between ISE Eiffel 6.6 and ISE Eiffel 6.7]]
[[Property:link_title|6.7]]
[[Property:weight|-14]]
[[Property:uuid|56177121-d509-3dd3-bb11-5f70d69a74f7]]
==What's new==
{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
* EiffelStudio can use GCC on Windows for both 32-bit and 64-bit edition. We are using version 4.4.5 of gcc.
* EiffelStudio can now parse UTF-8 source code. Unicode characters can be used in strings, comments and operators.
* New tracing facility for Eiffel code. Until now tracing was done at the runtime level by writing to the standard output. The new tracing facility lets you execute some user defined Eiffel code at entry and exit of all routine calls. It can be used for logging purposes, or for test coverage.
==Improvements==
* Allowed for a qualified anchored type that has a standalone type qualifier to be used as a type of a once function *bug#16947, test#anchor050).
==Changes==
==Bug fixes==
===Language issues===
===Compiler issues===
* Fixed various issues related to qualified anchored types: bug#16791 (test#anchor011), bug#16792 (test#incr352), bug#16793 (test#incr353), bug#16797 (test#anchor012), bug#16798 (test#anchor013), bug#16799 (test#anchor014), bug#16800 (test#anchor015), bug#16803 (test#anchor016), bug#16804 (test#anchor017), test#anchor018, bug#16819 (test#anchor019), bug#16821 (test#incr354), test#anchor020, test#anchor021, bug#16824 (test#anchor022), test#anchor023, bug#16839 (test#anchor024), test#anchor026, bug#16848 (test#anchor027), bug#16849, bug#16850 (test#attach030), bug#16855 (test#final089), bug#16849, bug#16867 (test#anchor028), bug#16868 (test#anchor029), bug#16876 (test#anchor031), bug#16878 (test#incr356), bug#16879 (test#anchor033), bug#16883 (test#anchor034), bug#16884 (test#anchor035), bug#16885 (test#anchor036), bug#16886 (test#anchor037), bug#16887 (test#anchor038), bug#16889 (test#incr358), bug#16890 (test#anchor040), bug#16893 (test#incr359), bug#16897 (test#anchor041), bug#16899 (test#incr362), bug#16900 (test#incr363), bug#16901 (test#incr364), bug#16902 (test#anchor043), bug#16943 (test#anchor047), bug#16944 (test#anchor048), bug#16945 (test#anchor049), bug#16959 (test#anchor052).
* Fixed various issues related to once per object: test#once001, test#once002, test#once003, test#once004, test#once005, test#once006, test#once007, test#once008, test#once009, test#once010, test#once011, test#incr366, test#incr376, test#incr384.
* Fixed various incrementality bugs: test#incr295 test#incr302 test#incr307 test#incr309 test#incr324 test#incr331 test#incr332 test#incr346 test#incr372 test#incr373 test#incr374.
* Fixed eweasel test#exec327 where evaluation an assertion the code being executed encounter the new check ... then ... end instruction it would reset some internal flags causing assertion within assertions to be checked when they should not.
* Fixed eweasel test#valid243, test#svalid028, test#svalid029, test#tuple004, test#freez032 and test#multicon058. The issue was that when we performed the type checking of inherited routines using prefix/infix we were not using the new name of the prefix/infix operator but still the old one. Thus if it was renamed it would cause a spurious compilation error instead of accepting the code.
===Runtime/code generation issues===
* When running an Eiffel system on Windows without assertion monitoring and you try to write a file that is not yet open, it will trigger an exception instead of silently exiting.
* Fixed eweasel test#thread016 where we forget to protect arguments used for catcall checking.
* Fixed building of shared libraries of CECIL system which failed on Windows.
* Fixed eweasel test#ccomp085 where compiler ensures that the order of includes of an Eiffel external is respected at compile time.
* Fixed eweasel test#exec326 by properly generating the REAL_32 values for {REAL_32}.min_value and {REAL_32}.max_value.
===Store/Retrieve issues===
* Prevented the C storable from blocking all threads while waiting from data to be read in <e>retrieved</e>. Now control waits for the storable type first before blocking all the other runtime threads. This fixes bug#16859.
* Fixed bug#16946 and eweasel test#store032 where corruption could occur if an object is stored in a different thread than the main thread.

29
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki Normal file
View File

@@ -0,0 +1,29 @@
[[Property:title|Major changes between ISE Eiffel 6.7 and ISE Eiffel 6.8]]
[[Property:link_title|6.8]]
[[Property:weight|-15]]
[[Property:uuid|4ae502ce-5832-c323-4c3a-d1b0d1243735]]
==What's new==
* Support for [[Concurrent programming with SCOOP|SCOOP concurrency model]].
{{seealso|<br/>1) SCOOP implementation [[SCOOP implementation#Known limitations|limitations]].<br/>2) [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]]. }}
==Improvements==
* Made ECF parser more tolerant by converting errors into warnings when the current namespace is unknown.
* Improved error reporting by including attachment status indicator in type information so that one can easily see the difference between attached and detachable types when they come from the classes with different default attachment settings.
==Changes==
* Made feature <e>{ITERATION_CURSOR}.start</e> optional when processing an iteration form of a loop.
==Bug fixes==
* Fixed bug#17374: Feature call on void target in {EB_CLASS_INFO_ANALYZER}.stone_in_click_ast in EiffelStudio.
* Fixed bug#17299: Locale preference lost the second time opening EiffelStudio.
* Fixed a crash that occurs when there is an error inside a check instruction.
===Language issues===
===Compiler issues===
===Runtime/code generation issues===
===Store/Retrieve issues===

11
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki Normal file
View File

@@ -0,0 +1,11 @@
[[Property:modification_date|Tue, 12 Nov 2019 13:31:36 GMT]]
[[Property:publication_date|Tue, 12 Nov 2019 13:20:00 GMT]]
[[Property:title|Compiler History]]
[[Property:weight|-8]]
[[Property:uuid|359395e7-4933-bb74-4397-353c8b6955cd]]
==Compiler version history==
{{Warning|This page as not been maintained}}
{{Note|Please check the -> [[EiffelStudio_release_notes|EiffelStudio Release Notes]]}}

63
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-1311-and-ise-eiffel-1405.wiki Normal file
View File

@@ -0,0 +1,63 @@
[[Property:title|Major changes between ISE Eiffel 13.11 and ISE Eiffel 14.05]]
[[Property:link_title|14.05]]
[[Property:weight|8]]
[[Property:uuid|a901f880-4f88-f889-4880-d3687b6939b1]]
==What's new==
* Syntax warnings are now reported for unsupported empty lists such as (), or [], or {}, as well as an empty export clause `export {NONE} end'.
* Added ability to extract the file location of a class in interactive mode.
==Improvements==
* Made workbench code more compact and faster by about 5 to 9% on average.
* Improved memory tool to list all fields of an object.
* Better command line usage that will report why the command line is incorrect instead of displaying the whole help.
* Compiler is now more robust if some required routines/classes are not found as expected by the compiler. It will now report a Library_error error instead of failing.
* Now the compiler reports all VWEQ warnings as before it was only doing it if you were comparing an expanded with a reference.
==Changes==
* In circa 2000, we allowed $x and $(expr) as expression instead of just argument passing. But while this was good for just $x, $(expr) is actually not supported properly in the code generation. In 14.05, we have disallowed $(expr) outside argument passing.
* In workbench mode, if the melted file cannot be found, instead of exiting the application, the application will run as if it had never been melted and will instead print a warning in the console.
==Bug fixes==
===Language issues===
===Compiler issues===
* test#anchor071 - Fixed computation of a qualified anchored type that involves a formal generic parameter and feature redeclaration in a descendant of the formal generic constraint.
* test#anchor077 - Fixed a compiler crash when analyzing the following qualified anchored type '''like x.f''' where f is defined as '''f: like y.z.w'''.
* bug#16991 (test#anchor056) - Fixed a bug that might cause the compiler to report an unknown feature in a qualified anchored type with a formal generic qualifier constrained only by formal generic types.
* test#anchor070 - Fixed a bug that might cause a compiler crash when nested qualified anchored types with a longer feature chain were involved in qualifiers of other qualified anchored types.
* bug#16983 (test#anchor055), bug#17034 (test#anchor057) - Fixed a bug that caused a crash when compiling code with a creation of an object of a qualified anchored type with a formal generic.
* bug#17239 (test#term198) - Fixed a bug that caused a crash when compiling the code that used an inline agent as an iteration expression.
* bug#17233 (test#term196) - Supported iteration on an expression of a formal generic type.
* bug#18759 (test#iteration004) - Changed processing of {ITERABLE}.new_cursor to use a renamed version of the feature in a descendant class rather than the feature having this name.
* test#config028, test#config029 and test#config038 - Fixed a crash when using a cluster/library with an invalid path.
* Fixed a long standing bug where descriptions in external nodes were lost.
* Fixed an issue with interactive mode where displaying all classes was actually not display classes which are part of a recursive cluster.
* bug#18758 (test#anchor073, test#anchor074, and test#anchor059) - Fixed some improper handling of qualified anchors.
* test#anchor050 - Fixed an issue on .NET where the compiler would not properly handle '''like {X}.f'''.
* test#anchor065 - Fixed a compiler crash when processing '''like {G}.value'''.
* Fixed a bug in the interactive mode of the compiler that was preventing the display of classes that belong to a folder of a cluster.
* test#valid265 - Fixed a bogus compilation error when the type of a variant expression is of an anchored type when it should have accepted it.
* bug#18824 (test#anchor075) - Fixed a compiler crash in .NET code generation where '''like {X}.dotnet_query''' would crash the compiler at degree 3.
* text#catcall013 - Fixed an issue with catcall checking which would crash the compiler in the specific case where a type used as argument has some conversion routines.
* Fixed bug#18855 where we used the wrong constant to display the command switch for the `-debug' option.
===SCOOP issues===
===Runtime/code generation issues===
* test#exec341 - Fixed a crash at runtime when performing an assignment using an object-less call, e.g. '''{EXT}.fea := bar'''.
* Fixed a regression that caused a C compilation error after removing a type from the system.
* bug#18758 (test#anchor072) - Fixed crash which only affected .NET code generation of qualified anchor types.
* test#anchor018, test#anchor050, test#anchor054, test#anchor056, test#anchor059, test#anchor063 and other tests - Fixed a code generation issue on .NET where some incorrect casts where generated causing an exception at runtime when the code is actually ok.
* test#freez022 - Fixed a missing conversion at runtime when formal argument type is an anchor.
* Fixed CECIL library creation to take into account the new memory_analyzer.o and offset.o modules of the runtime.
* bug#18785 (test#ccomp089) - Fixed a code generation issue for Linux 32-bit for the generation of the value of NaN, +Infinity and -Infinity for floating numbers.
===Store/Retrieve issues===
* Fixed an issue where retrieving a large amount of objects on a x86 platform, we would crash where restoring one of the store/retrieve stack using ''epop''.
* bug#18835 - Fixed a potential overflow issue with store/retrieve when you have more than 2^31 objects.

60
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-68-and-ise-eiffel-70.wiki Normal file
View File

@@ -0,0 +1,60 @@
[[Property:title|Major changes between ISE Eiffel 6.8 and ISE Eiffel 7.0]]
[[Property:link_title|7.0]]
[[Property:weight|13]]
[[Property:uuid|0211321e-969d-04a4-66ee-2a6069836845]]
==What's new==
* Supported development of incomplete void-safe classes (so called "design mode") by avoiding reporting void-safety errors for unreachable code, e.g. for the code after a call to a feature that never returns normally, say, to <e>{EXCEPTIONS}.die</e>. As a result it became possible to declare a creation procedure that does not initialize attached attributes properly (because the corresponding effective classes are not available yet), for example:
<e>
make (...)
do
... -- Some attributes are not initialized.
die (1) -- Compiler does not report VEVI errors.
end
</e>
:or
<e>
make (...)
do
... -- Some attributes are not initialized.
check implemented: False then end -- Compiler does not report VEVI errors.
end
</e>
==Improvements==
* Enforced full class checking for void-safe classes.
* Disallowed void-safety mismatch when a descendant or a client have stricter void-safety setting than the corresponding ancestor or supplier.
* Taken into account changes of class options when performing recompilation.
* Changed processing of "stable" features to follow the recent modifications to the standard.
* Avoided reporting errors related to variable initialization when the right-hand part of assignment to this variable causes an error.
* Promoted keywords <e>across</e> and <e>some</e> from the '''provisional''' [[Setting the syntax variant|syntax variant]] to the '''standard''' one.
* Made class <e>BIT_REF</e> optional as soon as a <e>BIT</e> type is not used in a system (to be ready to drop support for <e>BIT</e> types in the next releases).
* Replaced keyword completion for <e>indexing</e> with keyword completion for <e>note</e>.
==Changes==
* Changed default options: default [[Setting the syntax variant|syntax variant]] is set to [[Syntax level variant settings by version|standard]], [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] is set to '''true''' unless specified otherwise.
* Moved [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] option to [[Advanced Options|Advanced]] section.
==Bug fixes==
===Language issues===
* Considered <e>like Current</e> as attached regardless of [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] option.
* Prohibited assignment of <e>Void</e> to a variable of a reference formal generic type that has no <e>detachable</e> mark.
* Supported attachment marks on the type <e>NONE</e>, including implicit setting via [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] option.
* Corrected processing of self-initializing attributes to follow the standard rules.
===Compiler issues===
* Included location information in <code>VTCT</code> error and <code>VTCM</code> warning reports.
* Fixed several recompilation issues.
* Fixed several cases that could lead to a compiler crash.
* Corrected checks for attachment status of variables to include not only a body of a loop, but also its invariant, variant and exit condition when a variable may be detached in the loop body.
* Taken into account attachment status of <e>like Current</e> when checking for conformance.
* Taken separateness status into account when checking for formal generic type equality and conformance as well as when substituting actual generics.
* Made custom conditions in ECF case-insensitive to be in line with the processing of custom variables.
* Changed context of inherited assertion evaluation to use the one of the inherited assertion so that the types are evaluated correctly (this in particular affects qualified anchored types that involve formal generics that are no longer present in a descendant class).
===Runtime/code generation issues===
* Fixed several issues with separate feature calls.
===Store/Retrieve issues===
* Fixed an issue when there are too many mismatches in a storable, the retrieval would fail with an invalid object being retrieved.

63
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-70-and-ise-eiffel-71.wiki Normal file
View File

@@ -0,0 +1,63 @@
[[Property:title|Major changes between ISE Eiffel 7.0 and ISE Eiffel 7.1]]
[[Property:link_title|7.1]]
[[Property:weight|12]]
[[Property:uuid|4b7325ad-4c9c-d6f8-3a25-7d2a4d709fcb]]
==What's new==
* New SCOOP processor GC which lets you create as many processors as you want as long as they are no more than 1500 concurrent processors (or less depending on your available memory).
* Supported the EIFFEL_LIBRARY environment variables to locate libraries.
==Improvements==
* The Eiffel Configuration Files accept C compiler and linker flags. Former ECFs using a workaround to specify those flags as part of the external includes or external objects sections are automatically updated to the new specification.
* Report invalid Unicode code point for STRING_8 manifest.
* Ensured you can switch C compilers after compiling with one on Windows.
* Speed up C compilation with Visual Studio by using `#pragma once` on our header files (bug#17092).
* Speed up execution of expanded comparison using ~ when types are known to be different at compile time.
* Optimized code generation of <e>{CHARACTER_32}.is_character_8</e>.
* Optimized code generation of boolean expressions that are known to be False or True at compile time in both workbench and finalized mode.
==Changes==
* Breaking change of generating Unicode code point for STRING_8 manifest written in UTF-8 source code. (Written UTF-8 bytes was generated). Unlike previous versions, what you see will be what you get at runtime, i.e. the character codes are the same.
* In the `on-demand` void-safety mode, the compiler will not report a VD88 error when you are using a non-void safe library. This should help migrating existing code to full void-safety.
* Removed support for type qualifier for strings used in obsolete messages.
* Removed type qualifiers from manifest constants to follow the changes in the language rules that now prevent from using them in constant attribute declarations.
* VWEQ warnings will only be triggered for immediate code, not inherited code.
* The assignment attempt operator <e>?=</e> is now triggering an obsolete syntax warning.
* Changed expected content of verbatim strings to take into account that empty lines and empty lines with blanks are considered as different (test#syntax045).
* Default projects are now console applications by default.
==Bug fixes==
===Language issues===
* Fixed bug that the compiler accepted invalid typed character. i.e. {BOOLEAN} 'c'.
* Made sure that typed manifest strings are using a proper string type, not just any type (bug#18045).
* Ensured all attributes are set when an unqualified agent is created (bug#18067).
* Triggered a warning when a non-empty body of an attribute which has a self-initializing type as the body is guaranteed to be never executed (bug#15145, test#exec296).
* Added detection of inline agents on attributes to report a NOT_SUPPORTED error (bug#15147, test#term168).
===Compiler issues===
* Fixed various issues where compiler did not properly report errors for mal-formed Eiffel Configuration Files.
* Fixed formatting of VFAV(2) error reporting (bug#18050).
* Fixed duplicated report of VFAC(1) error (bug#18047).
* Made sure one can perform the C compilation using the 32-bit version of the compiler on a 64-bit machine.
* Fixed compilation of EiffelBase using the new replication mode (test#replication008 and test#replication009).
* Improved VTAT error description (bug#16875).
* Fixed a compiler failure when the F_code or W_code sub-directories are deleted after an initial compilation.
===SCOOP issues===
* Fixed a memory corruption when a query on a separate target would not properly register the results to the garbage collector, making the results potentially unusable.
===Runtime/code generation issues===
* Fixed code generation in melted mode when you declare a CHARACTER_32 constant feature such as <e>x: CHARACTER_32 = '%/027/'</e>.
* Prevented a deadlock situation after a fork is performed on Unix platforms when using the `eif_thread_fork` (bug#18094).
* Fixed a traitor situation where a multi-dot chain involving a separate target are treated as separate calls rather than normal calls (test#scoop024).
* Fixed code generation of object test on basic types that was failing on .NET (test#dotnet113).
* Fixed some definitions conflicts with `complex.h` which occurs on some platforms.
* Ensured that on Windows using any Microsoft C++ compiler only 2 digits are displayed for exponents that can be represented on 2 digits and three otherwise.
* Fixed a potential memory leak of thread context when a parent and a child are exiting at about the same time.
* Fixed an incorrect handling of <e>detachable NONE</e> at runtime (test#melt088, test#valid154).
* Fixed a performance issue when a thread exits which would slow downs all threads until the next garbage collector cycle.
* Redesigned termination of a multithreaded program to avoid some deadlock and/or race conditions that could occur on a heavily loaded system (test#thread020, test#thread021 and test#thread023)
===Store/Retrieve issues===
N/A

36
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-71-and-ise-eiffel-72.wiki Normal file
View File

@@ -0,0 +1,36 @@
[[Property:title|Major changes between ISE Eiffel 7.1 and ISE Eiffel 7.2]]
[[Property:link_title|7.2]]
[[Property:weight|11]]
[[Property:uuid|a063cc22-7638-e0cf-7d92-93aca615a283]]
==What's new==
* Added support for parsing Eiffel classes located in Unicode path.
==Improvements==
* Better error messages for VBAC(3), VBAR(2), VUTA(2) and VD80.
* Fixed latency issues regarding SCOOP client and supplier processor.
==Changes==
N/A
==Bug fixes==
===Language issues===
N/A
===Compiler issues===
* Fixed bug#18309: Refreezing system with no changes causes all C compilations to be redone.
* Fixed eweasel test#valid278 and test#term188 (bug#18281 and bug#1984) by ensuring that the type used in the objectless call is full valid.
===SCOOP issues===
* Fixed eweasel test#scoop027 to ensure lock passing detection when logging on a chain creator during creation of a new processor.
===Runtime/code generation issues===
* Fixed bug#18299 and eweasel test#exec351 where copying nested expanded would cause a memory corruption.
* Fixed eweasel test#thread024 where mutltithreaded projects could crash during a GC cycle.
* Fixed an issue with <e>EIF_INITIALIZE_AUX_THREAD</e> that would not work properly in workbench mode because it forgot to initialize the interpreter side by calling `<e>xinitint</e>'.
* Fixed a bug during debugging that causes a GC corruption due to the insertion of expanded objects located on the stack in the hector stack which is not allowed.
===Store/Retrieve issues===
N/A

36
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-72-and-ise-eiffel-73.wiki Normal file
View File

@@ -0,0 +1,36 @@
[[Property:title|Major changes between ISE Eiffel 7.2 and ISE Eiffel 7.3]]
[[Property:link_title|7.3]]
[[Property:weight|10]]
[[Property:uuid|84a0a02d-b9cc-9897-c1d9-41dfc27c294a]]
==What's new==
* Added support for agents with targets of separate types.
* Added new levels of void-safety: "conformance" that enables taking attachment marks into account when checking for conformance; "transitional" (previously "all") that checks almost all void-safety rules except those for unqualified agents and allows CAPs for preconditions and check instructions; "all" that checks all void-safety rules.
==Improvements==
* Fixed issue that causes many classes to be recompiled when not needed.
* Relaxed rules for using Current and unqualified agents when not all attributes are set to report VEVI errors only when qualified calls are involved in a sequence of unqualified calls and creation procedure calls ("targeted rules").
==Changes==
* The BIT type has been completely removed from libraries and runtime.
==Bug fixes==
===Language issues===
N/A
===Compiler issues===
* Fixed error in processing replicated and selected attributes with self-initializing attribute bodies that could lead to reporting these attributes as uninitialized.
* Fixed a bug that might result in a missing VEVI error for Result in a self-initializing attribute body.
===SCOOP issues===
* Fixed a bug that caused incorrect conformance checks for formal generics of different separate status.
* Fixed a bug that might cause incorrect conformance checks for attachment and separateness status of a constrained formal generic parameter against a class type.
* Fixed a C code generation bug that might cause an access on an invalid address during object test evaluation with an expression of a separate type.
===Runtime/code generation issues===
* Fixed a bug where the TYPE instance of a new generic derivation in the running system would be corrupted.
===Store/Retrieve issues===
* Fixed a bug in .NET where using the Eiffel serialization or marking objects would trigger computation of `hash_code` on Eiffel objects and thus changing their state.

43
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-73-and-ise-eiffel-1311.wiki Normal file
View File

@@ -0,0 +1,43 @@
[[Property:title|Major changes between ISE Eiffel 7.3 and ISE Eiffel 13.11]]
[[Property:link_title|13.11]]
[[Property:weight|9]]
[[Property:uuid|e32947f4-928c-816e-1dbd-4aa53030e8c7]]
==What's new==
* Supported parenthesis aliases that allow treating feature calls with arguments on entities that take no arguments to look like regular feature calls. This is mostly useful to make calls on agent objects, e.g. instead of <e>my_agent.call (x)</e> it may be possible to use <e>my_agent (x)</e>. Unlike bracket alias, parenthesis alias can be used with both queries and commands, but as with bracket alias, the corresponding feature should have at least one argument.
* Supported new rules to handle actual arguments in a feature call that wrap last arguments into a tuple when:
** the number of actual arguments exceeds the number of formal arguments
** the number of actual arguments is equal to the number of formal arguments, but the last actual argument is not type-compatible with the last formal argument unless wrapped in a tuple.
:: This is mostly useful to make calls on agent objects avoiding explicit manifest tuple notation. For example, <e>my_agent.call ([123, "abc", value])</e> can be written as <e>my_agent.call (123, "abc", value)</e>, or, when combined with parenthesis alias, as <e>my_agent (123, "abc", value)</e>.
* Supported conditional expressions that allow using different expressions to compute a value depending on some condition: <e>if x < y and x < z then x elseif y < z then y else z end</e>.
* ECF redirection support to provide a way to create redirection from a .ECF to another.
* Added VD89 warnings to highlight library dependency cycles.
==Improvements==
* Added support for Sun C compiler on Linux for RHEL, OL and Ubuntu 8.04. Other Linux distributions are not supported.
* Speed up SCOOP by an average of 35% up to 500% on some benchmarks:
** Added various optimizations to reduce massive latency over call logging and waiting due to overhead from operating system synchronization primitives and scoop call cleanup. Improved lock passing client supplier synchronization speed by a factor of 60 due to removing latency from condition variable use.
==Changes==
==Bug fixes==
===Language issues===
* Fixed bug#18643 (test#attach107, test#attach102) - Fixed a bug that may lead to unreported VEVI errors for attributes not properly set by a creation procedure when compiled in complete void-safety mode (rev#92835).
* Fixed bug#18266 (test#svalid031) - Fixed a bug that caused reporting a non-existent error for a renamed feature with a bracket alias.
* Fixed bug#18282 (test#multicon062) - Fixed a bug that caused incorrect error report for features with a bracket alias specified in multiple formal generic constraints.
===Compiler issues===
* Fixed a crash when converting old Ace files to new ECF format. (bug#18642 and bug#18628, rev#92820)
* Fixed bug#15591 (test#attach106), bug#17302 (test#valid270) - Fixed an erroneous reporting of VUOT for object test locals when right-hand side of a binary expression using these locals has a validity error (rev#92769).
* Fixed test#attach108 - Corrected computation of scopes of read-only variables used in implicative expressions with conjuctions.
===SCOOP issues===
* Fixed a crash when a separate detachable argument is Void (test#scoop035).
* Fixed lock passing creation of separate processor from non root processors.
* Fixed uncontrolled detection to iterate parent request chains. Prior to this a new chain would be created even though the processor was controlled in a parent routine, leading to inevitable deadlock.
===Runtime/code generation issues===
===Store/Retrieve issues===

73
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki Normal file
View File

@@ -0,0 +1,73 @@
[[Property:modification_date|Mon, 29 Jul 2019 05:54:09 GMT]]
[[Property:publication_date|Tue, 09 Jul 2019 08:25:22 GMT]]
[[Property:title|Differences between ETL 2nd printing and Eiffel Software implementation]]
[[Property:link_title|ETL 2nd printing vs implementation]]
[[Property:weight|-9]]
[[Property:uuid|fc1e73f4-5646-aa41-e7fe-97dc6f3ceb04]]
{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }}
"ETL 2nd printing" refers to the book "Eiffel: The Language" (2nd printing), published by Prentice Hall.
==Added classes==
* New basic classes have been added: <eiffel>INTEGER_8</eiffel>, <eiffel>INTEGER_16</eiffel>, <eiffel>INTEGER_64</eiffel>, <eiffel>CHARACTER_32</eiffel>. <eiffel>INTEGER</eiffel>, <eiffel>CHARACTER</eiffel>, <eiffel>REAL</eiffel>, <eiffel>DOUBLE</eiffel> are aliases to <eiffel>INTEGER_32</eiffel>, <eiffel>CHARACTER_8</eiffel>, <eiffel>REAL_32</eiffel>, <eiffel>REAL_64</eiffel>. {{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]]}}
* New <eiffel>TUPLE</eiffel>, <eiffel>ROUTINE</eiffel>, <eiffel>PROCEDURE</eiffel>, <eiffel>FUNCTION</eiffel>, <eiffel>PREDICATE</eiffel> classes required by the agent mechanism.
==Added keywords==
* <eiffel>Precursor</eiffel>
* <eiffel>reference</eiffel> (now obsolete): a keyword to specify that a type is used as a reference type.
* <eiffel>agent</eiffel>: a keyword used by the agent mechanism.
* <eiffel>create</eiffel>: Instead of using the famous exclamation mark to create an instance of a class, you can use the keyword <eiffel>create</eiffel>. Below you will find a correspondence table between the old and the new syntaxes. The old syntax is still valid, but at some points Eiffel Software will remove it from its implementation:
** Old syntax `!! a` => new syntax `create a`
** Old syntax `!! a.make` => new syntax `create a.make`
** Old syntax `!B! a` => new syntax `create {B} a`
** Old syntax `!B! a.make` => new syntax `create {B} a.make`
* <eiffel>note</eiffel>: replacement for the keyword <code>indexing</code>.
* <eiffel>attribute</eiffel>: a keyword to declare attribute body.
* <eiffel>attached</eiffel>: a keyword to specify attached types and object tests.
* <eiffel>detachable</eiffel>: a keyword to specify detachable types.
==Added semantics==
* [[ET: Genericity and Arrays|Generic creation]]
* Expression creation: you can now create an object within an expression. For example, you want to create an object and pass it as an argument to a function. Whereas you had to create a local variable, create the object and pass it to the function, you now simply need to pass to the function the creation expression. Here is a small example:
** Old method:
<code>
local
a: STRING
do
‼ a.make (10)
f (a)
end
</code>
** 'New method:
<code>
do
f (create {STRING}.make (10))
end
</code>
This is also very useful since it can improve the power of assertions.
* Mutually recursive constraints: one can now write class `A [H, G->H]` or class `B [H -> C, G -> ARRAY [H]]`. As a result, the declaration `A [D, E]` is valid only if `E` is a descendant of `D`. Similarly, the declaration `B [E, ARRAY [D]]` is not valid, if `E` is a descendant of `D`.
* [[ET: Other Mechanisms|Tuples]]
* [[ET: Agents|Agents]]
* Feature access: <br/>
<code>
local
value: INTEGER
do
value := {MY_CLASS}.value
end
</code>
<br/>
The previous call is valid, if and only if:
** <eiffel>value</eiffel> is a feature representing a constant of a basic type (<eiffel>INTEGER</eiffel>, <eiffel>DOUBLE</eiffel> or <eiffel>CHARACTER</eiffel>)
** <eiffel>value</eiffel> is a C/C++/DLL external feature
** <eiffel>value</eiffel> is an IL static external feature
==Obsolete constructs==
* Explicit values should be used to specify constant attributes instead of keyword `unique`.
==Added external support==
Look at the page for [[C externals|C]] and [[C++ Externals|C++]] with the introduction of `struct` and C++ external features encapsulation.

383
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki Normal file
View File

@@ -0,0 +1,383 @@
[[Property:modification_date|Tue, 09 Jul 2019 09:52:07 GMT]]
[[Property:publication_date|Tue, 09 Jul 2019 09:46:53 GMT]]
[[Property:title|Differences between standard ECMA-367 and Eiffel Software implementation]]
[[Property:link_title|ECMA-367 vs implementation]]
[[Property:weight|-10]]
[[Property:uuid|0eb58761-5b06-585f-ea92-cab2b8cd74b2]]
"ETL 2" refers to the book "Eiffel: The Language" (2nd printing), published by Prentice Hall.
==Kernel classes==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Fictitious class for tuples
| <eiffel>TUPLE</eiffel>
| No
| Yes
| Yes
|}
==Features==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Prefix and infix feature names
| <code>infix "+"</code>
| Yes
| No
| Yes, marked as obsolete
|-
| Operator and bracket aliases
| <code>add alias "+"</code>
| No
| Yes
| Yes, except for new rules
for free operator names
|-
| Assigner command
| <code>item alias "[]" (index: INTEGER): G assign put</code>
| No
| Yes
| Yes
|}
==Design by Contract==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Only postcondition clauses
| <eiffel>ensure only a, b</eiffel>
| No
| Yes
| No
|}
==Genericity==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Mutually recursive constraints
| <code>A [H, G -> H]</code><br/>
<code>B [H -> C, G -> ARRAY [H]]</code>
| No
| Yes
| Yes
|-
| Full mutually recursive constraints
| <code>A [H -> G, G -> H]</code><br/>
| No
| Yes
| Yes
|-
| Expandedness restriction on formal generic
| <code>A [reference G]</code><br/>
<code>B [expanded H]</code>
| No
| No
| Yes
|}
==Creating objects==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Implicit creation procedure (version of
<code>ANY.default_create</code>)
| <code>class A feature ... end</code><br/>
<code>-- The following instructions are equivalent:</code><br/>
<code>create {A} a</code><br/>
<code>create {A} a.default_create</code>
| No
| Yes
| Yes
|-
| Bang-bang syntax
| &#33;&#33; a<br/>
&#33;&#33; a.make<br/>
&#33;B&#33; a<br/>
&#33;B&#33; a.make
| Yes
| No
| Yes, marked as obsolete
|-
| Keyword syntax
| <code>create a</code><br/>
<code>create a.make</code><br/>
<code>create {B} a</code><br/>
<code>create {B} a.make</code>
| No
| Yes
| Yes
|-
| Creation expression
| <code>print (create {TIME}.make_now)</code>
| No
| Yes
| Yes
|-
| [[ET: Genericity and Arrays|Generic creation]]
| <code>create {G} x.make</code>
| No
| Yes
| Yes
|}
==Attachment==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Preserving expandedness status
when attaching expanded object
to reference entity
| <code>x</code> <code>:=</code> <code>y</code>
| No, object is copied to new
object of the corresponding
reference type
| Yes
| Yes, except for TYPED_POINTER
that is converted to POINTER before
reattachment
|-
| Reverse assignment (assignment attempt)
| <code>x</code> <code>?=</code> <code>y</code>
| Yes
| No
| Yes. Marked as obsolete (V7.1).
|}
==Feature calls==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Precursor call
| <code>Precursor</code>
| No
| Yes
| Yes
|-
| Non-object call
| <code>c := {COLOR}.green</code>
| No
| Yes
| Yes
|-
| Assigner call
| <eiffel>x [i] := x [i] + 1</eiffel>
| No
| Yes
| Yes
|-
| Bracket expression as call target
| <eiffel>x [i].update</eiffel>
| No
| No
| Yes
|}
==Void-safety==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Attachment marks
| <code>a: attached ANY</code> <br/>
<code>b: detachable ANY</code>
| No
| Yes, attached by default
| Yes, attached by default
|-
| Object test
| <code>attached {STRING} e as o</code>
| No
| Yes
| Yes
|-
| Attached target of a call
| <code>x.f</code>
| No
| Yes
| Yes, by option ''void_safety''
|-
| Properly set variable
| <code>x := value</code> <br/>
<code>use (x)</code>
| No
| Yes
| Yes, by option ''void_safety''
|}
==[[Concurrent programming with SCOOP|SCOOP]]==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! width="160pt"| <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Separate declaration
| <code> a: separate ANY </code>
| No
| No. <code>separate</code> reserved but not used
| Yes. Object attached to <code>a</code> may be handled by different SCOOP processor.
|}
==Expressions==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Bracket expression
| <code>y := x [i]</code>
| No
| Yes
| Yes
|-
| Creation expression
| <code>set_buffer (create {STRING}.make (100))</code>
| No
| Yes
| Yes
|-
| Manifest type
| <code>{MY_TYPE}</code>
| No
| Yes
| Yes
|-
| Manifest [[ET: Other Mechanisms|tuple]]
| <code>[a, b, c]</code>
| No
| Yes
| Yes
|-
| [[ET: Agents|Agent]]
| <code>list.do_all (agent print (?))</code>
| No
| Yes
| Yes
|-
| Once manifest string
| <code>once "abc"</code>
| No
| Yes
| Yes
|}
==Constants==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''Example'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Verbatim string
|
<code>x := "[
This string is left-adjusted.
]"
y := "{
This string is used "as is".
}"</code>
| No
| Yes
| Yes
|-
| Manifest type qualifier
| <code>{INTEGER_8} 123</code>
| No
| Yes
| Yes
|-
| Non-decimal integer
| <code>0xFF</code>
| No
| Yes
| Yes
|-
| Integer with intermediate underscores
| <code>1_000 0xFFFF_0000</code>
| In groups by 3 digits
| Yes
| Yes
|}
==Interfacing with external software==
{| class="doctable"
|-
! <center>'''Feature'''</center>
! <center>'''ETL2'''</center>
! <center>'''ECMA-367'''</center>
! <center>'''EiffelStudio'''</center>
|-
| Access to software written in C
| Basic syntax for any external software
| Registered sub-language
| See details for [[C externals|C externals]].
|-
| Access to software written in C++
| Basic syntax for any external software
| Registered sub-language
| See details for [[C++ Externals|C++ externals]].
|-
| Access to dynamically loaded libraries (DLLs)
| Basic syntax for any external software
| Registered sub-language
| See details for [[uuid:4ad177dd-13ec-c237-99b3-efc9851995a5|Interfacing with DLLs]].
|-
| Other external software
| Basic syntax for any external software
| Unregistered sub-language
| No
|}

64
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki Normal file
View File

@@ -0,0 +1,64 @@
[[Property:title|Definition file]]
[[Property:weight|2]]
[[Property:uuid|3a4b017c-ede1-7af1-2934-c7a28b303764]]
The syntax is pretty simple when you understand what you need to export a feature: you need the name of the '''feature''', the name of the concerned '''class''', and the name of a '''creation procedure'''. What is optional is to specify an '''alias''', an '''index''' and a '''calling convention'''. The index and calling convention are mainly used to create a DLL for windows, and the alias to export the feature under a different name.
===Syntax===
{| border="1"
|-
| '''Export_feature'''
| Class_name [Creation_part] ":" Feature [Optional_part]
|-
| '''Creation_part'''
| "(" feature_name ")"
|-
| '''Optional_part'''
| [Index_part] [Alias_part]
|-
| '''Index_part'''
| "@" integer
|-
| '''Alias_part'''
| "Alias" alias_name
|-
| '''Call_type_part'''
| "call_type" call_type_name
|}
===Example===
<code lang=text>
ROOT_CLASS (make): foo @ 4 Alias my_foo call_type __stdcall</code>
===Constraints===
; on the class: The class cannot be deferred or generic.
; on the feature: It could be any feature except an attribute, an external feature or a deferred feature.
; on the creation procedure: It must have zero argument, and no return type.
; on the alias name: It must be a valid name for a C function.
; on the index: It must be strictly positive.
; on the call type: It must be a valid call type for the targeted platform (useful for Windows only). For Visual C++, the valid calling conventions are __stdcall, __cdecl and __fastcall.
For each feature the required fields are the '''class''', the '''creation procedure''', and of course the '''feature''' itself.
* If the feature is a creation procedure then do not specify any creation, it will use the feature as creation. For example '''ROOT_CLASS: make'''.
* If the class has no creation procedure, do not specify any creation. default_create will be automatically used.
===A definition file===
<code lang=text>
-- EXPORTED FEATURE(s) OF THE SHARED LIBRARY
-- SYSTEM : demo
-- CLASS [BAR]
-- Here get_string uses make_b as creation
BAR (make_b) : get_string
-- Here print_bar uses make_a as creation
BAR (make_a) : print_bar
-- CLASS [ROOT_CLASS]
-- Here the feature is also a creation
ROOT_CLASS : make
ROOT_CLASS (make) : foo
ROOT_CLASS (make) : test_bar
</code>

30
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-builder.wiki Normal file
View File

@@ -0,0 +1,30 @@
[[Property:title|Dynamic library builder]]
[[Property:weight|1]]
[[Property:uuid|e64cdcf2-6da1-98d5-8356-28b50d01374b]]
In order to facilitate the creation of C dynamic libraries using EiffelStudio, a wizard helps generate the definition files used to define the contents of the shared library. If for some reason you need to override the wizard, the [[Definition file|syntactic rules]] of the definition files are available, but their knowledge is not necessary to use the generation of dynamic libraries in EiffelStudio.
The wizard is accessible in the '''Tools'''/ '''Dynamic library builder''' menu.
The dynamic library window that appears when selecting this menu is mainly composed of a list which contains all features that should be exported. This list is course empty at first.
[[Image:shared-library-window]]
{{note|The layout of this wizard is slightly different on Windows and on Unix systems, because the index and calling convention fields never appear on Unix systems. }}
To add a new feature to the definition file, you can either:
* Pick the feature from any place in EiffelStudio and drop it into the list. If several creation procedures exists in the container class, a dialog is popped up to give the choice between all possible creation procedures.
* Or, use the Add command [[Image:16x16--general-add-icon]] in the '''Edit'''/ '''Add''' menu. This pops up a dialog where it is possible to enter manually all parameters for the exported feature.
[[Image:new-exported-feature]]
Other commands of the '''Edit''' menu allow you to remove [[Image:16x16--general-delete-icon]] exported features or to modify their export parameters [[Image:16x16--general-edit-icon]] .
It is also possible to check the validity of the definition file. This command [[Image:view-unmodified-icon]] performs both a global check, to ensure that for example two features do not have the same name or same index in the library, and also local checks, that check for each feature that the parameters are valid.
Other commands, located in the '''File''' menu, give standard file operations, such as opening [[Image:general-open-icon]] a definition file, creating a new definition file [[Image:new-document-icon]] ,or saving the current definition file [[Image:16x16--general-save-icon]] .
{{tip|Although the wizard can handle several files during the same EiffelStudio session, remember that only one file can be used in the project settings to effectively generate a shared library. }}

47
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-generated-files.wiki Normal file
View File

@@ -0,0 +1,47 @@
[[Property:title|Dynamic library: Generated files]]
[[Property:weight|3]]
[[Property:uuid|f3926dd7-eb68-7a82-39f0-b4f5ea891436]]
Once the Eiffel definition file is created, the compiler will generate a set of files and will compile them to generate the Dynamic library into the <code lang="text">EIFGENs/target_name/W_code</code> or <code lang="text">EIFGENs/target_name/F_code</code> directory.
{{note|To generate and compile these files, you have to indicate the definition file that should be used in the [[Advanced Options|advanced node of the project settings]] of your system. This way EiffelStudio will know which one to use. If you do not specify any definition file, nothing will be generated. }}
The set of files is composed of:
* <code lang="text">EIFGENs/target_name/W_code/</code>'''system.def''' (or F_code)
* <code lang="text">EIFGENs/target_name/W_code/</code>'''edynlib.c''' (or F_code)
* <code lang="text">$(ISE_EIFFEL)/studio/config/$(ISE_PLATFORM)/templates/</code>'''egc_dynlib.template''' <br/>
this file will be copied during the compilation into the EIFGENs/target_name/W_code/E1 directory as '''egc_dynlib.c'''
* <code lang="text">$(ISE_EIFFEL)/studio/spec/$(ISE_PLATFORM)/include/</code>'''egc_dynlib.h'''
* and the Makefile
The ''system.def'' is only used on windows, it is the definition file used to generate a DLL when linking.<br/>
Information about the DLL
<code lang=text>LIBRARY demo.dll
DESCRIPTION DEMO.DLL</code>
The following are EXPORTed functions.
<code lang=text>
EXPORTS</code>
This part concerns the run-time. It initializes the run-time and reclaim Eiffel objects.
<code lang=text>
;System
init_rt
reclaim_rt
</code>
The exported for the BAR class:
<code lang=text>; CLASS [BAR]
get_string
print_bar
</code>
The exported for the ROOT_CLASS class:
<code lang=text>; CLASS [ROOT_CLASS]
make
foo
test_bar</code>
The ''edynlib.c'' file is the interface between the Eiffel system and the C code. It contains the declaration and the implementation of the function used to directly call the eiffel feature with its real name.
The <span> ''egc_dynlib.c'' </span> and <span> ''egc_dynlib.h'' </span> files are used for operations performed by the run-time.

13
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki Normal file
View File

@@ -0,0 +1,13 @@
[[Property:title|Dynamic library generation]]
[[Property:weight|-12]]
[[Property:uuid|201551d5-84af-f1ee-deed-b599d4f6e64a]]
The Eiffel compiler offers the possibility to generate a '''dynamic shared library''' based on the system.
Thanks to this dynamic library, it is possible to call Eiffel features from a C program, by using the real names of the features.
In other words, the user can generate a DLL ''(*.dll)'' using features of the system on windows, and/or a shared library ''(*.so)'' on Unix.
For that, the user has first to describe what he wants to export in his dynamic library. This is done via a definition file ''(*.def)'', which specifies what features should be exported. A [[Dynamic library builder|wizard]] helps build the definition file, which makes this step very intuitive. The second step is to select the definition file in the [[Advanced Options|project settings]] to take this definition file into account. This done, the next compilation of the system will yield [[Dynamic library: Generated files|C files]] that can be used to create the shared library.

10
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/index.wiki Normal file
View File

@@ -0,0 +1,10 @@
[[Property:title|Compiler]]
[[Property:weight|-9]]
[[Property:uuid|6ce8a6e1-5f44-8c47-fcf0-549d1ea0ffaf]]
EiffelStudio naturally includes a powerful Eiffel compiler, which is at the core of the IDE. It supports the entire Eiffel programming language as defined in the third edition of ''Eiffel: The Language''.
This compiler uses Eiffel's Melting Ice Technology (TM), which accounts for lightning-fast incremental recompilations, ideal during the development cycle. It also provides finalization, which yields a high level of optimization that should be used for released programs.

34
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki Normal file
View File

@@ -0,0 +1,34 @@
[[Property:title|Melting Ice Technology]]
[[Property:weight|-15]]
[[Property:uuid|17c5cf39-2bb3-67e4-11e3-2b6d021e5df1]]
=Types of compilation provided by Melting Ice=
EiffelStudio relies on Melting Ice Technology, the proprietary compilation mechanism of Eiffel Software, which offers three forms of compilation: '''melting''', '''freezing''', and '''finalizing'''.
==Melting==
Melting is used for making a few changes during typical development activity. The fastest of the mechanisms, typically taking a few seconds after small changes. Melting time is proportional to the size of the changed parts and affected classes, while the time needed to freeze or finalize is partly proportional to the size of the whole system. As long as you do not include new external C/C++ code, a C/C++ compiler is not required. However, execution speed is not optimal. The generated executable is debuggable.
==Freezing==
Freezing generates C code from the active system, and then compiles it into machine code; you must have a C/C++ compiler installed. You need to use this option if you add new agents or external C/C++ calls. Unless you add external code, you can re-freeze every couple of days. The rest of the time, you can melt your software to receive immediate feedback. The speed is still slower than when finalizing, but the generated executable is still debuggable.
==Finalizing==
Finalizing delivers a production version (intermediate or final) of your software. It can be used to measure its performance in operational conditions. Finalization performs extensive time and space optimizations that enable Eiffel to match the efficiency of C/C++; it also creates a stand-alone C package that you can use for cross-platform development. Because of all the optimizations involved, finalizing takes the most time, and the generated executable is not debuggable.
==Precompiling==
Precompilation allows you to create a library in which the classes are already compiled, so when it is used, compile times are decreased. EiffelStudio comes with optional precompiled forms of commonly used libraries. For example, in the Microsoft Windows distribution you can opt for precompiled EiffelBase, or WEL + EiffelBase, or EiffelVision 2 + WEL + EiffelBase. As indicated by these options, the precompilation of a library must also include any other library upon which the target library depends. In other words, it would not be possible to precompile EiffelVision 2 without also including WEL and EiffelBase, too.
=Additional detail=
Melting and freezing generate an executable in the EIFGENs|target_name|W_code subdirectory of the project directory. The executable is composed of a standard executable file named after the system, and of a < ''system name''>.melted file, which is called the Eiffel update file. Although it is recommended to finalize the system when running it from outside EiffelStudio (since the performance is better), it is possible to launch a melted/frozen executable. However, the Eiffel update file is necessary, the executable alone will not run.
Basically, the Eiffel update file incorporates the changes that have been made to the system since it was last frozen. Therefore, it is very small when the system has just been frozen, and progressively becomes bigger each time the system is melted. On the contrary, the executable is only modified when the system is frozen, never when it is melted.
The contents of the Eiffel update file are in a byte code representation which is dynamically interpreted at run-time.

75
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki Normal file
View File

@@ -0,0 +1,75 @@
[[Property:modification_date|Mon, 11 Nov 2019 19:13:26 GMT]]
[[Property:publication_date|Mon, 11 Nov 2019 19:13:26 GMT]]
[[Property:title|Supported C compilers]]
[[Property:weight|-14]]
[[Property:uuid|4d4a70fa-b6da-cecb-83e0-dcc18d6ed54a]]
==Unix/Linux Users:==
EiffelStudio supports `gcc` on most platforms and the native `cc` compiler if it is an ANSI C compiler.
==Microsoft Windows Users==
EiffelStudio supports Microsoft and MinGW compilers on Microsoft Windows.
===Microsoft Visual C++ Users===
EiffelStudio supports versions 10.0 and higher of the Microsoft Visual Studio C++ environment. This is available in Visual Studio 2010 or higher revision, or in version of the Windows SDK 7.1 or higher.
EiffelStudio will automatically detect the location of the C compiler.
By default the installation program will set in the registry keys the <code lang="text">ISE_C_COMPILER</code> key to `msc` (for versions 12.0 and below) or `msc_vc140` (for Visual Studio C++ 2015 and later.)
===MinGW Users===
By default the installation program will set in the registry keys the <code lang="text">ISE_C_COMPILER</code> key to `mingw`.
In versions as late as 6.6, there is a [[EiffelCOM Wizard Guided Tour|restriction]] that prevents the use of EiffelCOM with the MinGW compiler.
===Changing your C compiler on Windows===
You can do it in either of two different ways.
You can manually edit the registry key <code lang="text">HKLM\Software\ISE\EiffelNN</code> and change the value of the <code lang="text">ISE_C_COMPILER</code> string key to either `msc` (`msc_vc140`) or `mingw` depending upon the effect you desire.
Alternatively, you can set the environment variable <code lang="text">ISE_C_COMPILER</code> to either `msc` (`msc_vc140`) or `mingw`.
{| style="width: auto; margin: 0 auto;"
|+ Reference information about supported C compilers on Windows
! Compiler
! Value of <code lang="text">ISE_C_COMPILER</code>
|-
| MinGW
| `mingw`
|-
| Microsoft Visual Studio C++ 2010 (v10.0)
| `msc`
|-
| Microsoft Visual Studio C++ 2012 (v11.0)
| `msc`
|-
| Microsoft Visual Studio C++ 2013 (v12.0)
| `msc`
|-
| Microsoft Visual Studio C++ 2015 (v14.0)
| `msc_vc140`
|-
| Microsoft Visual Studio C++ 2017 (v14.1)
| `msc_vc140`
|-
| Microsoft Visual Studio C++ 2019 (v14.2)
| `msc_vc140`
|-
|}
===Availability of free compilers===
'' Microsoft ''
Download the free [https://visualstudio.microsoft.com/vs/community/|Visual Studio Community Edition]
If required download [https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads|Microsoft Visual C++ Redistributable for Visual Studio 2015, 2017 and 2019].
'' MinGW ''
Copy included with the Eiffel Software distribution.

140
documentation/19.12/eiffelstudio/eiffelstudio-reference/compiler/syntax-level-variant-settings-version.wiki Normal file
View File

@@ -0,0 +1,140 @@
[[Property:title|Syntax level variant settings by version]]
[[Property:weight|-11]]
[[Property:uuid|aa52a183-c616-4590-5e7e-f9b9e2a71f14]]
The Eiffel Software compiler provides a set of options, available in [[General Target Options|Project Settings]], which allows users to [[Setting the syntax variant|select a variant of the Eiffel programming language syntax]] that best suits their needs. The meanings of these options, and in fact the options themselves, are subject to change from one version to the next. Below you will find a table that defines the meaning of the syntax level variants for each version.
The options are distinguished by how the compiler handles the processing of certain words found in Eiffel text which may be:
# Associated with language constructs, or
# Allowed as identifiers, or
# In the case of some options as either keywords or identifiers depending upon the context in which the words are found.
{| border="1" style="border-collapse: collapse; border-style: solid;"
|+ '''Legend'''
| style="color: navy;" | '''keyword'''
| Accepted as a keyword
|-
| style="color: blue;" | '''keyword'''
| Accepted as a keyword with a warning
|-
| style="color: maroon;" | '''keyword'''
| Accepted as a keyword or if grammar permits as an identifier with a warning
|-
| style="color: gray;" | name
| Accepted as an identifier with a warning
|-
| style="color: black;" | name
| Accepted as an identifier
|}
{| border="1" style="width: 100%; border-collapse: collapse; border-style: solid;"
|+ '''Constructs affected by the ''syntax'' project setting'''
|-
! rowspan="2" style="text-align: center; valign: center;" | Release
! colspan="4" style="text-align: center;" | Setting value*
|-
! Obsolete
! Transitional
! Standard
! Provisional
|-
! rowspan="9" style="valign: center; text-align: center;" | [[Release notes for EiffelStudio 7.0 | 7.0]] and [[EiffelStudio release notes | more recent]]
| style="color: gray;" | across
| style="color: maroon;" | '''across'''
| style="color: navy;" | '''across'''
| style="color: navy;" | '''across'''
|-
| style="color: maroon;" | '''assign'''
| style="color: maroon;" | '''assign'''
| style="color: navy;" | '''assign'''
| style="color: navy;" | '''assign'''
|-
| style="color: gray;" | attached
| style="color: maroon;" | '''attached'''
| style="color: navy;" | '''attached'''
| style="color: navy;" | '''attached'''
|-
| style="color: gray;" | attribute
| style="color: maroon;" | '''attribute'''
| style="color: navy;" | '''attribute'''
| style="color: navy;" | '''attribute'''
|-
| style="color: gray;" | detachable
| style="color: maroon;" | '''detachable'''
| style="color: navy;" | '''detachable'''
| style="color: navy;" | '''detachable'''
|-
| style="color: navy;" | '''indexing'''
| style="color: blue;" | '''indexing'''
| style="color: black;" | indexing
| style="color: black;" | indexing
|-
| style="color: navy;" | '''is'''
| style="color: blue;" | '''is'''
| style="color: black;" | is
| style="color: black;" | is
|-
| style="color: gray;" | note
| style="color: navy;" | '''note'''
| style="color: navy;" | '''note'''
| style="color: navy;" | '''note'''
|-
| style="color: gray;" | some
| style="color: maroon;" | '''some'''
| style="color: navy;" | '''some'''
| style="color: navy;" | '''some'''
|- style="border-top: 4px solid gray;"
! rowspan="9" style="valign: center; text-align: center;" | [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]]
| style="color: gray;" | across
| style="color: gray;" | across
| style="color: gray;" | across
| style="color: maroon;" | '''across'''
|-
| style="color: maroon;" | '''assign'''
| style="color: maroon;" | '''assign'''
| style="color: navy;" | '''assign'''
| style="color: maroon;" | '''assign'''
|-
| style="color: gray;" | attached
| style="color: maroon;" | '''attached'''
| style="color: navy;" | '''attached'''
| style="color: maroon;" | '''attached'''
|-
| style="color: gray;" | attribute
| style="color: maroon;" | '''attribute'''
| style="color: navy;" | '''attribute'''
| style="color: maroon;" | '''attribute'''
|-
| style="color: gray;" | detachable
| style="color: maroon;" | '''detachable'''
| style="color: navy;" | '''detachable'''
| style="color: maroon;" | '''detachable'''
|-
| style="color: navy;" | '''indexing'''
| style="color: blue;" | '''indexing'''
| style="color: black;" | indexing
| style="color: black;" | indexing
|-
| style="color: navy;" | '''is'''
| style="color: blue;" | '''is'''
| style="color: black;" | is
| style="color: black;" | is
|-
| style="color: gray;" | note
| style="color: navy;" | '''note'''
| style="color: navy;" | '''note'''
| style="color: navy;" | '''note'''
|-
| style="color: gray;" | some
| style="color: gray;" | some
| style="color: gray;" | some
| style="color: maroon;" | '''some'''
|}
<nowiki>*</nowiki> A general explanation of what each variant setting means can be found in the section on [[Setting the syntax variant|setting the syntax variant.]]