docs/sourcetree: update CLion set up instructions (#2454)

After #2325 the old method no longer works as our Makefile does not print compilation commands when run with --dry-run, see https://github.com/neondatabase/neon/issues/2378#issuecomment-1241421325

This method is much slower but is hopefully robust.

Add some more notes while we're here.

docs/sourcetree.md

@@ -147,8 +147,16 @@ C code requires some extra care, as it's built via Make, not CMake. Some of our
    ```bash
    # Install a `compiledb` tool which can parse make's output and generate the compilation database.
    poetry add -D compiledb
-   # Run Make without actually compiling code so we can generate the compilation database. It still may take a few minutes.
-   make --dry-run --print-directory --keep-going --assume-new=* postgres neon-pg-ext | poetry run compiledb --verbose --no-build
+   # Clean the build tree so we can rebuild from scratch.
+   # Unfortunately, our and Postgres Makefiles do not work well with either --dry-run or --assume-new,
+   # so we don't know a way to generate the compilation database without recompiling everything,
+   # see https://github.com/neondatabase/neon/issues/2378#issuecomment-1241421325
+   make distclean
+   # Rebuild the Postgres parts from scratch and save the compilation commands to the compilation database.
+   # You can alter the -j parameter to your liking.
+   # Note that we only build for a specific version of Postgres. The extension code is shared, but headers are
+   # different, so we set up CLion to only use a specific version of the headers.
+   make -j$(nproc) --print-directory postgres-v15 neon-pg-ext-v15 | poetry run compiledb --verbose --no-build
    # Uninstall the tool
    poetry remove -D compiledb
    # Make sure the compile_commands.json file is not committed.
@@ -157,7 +165,8 @@ C code requires some extra care, as it's built via Make, not CMake. Some of our
 3. Open CLion, click "Open File or Project" and choose the generated `compile_commands.json` file to be opened "as a project". You cannot add a compilation database into an existing CLion project, you have to create a new one. _Do not_ open the directory as a project, open the file.
 4. The newly created project should start indexing Postgres source code in C, as well as the C standard library. You may have to [configure the C compiler for the compilation database](https://www.jetbrains.com/help/clion/compilation-database.html#compdb_toolchain).
 5. Open the `Cargo.toml` file in an editor in the same project. CLion should pick up the hint and start indexing Rust code.
-7. Now you have a CLion project which knows about C files, Rust files. It should pick up Python files automatically as well.
+6. Now you have a CLion project which knows about C files, Rust files. It should pick up Python files automatically as well.
+7. Set up correct code indentation in CLion's settings: Editor > Code Style > C/C++, choose the "Project" scheme on the top, and tick the "Use tab character" on the "Tabs and Indents" tab. Ensure that "Tab size" is 4.
 
 You can also enable Cargo Clippy diagnostics and enable Rustfmt instead of built-in code formatter.
 
@@ -168,3 +177,4 @@ Known issues (fixes and suggestions are welcome):
 * Test results may be hard to read in CLion, both for unit tests in Rust and integration tests in Python. Use command line to run them instead.
 * CLion does not support non-local Python interpreters, unlike PyCharm. E.g. if you use WSL, CLion does not see `poetry` and installed dependencies. Python support is limited.
 * Cargo Clippy diagnostics in CLion may take a lot of resources.
+* `poetry add -D` updates some packages and changes `poetry.lock` drastically even when followed by `poetry remove -D`. Feel free to `git checkout poetry.lock` and `./scripts/pysync` to revert these changes.