summaryrefslogtreecommitdiff
path: root/py/map.c
diff options
context:
space:
mode:
authorAngus Gratton <angus@redyak.com.au>2024-02-27 15:32:29 +1100
committerDamien George <damien@micropython.org>2024-03-07 14:20:42 +1100
commitdecf8e6a8bb940d5829ca3296790631fcece7b21 (patch)
tree55b7cd31de14b73e4b72d49344e9084f402767a9 /py/map.c
parentb3f2f18f927fa2fad10daf63d8c391331f5edf58 (diff)
all: Remove the "STATIC" macro and just use "static" instead.
The STATIC macro was introduced a very long time ago in commit d5df6cd44a433d6253a61cb0f987835fbc06b2de. The original reason for this was to have the option to define it to nothing so that all static functions become global functions and therefore visible to certain debug tools, so one could do function size comparison and other things. This STATIC feature is rarely (if ever) used. And with the use of LTO and heavy inline optimisation, analysing the size of individual functions when they are not static is not a good representation of the size of code when fully optimised. So the macro does not have much use and it's simpler to just remove it. Then you know exactly what it's doing. For example, newcomers don't have to learn what the STATIC macro is and why it exists. Reading the code is also less "loud" with a lowercase static. One other minor point in favour of removing it, is that it stops bugs with `STATIC inline`, which should always be `static inline`. Methodology for this commit was: 1) git ls-files | egrep '\.[ch]$' | \ xargs sed -Ei "s/(^| )STATIC($| )/\1static\2/" 2) Do some manual cleanup in the diff by searching for the word STATIC in comments and changing those back. 3) "git-grep STATIC docs/", manually fixed those cases. 4) "rg -t python STATIC", manually fixed codegen lines that used STATIC. This work was funded through GitHub Sponsors. Signed-off-by: Angus Gratton <angus@redyak.com.au>
Diffstat (limited to 'py/map.c')
-rw-r--r--py/map.c8
1 files changed, 4 insertions, 4 deletions
diff --git a/py/map.c b/py/map.c
index c18df5a9f..d40e3dc4d 100644
--- a/py/map.c
+++ b/py/map.c
@@ -65,14 +65,14 @@
// The first set of sizes are chosen so the allocation fits exactly in a
// 4-word GC block, and it's not so important for these small values to be
// prime. The latter sizes are prime and increase at an increasing rate.
-STATIC const uint16_t hash_allocation_sizes[] = {
+static const uint16_t hash_allocation_sizes[] = {
0, 2, 4, 6, 8, 10, 12, // +2
17, 23, 29, 37, 47, 59, 73, // *1.25
97, 127, 167, 223, 293, 389, 521, 691, 919, 1223, 1627, 2161, // *1.33
3229, 4831, 7243, 10861, 16273, 24407, 36607, 54907, // *1.5
};
-STATIC size_t get_hash_alloc_greater_or_equal_to(size_t x) {
+static size_t get_hash_alloc_greater_or_equal_to(size_t x) {
for (size_t i = 0; i < MP_ARRAY_SIZE(hash_allocation_sizes); i++) {
if (hash_allocation_sizes[i] >= x) {
return hash_allocation_sizes[i];
@@ -128,7 +128,7 @@ void mp_map_clear(mp_map_t *map) {
map->table = NULL;
}
-STATIC void mp_map_rehash(mp_map_t *map) {
+static void mp_map_rehash(mp_map_t *map) {
size_t old_alloc = map->alloc;
size_t new_alloc = get_hash_alloc_greater_or_equal_to(map->alloc + 1);
DEBUG_printf("mp_map_rehash(%p): " UINT_FMT " -> " UINT_FMT "\n", map, old_alloc, new_alloc);
@@ -332,7 +332,7 @@ void mp_set_init(mp_set_t *set, size_t n) {
set->table = m_new0(mp_obj_t, set->alloc);
}
-STATIC void mp_set_rehash(mp_set_t *set) {
+static void mp_set_rehash(mp_set_t *set) {
size_t old_alloc = set->alloc;
mp_obj_t *old_table = set->table;
set->alloc = get_hash_alloc_greater_or_equal_to(set->alloc + 1);