The patch bumps the Clang version from 16 to 19 in workflows that are intended to use the most modern Clang version. Many things were changed since version 16, see release notes in [1], [2], [3]. The `-Ofast` command-line option has been deprecated in Clang 19, see [3]. It is advised to switch to `-O3 -ffast-math` if the use of non-standard math behavior is intended, and -O3 otherwise. The patch replaces `-Ofast` with `-O3 -ffast-math` to suppress a message below in a build log: NO_WRAP clang-19: warning: argument '-Ofast' is deprecated; use '-O3 -ffast-math' for the same behavior, or '-O3' to enable only conforming optimizations [-Wdeprecated-ofast] NO_WRAP The bump had needed an update of Dockerfile used for building the Docker image used in the aforementioned workflows, see pull request in [4]. 1. https://releases.llvm.org/17.0.1/tools/clang/docs/ReleaseNotes.html 2. https://releases.llvm.org/18.1.6/tools/clang/docs/ReleaseNotes.html 3. https://releases.llvm.org/19.1.0/tools/clang/docs/ReleaseNotes.html 4. https://github.com/tarantool/infra/pull/206 NO_CHANGELOG=build NO_DOC=build NO_TEST=build (cherry picked from commit 11145f6a82b1753e81baf8a439b29962dfef4221)

If opts.identity is NULL and strdup is failed we do NULL pointer dereference when reporting the error. Let's just panic if strdup() failed. While at it replace another strdup() with xstrdup() in this function. Our current approach is to panic on runtime OOM. Closes tarantool/security#128 NO_TEST=issue is not possible after the fix NO_CHANGELOG=not reproducible NO_DOC=bugfix (cherry picked from commit 47b72f44986797466b95b9431a381dbef7dd64fd)

The reason is that the previous libcurl submodule update in commit 0919f390802f146852b462215327ef03e2730cfc ("third_party: update libcurl from 8.8.0 to 8.10.1") reveals the following regression: NOWRAP ```c $ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()" tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed. Aborted (core dumped) ``` NOWRAP The stacktrace is the following: NOWRAP ```c <...> #4 __assert_fail #5 curl_multi_assign // <- called by us #6 curl_multi_sock_cb // <- this is our callback #7 Curl_multi_pollset_ev #8 cpool_update_shutdown_ev #9 cpool_discard_conn #10 cpool_close_and_destroy_all #11 Curl_cpool_destroy #12 curl_multi_cleanup #13 curl_env_finish // <- destroy the multi handle #14 httpc_env_finish #15 luaT_httpc_cleanup #16 lj_BC_FUNCC #17 gc_call_finalizer #18 gc_finalize #19 gc_onestep #20 lj_gc_fullgc #21 lua_gc #22 lj_cf_collectgarbage #23 lj_BC_FUNCC #24 lua_pcall #25 luaT_call #26 lua_main #27 run_script_f #28 fiber_cxx_invoke #29 fiber_loop #30 coro_init ``` NOWRAP The multi handle is during the destroy, but our `CURLMOPT_SOCKETFUNCTION` callback is invoked and the `curl_multi_assign()` call (invoked to associate a libev watcher to the given file descriptor) fails on the assertion. Everything is as described in https://github.com/curl/curl/issues/15201. The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit updates libcurl to this revision to fix the regression. Adjusted build options in our build script: * Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3] * Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4] * Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`: [curl-8_10_1-130-gd78e129d5][5] [1]: https://github.com/curl/curl/commit/48f61e781a01e6a8dbc4a347e280644b1c68ab6a [2]: https://github.com/curl/curl/commit/461ce6c6160b86439ddd74c59541231ec9e8558e [3]: https://github.com/curl/curl/commit/ce7d0d41378007eda676c83ad6b86c59870cc9f1 [4]: https://github.com/curl/curl/commit/71cf0d1fca9e1f53524e1545ef0c08d174458d80 [5]: https://github.com/curl/curl/commit/d78e129d50b2d190f1c1bde2ad1f62f02f152db0 NO_DOC=bugfix NO_CHANGELOG=fixes an unreleased commit NO_TEST=can't reproduce without https to add a test case, verified locally (cherry picked from commit fbe6d0a0a40945c42609f5119a007b5c3980c232)

The type cast is unnecessary and causes false-positive errors: NO_WRAP ``` ./src/box/field_map.c:110:10: runtime error: store to misaligned address 0x507000071082 for type 'uint32_t *' (aka 'unsigned int *'), which requires 4 byte alignment 0x507000071082: note: pointer points here 01 00 00 00 be be be be f0 ff ff ff 02 00 00 00 be be be be be be be be 00 00 00 00 00 00 00 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ./src/box/field_map.c:110:10 ``` NO_WRAP Closes #10631 NO_DOC=bugfix NO_CHANGELOG=minor NO_TEST=tested by debug_asan_clang workflow (cherry picked from commit 5ddbd85cc377a29dc27d01ad06acdc6acc24cc5b)

