rneovim.git/src/nvim/generators, branch 20230125_mix Neovim fork with Rahm's personal hacks. build: make generated source files reproducible #21586 2023-01-23T09:26:46+00:00 Arnout Engelen arnout@engelen.eu 2023-01-23T09:26:46+00:00 cb757f2663e6950e655c6306d713338dfa66b18d Problem: Build is not reproducible, because generated source files (.c/.h/) are not deterministic, mostly because Lua pairs() is unordered by design (for security). https://github.com/LuaJIT/LuaJIT/issues/626#issuecomment-707005671 https://www.lua.org/manual/5.1/manual.html#pdf-next > The order in which the indices are enumerated is not specified [...] > >> The hardening of the VM deliberately randomizes string hashes. This in >> turn randomizes the iteration order of tables with string keys. Solution: - Update the code generation scripts to be deterministic. - That is only a partial solution: the exported function (funcs_metadata.generated.h) and ui event (ui_events_metadata.generated.h) metadata have some mpack'ed tables, which are not serialized deterministically. - As a workaround, introduce `PRG_GEN_LUA` cmake setting, so you can inject a modified build of luajit (with LUAJIT_SECURITY_PRN=0) that preserves table order. - Longer-term we should change the mpack'ed data structure so it no longer uses tables keyed by strings. Closes #20124 Co-Authored-By: dundargoc <gocdundar@gmail.com> Co-Authored-By: Arnout Engelen <arnout@bzzt.net> 
Problem:
Build is not reproducible, because generated source files (.c/.h/) are not
deterministic, mostly because Lua pairs() is unordered by design (for security).

https://github.com/LuaJIT/LuaJIT/issues/626#issuecomment-707005671
https://www.lua.org/manual/5.1/manual.html#pdf-next
> The order in which the indices are enumerated is not specified [...]
>
>> The hardening of the VM deliberately randomizes string hashes. This in
>> turn randomizes the iteration order of tables with string keys.

Solution:
- Update the code generation scripts to be deterministic.
    - That is only a partial solution: the exported function
      (funcs_metadata.generated.h) and ui event
      (ui_events_metadata.generated.h) metadata have some mpack'ed
      tables, which are not serialized deterministically.
    - As a workaround, introduce `PRG_GEN_LUA` cmake setting, so you can
      inject a modified build of luajit (with LUAJIT_SECURITY_PRN=0)
      that preserves table order.
    - Longer-term we should change the mpack'ed data structure so it no
      longer uses tables keyed by strings.

Closes #20124

Co-Authored-By: dundargoc <gocdundar@gmail.com>
Co-Authored-By: Arnout Engelen <arnout@bzzt.net>
 refactor(ui): devirtualize the ui layer 2023-01-05T08:48:26+00:00 bfredl bjorn.linse@gmail.com 2022-12-30T21:17:01+00:00 47ba78f89a1f0bba8168b4408bc55a3024d5ab97 - The defined interface for the UI is only the RPC protocol. The original UI interface as an array of function pointers fill no function. - On the server, all the UI:s are all RPC channels. - ui.c is only used on the server. - The compositor is a preprocessing step for single-grid UI:s - on the client, ui_client and tui talk directly to each other - we still do module separation, as ui_client.c could form the basis of a libnvim client module later. Items for later PR:s - vim.ui_attach is still an unhappy child, reconsider based on plugin experience. - the flags in ui_events.in.h are still a mess. Can be simplified now. - UX for remote attachment needs more work. - startup for client can be simplified further (think of the millisecs we can save) 
- The defined interface for the UI is only the RPC protocol. The original
  UI interface as an array of function pointers fill no function.
- On the server, all the UI:s are all RPC channels.
  - ui.c is only used on the server.
  - The compositor is a preprocessing step for single-grid UI:s
- on the client, ui_client and tui talk directly to each other
  - we still do module separation, as ui_client.c could form the basis
    of a libnvim client module later.

