Rename .fc to .func

docs/func/builtins.md

@@ -1,5 +1,5 @@
 # Built-ins
-This section describes some language constructions which are less fundamental that ones described in previous sections. They could be defined in [stdlib.fc](/func/stdlib.md), but it would leave less room for FunC optimizer.
+This section describes some language constructions which are less fundamental that ones described in previous sections. They could be defined in [stdlib.func](/func/stdlib.md), but it would leave less room for FunC optimizer.
 
 ## Throwing exceptions
 Exceptions can be thrown by conditional primitives `throw_if` and `throw_unless` and by unconditional `throw`. The first argument is the error code, the second is the condition (`throw` has only one argument).

docs/func/functions.md

@@ -35,7 +35,7 @@ where `[ ... ]` correspond to an optional entry.
 ### Function name
 Function name can be any [identifier](/func/literals_identifiers?id=identifiers) and also it can start with `.` or `~` symbols. The meaning of those symbols is [explained](func/statements?id=methods-calls) in statements section.
 
-For example, `udict_add_builder?`, `dict_set` and `~dict_set` are valid and different function names (they are defined in [stdlib.fc](/func/stdlib.md)).
+For example, `udict_add_builder?`, `dict_set` and `~dict_set` are valid and different function names (they are defined in [stdlib.func](/func/stdlib.md)).
 
 #### Special function names
 FunC (actually Fift assembler) has several reserved function names with predefined [ids](/func/functions.md?id=method_id).
@@ -92,7 +92,7 @@ There are three types of specifiers: `impure`, `inline`/`inline_ref` and `method
 
 If `impure` is not specified and the result of the function call is not used, then FunC compiler may and will delete this function call.
 
-For example, in [stdlib.fc](/func/stdlib.md) function
+For example, in [stdlib.func](/func/stdlib.md) function
 ```
 int random() impure asm "RANDU256";
 ```

docs/func/literals_identifiers.md

@@ -26,7 +26,7 @@ For example, those are valid identifier:
 
 `'` at the end of the name of a variable is conventionally used when some modified version of the old value is introduced. For example, almost all modifying built-in primitives for hashmap manipulation (except ones with prefix `~`) take a hashmap and return a new version of the hashmap along with some other data, if necessary. It is convenient to name those values with the same name suffixed by `'`.
 
-Suffix `?` is usually used for boolean variables (TVM hasn't built-in type bool; bools are represented by integers: 0 is false and -1 is true) or for functions that returns some flag, usually indicating success of the operation (like `udict_get?` from [stdlib.fc](/func/stdlib.md)).
+Suffix `?` is usually used for boolean variables (TVM hasn't built-in type bool; bools are represented by integers: 0 is false and -1 is true) or for functions that returns some flag, usually indicating success of the operation (like `udict_get?` from [stdlib.func](/func/stdlib.md)).
 
 Those are not valid identifiers:
 - `take(first)Entry`

docs/func/stdlib.md

@@ -1,5 +1,5 @@
 # FunC standard library
-This section discuss the stdlib.fc library.
+This section discuss the stdlib.func library.
 
 Currently the library is just a wrapper for most common assembler TVM commands, which aren't built-ins. Description of every TVM command used in the library can be found in [TVM documentation](https://newton-blockchain.github.io/docs/tvm.pdf) (Appendix A). Some of the descriptions were borrowed into this document.
 

docs/howto/config-params.md

@@ -292,4 +292,4 @@ It may happen that the code of the configuration smart contract itself or the co
 
 Alternatively, critical configuration parameters `0` (the address of the configuration smart contract) or `1` (the address of the elector smart contract) can be changed to other values, that must correspond to already existing and correctly initialized smart contracts. In particular, the new configuration smart contract must contain a valid configuration dictionary in the first reference of its persistent data. Since it is not so easy to correctly transfer changing data (such as the list of active configuration proposals, or the previous and current participant lists of validator elections) between different smart contracts, in most cases it is better to upgrade the code of existing smart contract rather than to change the configuration smart contract address.
 
-There are two auxiliary scripts used to create such configuration proposals to upgrade the code of the configuration or elector smart contract. Namely, `create-config-upgrade-proposal.fif` loads a Fift assembler source file (`auto/config-code.fif` by default, corresponding to the code automatically generated by FunC compiler from `crypto/smartcont/config-code.fc`) and creates the corresponding configuration proposal (for configuration parameter `-1000`). Similarly, `create-elector-upgrade-proposal.fif` loads a Fift assembler source file (`auto/elector-code.fif` by default) and uses it to create a configuration proposal for configuration parameter `-1001`. In this way creating configuration proposals to upgrade one of these two smart contracts should be very simple. However, one should also publish the modified FunC source of the smart contract, the exact version of the FunC compiler used to compile it, so that all validators (or rather their operators) would be able to reproduce the code in the configuration proposal (and compare the hashes), and study and discuss the source code and the changes in this code before deciding to vote for or against proposed changes.
+There are two auxiliary scripts used to create such configuration proposals to upgrade the code of the configuration or elector smart contract. Namely, `create-config-upgrade-proposal.fif` loads a Fift assembler source file (`auto/config-code.fif` by default, corresponding to the code automatically generated by FunC compiler from `crypto/smartcont/config-code.func`) and creates the corresponding configuration proposal (for configuration parameter `-1000`). Similarly, `create-elector-upgrade-proposal.fif` loads a Fift assembler source file (`auto/elector-code.fif` by default) and uses it to create a configuration proposal for configuration parameter `-1001`. In this way creating configuration proposals to upgrade one of these two smart contracts should be very simple. However, one should also publish the modified FunC source of the smart contract, the exact version of the FunC compiler used to compile it, so that all validators (or rather their operators) would be able to reproduce the code in the configuration proposal (and compare the hashes), and study and discuss the source code and the changes in this code before deciding to vote for or against proposed changes.