LSP function hints are mixed up for zlib

[jamespeapen]

Observed behavior

The zlib function descriptions seem to be mixed up. This is only for zlib as far as I can tell. Other functions from std and Rcpp are showing their correct descriptions. I am showing two examples here.

This is the official description for zlib's gzgets (https://www.zlib.net/manual.html#Gzip):

Read and decompress bytes from file into buf, until len-1 characters are read, or until a newline character is read
and transferred to buf, or an end-of-file condition is encountered. If any characters are read or if len is one, the 
string is terminated with a null character. If no characters are read due to an end-of-file or len is less than one,
then the buffer is left untouched. 

which is what I get from ccls when I type gzputc:

Here is gzputs from https://nixdoc.net/man-pages/OpenBSD/man3/gzputc.3.html:

The gzputs() function writes the given null-terminated string to the compressed file, excluding the terminating null
character.

but I get that hint when I type gzgets:

My .ccls config:

clang
%c -std=c11
%cpp -std=c++2a
-I/home/james.eapen/.R/Rcpp/include
-I/home/james.eapen/.R/RcppArmadillo/include
-I/usr/share/R/include

Minimal reprex:

Any zlib function can be used in main.

#include <zlib.h>

int main(int argc, char *argv[])
{
    return 0;
}

Expected behavior

LSP hints are the correct ones for zlib functions.

Steps to reproduce

1. Copy the minimal example.
2. Type zlib functions like gzgets or gzputc and trigger the LSP completion.

System information

• ccls version:

Ubuntu ccls version 0.20210330-1
clang version 12.0.1-19ubuntu3

• clang version:

Ubuntu clang version 14.0.0-1ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

• OS: Ubuntu 22.04.1 LTS
• Editor: Neovim v0.8.0-1210-gd367ed9b2
• Language client (and version): Neovim LSP with nvim-lspconfig (5f4b1fa83c80f43e434c1fb227967dac9ad8f44c)

[MosakujiHokuto]

https://github.com/madler/zlib/blob/master/zlib.h#L1491

zlib seems to be putting descriptions below function declarations, which seems to be an unusual practice to me (AFAIK most library put those descriptions above declarations).

I don't think this should be fix on ccls side...

[MaskRay]

madler/zlib is known to have these problems (https://github.com/madler/zlib/issues/633). I agree that modern utilities should not follow its convention...