kc3-lang/libxkbcommon/src/xkbcomp/types.c
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
00e3058e | 2023-11-06 21:53:51 | Prevent recursive includes of keymap components - Add check for recursive includes of keymap components. It relies on limiting the include depth. The threshold is currently to 15, which seems reasonable with plenty of margin for keymaps in the wild. - Add corresponding new log message `recursive-include`. - Add tests for recursive includes. | |
|
2b714310 | 2023-10-25 20:01:22 | Fix memory leaks in key types compilation When there is no error the types are “stolen” and copied to the keymap. But when there is an error, `MergeIncludedKeyTypes` just return without “stealing” nor freeing the types. Fixed by explicitly freeing the key types. Fixed another leak in `HandleKeyTypeDef` that may occur if there is an error in parsing a type definition. | |
|
c0065c95 | 2023-09-21 20:06:27 | Messages: merge macros with and without message code Previously we had two types of macros for logging: with and without message code. They were intended to be merged afterwards. The idea is to use a special code – `XKB_LOG_MESSAGE_NO_ID = 0` – that should *not* be displayed. But we would like to avoid checking this special code at run time. This is achieved using macro tricks; they are detailed in the code (see: `PREPEND_MESSAGE_ID`). Now it is also easier to spot the remaining undocumented log entries: just search `XKB_LOG_MESSAGE_NO_ID`. | |
|
a83d745b | 2023-09-21 20:06:27 | Messages: add new messages to registry This commit is another step to identify and document the maximum number of logging messages. Bulk changes: - Rename `conflicting-key-type` to `conflicting-key-type-merging-groups`. Giving more context in the name allow us to introduce `conflicting-key-type-definitions` later. - Add conflicting-key-type-definitions - Add conflicting-key-type-map-entry - Add undeclared-modifiers-in-key-type Also improve the log messages. - Add conflicting-key-type-preserve-entries - Use XKB_ERROR_UNSUPPORTED_MODIFIER_MASK - Add illegal-key-type-preserve-result - Add conflicting-key-type-level-names - Add duplicate-entry - Add unsupported-symbols-field - Add missing-symbols-group-name-index - Use XKB_ERROR_WRONG_FIELD_TYPE - Add conflicting-key-name - Use XKB_WARNING_UNDEFINED_KEYCODE - Add illegal-keycode-alias - Add unsupported-geometry-section - Add missing-default-section - Add XKB_LOG_MESSAGE_NO_ID - Rename log_vrb_with_code to log_vrb - Use ERROR_WRONG_FIELD_TYPE & ERROR_INVALID_SYNTAX - Add unknown-identifier - Add invalid-expression-type - Add invalid-operation + fixes - Add unknown-operator - Rename ERROR_UNKNOWN_IDENTIFIER to ERROR_INVALID_IDENTIFIER - Add undeclared-virtual-modifier - Add expected-array-entry - Add invalid-include-statement - Add included-file-not-found - Add allocation-error - Add invalid-included-file - Process symbols.c - Add invalid-value - Add invalid-real-modifier - Add unknown-field - Add wrong-scope - Add invalid-modmap-entry - Add wrong-statement-type - Add conflicting-key-symbols-entry - Add invalid-set-default-statement | |
|
ef81d04e | 2023-09-18 18:17:34 | Structured log messages with a message registry Currently there is little structure in the log messages, making difficult to use them for the following use cases: - A user looking for help about a log message: the user probably uses a search engine, thus the results will depend on the proper indexing of our documentation and the various forums. It relies only on the wording of the message, which may change with time. - A user wants to filter the logs resulting of the use of one of the components of xkbcommon. A typical example would be testing xkeyboard-config against libxkbcommon. It requires the use of a pattern (simple words detection or regex). The issue is that the pattern may become silently out-of-sync with xkbcommon. A common practice (e.g. in compilers) is to assign unique error codes to reference theses messages, along with an error index for documentation. Thus this commit implements the following features: - Create a message registry (message-registry.yaml) that defines the log messages produced by xkbcommon. This is a simple YAML file that provides, for each message: - A unique numeric code as a short identifier. It is used in the output message and thus can be easily be filtered to spot errors or searched in the internet. It must not change: if the semantics of message changes, it is better to introduce a new message for clarity. - A unique text identifier, meant for two uses: 1. Generate constants dealing with log information in our code base. 2. Generate human-friendly names for the documentation. - A type: currently warning or error. Used to prefix the constants (see hereinabove) and for basic classification in documentation. - A short description, used as concise and mandatory documentation. - An optionnal detailed description. - Optional examples, intended to help the user to fix issues themself. - Version of xkbcommon it was added. For old entries this often unknown, so they will default to 1.0.0. - Version of xkbcommon it was removed (optional) No entry should ever be deleted from this index, even if the message is not used anymore: it ensures we have unique identifiers along the history of xkbcommon, and that users can refer to the documentation even for older versions. - Add the script update-message-registry.py to generate the following files: - messages.h: message code enumeration for the messages currently used in the code base. Currently a private API. - message.registry.md: the error index documentation page. - Modify the logging functions to use structured messages. This is a work in progress. | |
 |