New commits: * mempool: fix UBSan errors regarding misaligned stores NO_DOC=submodule bump NO_TEST=submodule bump NO_CHANGELOG=submodule bump (cherry picked from commit 9dd56f49be85dc8a1fe874629711a828835f740c)

All structures with a non-default alignment (set by `alignas()`) must be allocated by `aligned_alloc()`, otherwise an access to such a structure member fill crash, e.g. if compiled with AVX-512 support. Closes #10215 Part of #10631 NO_DOC=bugfix NO_TEST=tested by debug_asan_clang workflow NO_CHANGELOG=fix is actually not user-visible, because tarantool still doesn't work with enabled AVX-512 (#10671) (cherry picked from commit a60ec82d4f07720148b0724e5feff31f76291b56)

This reverts commit 3c25c667352ec4f9c733c514a1b8c15264c6ad88. `aligned_alloc()` is supported by macOS since 10.15. I believe that we do not support older versions now. NO_DOC=internal NO_TEST=internal NO_CHANGELOG=internal (cherry picked from commit 2f4594f748cff99d15f8f6d603797a308793de86)

It doesn't work since 2023-11-18. The uploading succeeds, but the website says: > The Coverity Build tool version is no longer supported. Please > download the latest version for your platform from > https://scan.coverity.com/download... It seems, some specific toolset is installed in the `tarantool/testing:debian-buster` image and it was deprecated 11 months ago. Recently the CI workflow starts to fail due to use of the old image with an old CMake in it: > [ 2%] Performing configure step for 'bundled-nanoarrow-project' > -- Building using CMake version: 3.13.4 > -- Configuring incomplete, errors occurred! > CMake Error at CMakeLists.txt:19 (cmake_minimum_required): > CMake 3.14 or higher is required. You are running version 3.13.4 It is likely due to commit 49c160c28c97 ("third_party: initial import of nanoarrow"). Here I refine the workflow file: * Get rid of the custom docker image with preinstalled Coverity toolset. * Use a nice unofficial-coverity-scan GitHub Action ([1]). * Add the `libreadline-dev` dependency installation, because it is needed to build tarantool on Ubuntu 24.04. * Drop related `.test.mk` rules, because it looks more readable to invoke a few commands from the workflow file directly. * Drop testing artifacts uploading that seems a copy-paste from some workflow that runs the tests and the given directory unlikely has any file in our case. * Drop unused step that adds a comment to the pull request. And things seems to start working. At least, after a testing run of the workflow now I see the following status on the website: > Last Build Status: Running. Your build is currently being analyzed [1]: https://github.com/marketplace/actions/unofficial-coverity-scan See also #10651. NO_DOC=developer tools NO_CHANGELOG=see NO_DOC NO_TEST=see NO_DOC (cherry picked from commit f5daacfac84fbea3bb67991fa71ea4e789184ec8)

The recent libcurl update in commit 0919f390802f ("third_party: update libcurl from 8.8.0 to 8.10.1") reveals an old problem in our libcurl's build script: it attempts to disable the libidn2 dependency using the `-DHAVE_LIBIDN2=OFF` option instead of `-DUSE_LIBIDN2=OFF`. It doesn't work after a recent curl building machinery change, see https://github.com/curl/curl/pull/14555 This commit fixes the problem by using `-DUSE_LIBIDN2=OFF`. Reported in #10621 NO_DOC=build mechanics fixup NO_CHANGELOG=fixes a non-released commit NO_TEST=verified locally, seems to need an extra work on a separate CI workflow with a particular building environment; no time for that tonight, sorry (cherry picked from commit a4b4158f2196442308aba7df8f8e21b98b5319fc)

The testsuite "Datetime string parsing by format (detailed)" tests parsing of a string with various conversion specifications. However, `tostring(dt)` is used as a test oracle, and all these testcases do not test some conversion specifications at all because the metamethod `__tostring` for the datetime object uses `:format()` with the default format string. Due to missed tests for conversion specifications, the behavior described in #10470 was missed: ``` tarantool> dt = date.parse('Mon', {format = '%a'}) tarantool> dt --- - 1970-01-01T00:00:00Z ... tarantool> dt:format('%a') --- - Thu ... ``` The patch adds tests for `strptime` with all possible conversion specifications described in strftime(3) [1][2]. 1. https://man.freebsd.org/cgi/man.cgi?strftime(3) 2. https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html Follows up #8588 Follows up #6731 Relates to #10470 NO_CHANGELOG=testing NO_DOC=testing (cherry picked from commit 109b18df4da0b34f4408f67902e0db04540cb32b)