bnjbvr assigned Issue #1164 (assigned to bnjbvr):
Settings have weird naming schemes so far: some of them use the form "verb + nouns" (enable_verifier), others use "nouns + verb in past form" (probestack_enabled), and others only have nouns (colocated_libcalls).
We should use the form "verb + nouns" or only nouns, but get away from other forms. A few things could be clarified too. So I propose the following renamings:
- colocated_calls => use_colocated_calls
- allones_funcaddrs => emit_all_ones_funcaddrs (This one is not ideal, but "allones" in a single word trips me up each time I read it. Maybe emit_all_ones_for_funcaddrs?)
- probestack_enabled => enable_probestack
- jump_tables_enabled => enable_jump_tables
I've also thought about renaming baldrdash_prologue_words => baldrdash_num_prologue_words, but this would repeat the setting type in addition to the type present in signature if #976 were to be implemented.
If that's agreed upon, I'm happy to do the work here. It's going to an API breaking change too. If you have ideas or opinions about names, it's a good time to chime in!
bnjbvr commented on Issue #1164:
Fixed by https://github.com/bytecodealliance/cranelift/commit/3268b0d11f6646b95e250d9f5eba22756434bcef
bnjbvr closed Issue #1164 (assigned to bnjbvr):
Settings have weird naming schemes so far: some of them use the form "verb + nouns" (enable_verifier), others use "nouns + verb in past form" (probestack_enabled), and others only have nouns (colocated_libcalls).
We should use the form "verb + nouns" or only nouns, but get away from other forms. A few things could be clarified too. So I propose the following renamings:
- colocated_calls => use_colocated_calls
- allones_funcaddrs => emit_all_ones_funcaddrs (This one is not ideal, but "allones" in a single word trips me up each time I read it. Maybe emit_all_ones_for_funcaddrs?)
- probestack_enabled => enable_probestack
- jump_tables_enabled => enable_jump_tables
I've also thought about renaming baldrdash_prologue_words => baldrdash_num_prologue_words, but this would repeat the setting type in addition to the type present in signature if #976 were to be implemented.
If that's agreed upon, I'm happy to do the work here. It's going to an API breaking change too. If you have ideas or opinions about names, it's a good time to chime in!
Last updated: Nov 22 2024 at 16:03 UTC