40aab05e | 2019-12-27 13:03:20 | build: include config.h manually Previously we included it with an `-include` compiler directive. But that's not portable. And it's better to be explicit anyway. Every .c file should have `include "config.h"` first thing. Signed-off-by: Ran Benita <ran@unusedvar.com> | |
 |
26453b84 | 2017-12-12 14:30:21 | keymap: fix NULL dereference when dumping the default fallback type The default fallback type uses type->level_names = NULL but the keymap-dump code was not checking this case. Instead of adding more workarounds and possible bugs (e.g. previous commit), let's just keep the number of level names separately. This has the additional advantage retains extraneous level name if someone adds them for some reason. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9f85d6b7 | 2017-12-12 14:02:17 | xkbcomp/types: fix types being assigned the wrong number of levels in some circumstances The buggy code assigned the number of levels based on the number of level names in the definition, instead of the actual number of levels! This would completely break type definitions which do not give names to levels. This was not noticed for so long because xkeyboard-config always gives names to all levels. This regressed in 61fed8dab9b8e27981f36ffc96666d7376546e30. Reported-by: Gatis Paeglis <gatis.paeglis@qt.io> Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
c03834a1 | 2014-10-23 21:00:20 | Reduce variable scopes Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4a660d7f | 2014-10-18 19:47:19 | xkbcomp: remove file->topName It is useless. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
61fed8da | 2014-07-26 00:19:34 | Replace darray_mem with a new darray_steal That's a more declarative interface. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
5f5b960c | 2014-07-25 23:40:40 | types: refactor CopyKeyTypesToKeymap So it's OOM-safe and doesn't clobber keymap on failure. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
07fb6a6c | 2014-04-22 18:18:13 | xkbcomp: don't align enum values Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
28a22ba2 | 2014-04-22 18:05:24 | xkbcomp: use straight assignment instead of CopyModSet Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
787faf36 | 2014-04-22 12:23:36 | keymap: don't use darray in xkb_mod_set Instead just statically allocate the mods array (of size MAX_MOD_SIZE = 32). The limit is not going anywhere, and static allocations are nicer (nicer code, no OOM, etc.). It's also small and dense enough. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
f2cbeda9 | 2013-02-09 18:25:12 | types: use xkb_mod_set instead of entire keymap Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
b5655b3d | 2013-02-08 14:39:38 | vmod: take xkb_mod_set instead of the entire keymap This is the only place where the modifier information is modified. We will make it local to a given XKB file (after which it will be merged into the keymap). Currently it changes the keymap directly, which sidesteps the abstraction and leaves side-effects even if the XkbFile's compilation fails. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9fbcf6bb | 2013-02-08 13:56:41 | expr: take xkb_mod_set instead of the entire keymap The modifier-resolving functions only need the modifier information. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
edc0aef5 | 2013-02-08 13:21:27 | text: take xkb_mod_set instead of the entire keymap The modifier printing functions only need the modifier information, they don't care about keys or leds, etc. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
36cbecc5 | 2013-02-08 00:14:49 | types: separate ctx Separate the ctx object to its own field in CompatInfo, instead of doing keymap->ctx. The compilation functions should not have direct access to the keymap; instead they should process the files with their own independent state (in the *Info structs) as much as possible, and only at the end should they be copied (i.e. commited) to the keymap. If the compilation fails, it leaves no by-products. It's also just good form. This was seemingly the original author's intention, but I suppose he cut a few corners (mostly with the handling of virtual modifiers, which are threaded through types -> compat -> symbols). This commit is the first step and may look artificial; however the 'keymap' field will be removed shortly. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
5bd273a7 | 2012-11-27 10:42:15 | vmod: bring back support for direct vmod -> real mod mapping This brings back the functionality that was removed in b9c87eb710ba4a86455601ca8c5a516b25e20366. Though it is not used in xkeyboard-config, from our current perspective it can be quite useful to be able to set the mappings directly, thus sidestepping the ugly and legacy-ridden modifier_map statement. Here's an example of how to get rid of modifier_map statements (though that would break core-X11 applications, since they must have the mappings through keysyms): virtual_modifiers NumLock = Mod2; virtual_modifiers Alt = Mod1; // Would be nice to map these to Alt, but that would be // incompatible with xkbcomp and somewhat complicated virtual_modifiers LAlt = Mod1; virtual_modifiers RAlt = Mod1; virtual_modifiers LevelThree = Mod5; virtual_modifiers RControl = Control; virtual_modifiers LControl = Control; virtual_modifiers Super = Mod4; virtual_modifiers Meta = Mod1; virtual_modifiers Hyper = Mod4; virtual_modifiers AltGr = Mod5; virtual_modifiers LShift = Shift; virtual_modifiers RShift = Shift; Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
35cab168 | 2014-02-09 16:49:45 | types: steal types when merging if possible Like we do everywhere else. Removes some unnecessary allocations and copying. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
3923aa71 | 2014-02-09 11:27:34 | doc: move some file comments into txt files in doc/ Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
bbc69b63 | 2014-01-12 10:53:23 | action, types: remove unused Report functions Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9e801ff7 | 2013-07-21 17:01:20 | ctx: adapt to the len-aware atom functions xkb_atom_intern now takes a len parameter. Turns out though that almost all of our xkb_atom_intern calls are called on string literals, the length of which we know statically. So we add a macro to micro-optimize this case. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
4b560287 | 2013-07-18 14:50:21 | xkbcomp: escape the section names before storing them in the keymap This ensures the names are escaped before having any interaction with the user. This was caught by noticing dump(compile(dump())) != dump. Since that's a nice test we add it to stringcomp. https://bugs.freedesktop.org/show_bug.cgi?id=67032 Reported-By: Auke Booij Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
57bfde3a | 2013-03-04 18:41:13 | keymap: rename xkb_kt_map_entry to xkb_key_type_entry That's a better name and fits more nicely. Also change type->map to type->entries. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
6a39a065 | 2013-03-04 18:35:56 | Fix pointer style nit (I really dislike this one for some reason..) Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2b6e576f | 2013-03-04 14:04:49 | types: remove file_id See previous commit. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
2ddb9e4f | 2013-03-04 14:00:44 | types: put all copy-to-keymap code in one function Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
614f60e3 | 2013-03-03 00:11:27 | xkbcomp: handle XKB file include's better The 'merge_mode' situation is quite messy, and we've introduced a regression compared to original xkbcomp: when handling a composite include statement, such as replace "foo(bar)+baz(bla)|doo:dee" and merging the entire resulting *Info back into the including *Info, we actually use the merge mode that is set by the last part (here it is "augment" because of the '|'), when we should be using the one set for the whole statement (here "replace"). We also take the opportunity to clean up a bit. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
540feef3 | 2013-03-01 13:51:13 | More spelling errors Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a46e4cc1 | 2013-02-25 00:19:51 | Fix dead assignments "Value stored to 'stmt' is never read" "Value stored to 'grp_to_use' is never read" And change 'grp' to 'group' if we're here. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
dd81d5e0 | 2013-02-08 00:07:28 | Change some log functions to take ctx instead of keymap They don't need the keymap, only the context. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a1124b59 | 2012-10-06 17:42:21 | expr: unify the real and virtual modifier functions This again pushes the mod type annotation to the original call site, to make it easier to grep to see where the real/virtual distinction matters. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
39232e6d | 2012-10-06 17:21:09 | Remove now-unneeded mod type annotations Most of the mod type annotations can now be changed to MOD_BOTH, because if you pass a mask which can only contain real mods in the first place to e.g. ModMaskText, then MOD_REAL and MOD_BOTH will give the same result. In the cases where MOD_BOTH is only ever the argument, we just remove it. What's left is where it really "matters". Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
9ebd2f67 | 2012-10-06 14:34:17 | text: explicitly take mod_type in mod functions This essentially "tags" each invocation of the functions with the modifier type of the argument, which allows for easy grepping for them (with the aim being, to remove anything but MOD_BOTH). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
aed3140e | 2012-10-05 21:06:34 | Remove VModInfo for now VModInfo currently is only used to track which virtual modifiers were declared in the file which owns the VModInfo. This, in turn, is only used in ResolveVirtualModifier, which in turn is only used to resolve the virtualModifier field in an interpret statement (compat.c). In other words, it is used to ensure that interprets can only use a vmod which was declared in the same map. We remove this now, because it doesn't do much and distracts from other changes; we will later re-add it properly. Specificly, we will make it so that virtual modifiers are not the exception in that they modify the keymap directly, instead of keeping the changes in some *Info struct and commiting them to the keymap at the end of the compilation. (This is bad because if a vmod is added to the keymap, and then the compilation of this specific file fails, the change sticks around nonetheless). Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1f4009d4 | 2012-10-04 19:44:47 | vmod: remove merge argument from HandleVModDef It's unused and unneeded. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
a75989b9 | 2012-10-04 12:39:22 | Omit struct '_Name' from non-recursive struct typedefs Just a pet peeve. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
0dd40125 | 2012-09-22 10:58:00 | API: add _context prefix to log-related functions This is to follow the general scheme set by all of the other API functions. Since no one is using these functions yet, we don't (actually better not) add the old names to xkbcommon-compat.h. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
96c21e15 | 2012-09-14 00:21:54 | Clean up Init/Clear functions - The Clear* functions should just free the memory associated with the object. If the object is used again, it is Init'd again. - s/Free/Clear if the actual pointer is not free'd. - Zeroise object in Init and only initialize non-zero fields. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1a996883 | 2012-08-31 19:05:49 | expr: make ResolveString return an atom Almost all callers do xkb_atom_intern on the currently returned string, while ResolveString converts the atom to the string to begin with... uselss double work. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8d7d9792 | 2012-08-28 00:42:59 | log: replace "priority" by "level" everywhere Now that we don't use syslog, "level" does sound more commonplace. We should change it while there is still nobody using it. Also leave some space between the integers of the xkb_log_level enum values, if we ever need to shove more in between. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
1736e7da | 2012-08-31 12:12:13 | types: don't strdup a default name None of the other files does that. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
149e1b2f | 2012-08-31 12:06:50 | types: use darray for KeyTypesInfo instead of list Simpler, uses less memory and more efficient. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8654d36e | 2012-08-27 23:00:07 | types: remove outdated comments The code is pretty straightforward now... Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
d3ddcf70 | 2012-08-15 21:45:02 | expr: move op_type/value_type_to_string functions to ast Generally the enum-to-string function should appear where the enum is defined. Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
eaa50c45 | 2012-08-15 10:10:44 | xkbcomp: seperate keymap-copying code from Compile functions Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
8f1ee629 | 2012-08-14 14:42:57 | types: add "Effects on keymap" to overview Signed-off-by: Ran Benita <ran234@gmail.com> | |
|
cdc228ea | 2012-08-13 11:00:43 | Organize xkbcomp/ header files Various non-functional changes: - Re-add keycodes.h and move some stuff there. - Add parser-priv.h for internal bison/flex stuff. - Don't include headers from other headers, such that file dependencies are immediate in each file. - Rename xkbcomp.h -> ast.h, parseutils.{c,h} -> ast-build.{c,h} - Rename path.{c,h} -> include.{c,h} - Rename keytypes.c -> types.c - Make the naming of XkbFile-related functions more consistent. - Move xkb_map_{new,ref,unref} to map.c. - Remove most extern keyword from function declarations, it's just noise (XKB_EXPORT is what's important here). - Append XKBCOMP_ to include guards. - Shuffle some code around to make all of this work. Splitting this would be a headache.. Signed-off-by: Ran Benita <ran234@gmail.com> |