Items for later PR:s
- vim.ui_attach is still an unhappy child, reconsider based on plugin experience.
- the flags in ui_events.in.h are still a mess. Can be simplified now.
- UX for remote attachment needs more work.
- startup for client can be simplified further (think of the millisecs we can save)
docs: fix typos (#21427) 2023-01-03T23:38:48+00:00 dundargoc 33953936+dundargoc@users.noreply.github.com 2023-01-03T23:38:48+00:00 936e191fef9865600af211c29ea4959ffbce81dd Co-authored-by: Gustavo Sampaio <gbritosampaio@gmail.com> Co-authored-by: C.D. MacEachern <craig.daniel.maceachern@gmail.com> Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com> Co-authored-by: Tomas Nemec <nemi@skaut.cz> 
Co-authored-by: Gustavo Sampaio <gbritosampaio@gmail.com>
Co-authored-by: C.D. MacEachern <craig.daniel.maceachern@gmail.com>
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
Co-authored-by: Tomas Nemec <nemi@skaut.cz>
 feat!: remove hardcopy 2023-01-03T10:07:43+00:00 Lewis Russell lewis6991@gmail.com 2023-01-03T10:07:43+00:00 5841a97500bffa5a2b9eed2eb41025f5587790ba Co-authored-by: Justin M. Keyes <justinkz@gmail.com> 
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
 fix(tui): more work in the TUI 2022-12-31T12:25:26+00:00 bfredl bjorn.linse@gmail.com 2022-05-02T19:10:01+00:00 43e8ec92de9e0850e7d202cb7ff9051bc408447e 






feat(tui): run TUI as external process
2022-12-31T09:43:28+00:00

hlpr98
hlpr98@gmail.com

2019-05-27T16:34:24+00:00

24488169564c39a506c235bf6a33b8e23a8cb528












refactor: move ex_retab() to indent.c
2022-11-30T02:12:28+00:00

zeertzjq
zeertzjq@outlook.com

2022-11-30T02:12:09+00:00

e0c7b8955d0193ebbc7df703179ecb035f73fec7












vim-patch:8.1.2001: some source files are too big (#21231)
2022-11-29T08:47:29+00:00

zeertzjq
zeertzjq@outlook.com

2022-11-29T08:47:29+00:00

0b79137c59fbe44bded76f123602e552dc6f7b03

Problem:    Some source files are too big.
Solution:   Move buffer and window related functions to evalbuffer.c and
            evalwindow.c. (Yegappan Lakshmanan, closes vim/vim#4898)

https://github.com/vim/vim/commit/261f346f8154c0ec7094a4a211c653c74e9f7c2e




Problem:    Some source files are too big.
Solution:   Move buffer and window related functions to evalbuffer.c and
            evalwindow.c. (Yegappan Lakshmanan, closes vim/vim#4898)

https://github.com/vim/vim/commit/261f346f8154c0ec7094a4a211c653c74e9f7c2e






build: allow IWYU to fix includes for all .c files
2022-11-15T09:30:03+00:00

dundargoc
gocdundar@gmail.com

2022-09-11T15:12:44+00:00

66360675cf4d091b7460e4a8e1435c13216c1929

Allow Include What You Use to remove unnecessary includes and only
include what is necessary. This helps with reducing compilation times
and makes it easier to visualise which dependencies are actually
required.

Work on https://github.com/neovim/neovim/issues/549, but doesn't close
it since this only works fully for .c files and not headers.





Allow Include What You Use to remove unnecessary includes and only
include what is necessary. This helps with reducing compilation times
and makes it easier to visualise which dependencies are actually
required.

Work on https://github.com/neovim/neovim/issues/549, but doesn't close
it since this only works fully for .c files and not headers.







feat(lua-api): avoid unnecessary allocations (#19877)
2022-11-14T18:04:36+00:00

Lewis Russell
lewis6991@gmail.com

2022-11-14T18:04:36+00:00

f8c671827710c6e9cca3bfd60c32098b2be8239a

Lua makes (or reuses) an internal copy of strings, so we can safely push
buf pointers onto the stack.




Lua makes (or reuses) an internal copy of strings, so we can safely push
buf pointers onto the stack.