ci: go back to stricter checks

[maelle]

Fix #1006

Now I understand why everything was green on CI!

[aviator-app]

Current Aviator status

Aviator will automatically update this comment as the status of the PR changes.
Comment /aviator refresh to force Aviator to re-examine your PR (or learn about other /aviator commands).

This PR was merged using Aviator.

---

See the real-time status of this PR on the Aviator webapp.

Use the Aviator Chrome Extension to see the status of your PR within GitHub.

[krlmlr]

What's there for me to review? Should we fix first?

[maelle]

I think it'd make sense to merge then rebase all PRs that work towards getting the build green again?

[aviator-app]

This pull request failed to merge: some CI status(es) failed. Remove the blocked label to re-queue.

Failed CI(s): Check ubuntu-20.04 (devel), Check ubuntu-20.04 (oldrel-2)

[aviator-app]

This pull request failed to merge: some CI status(es) failed. Remove the blocked label to re-queue.

Failed CI(s): Check ubuntu-20.04 (oldrel-2)

[aviator-app]

This pull request failed to merge: some CI status(es) failed. Remove the blocked label to re-queue.

Failed CI(s): Check windows-latest (release), Check ubuntu-20.04 (oldrel-3), Check ubuntu-20.04 (release), Check macOS-latest (release), Check ubuntu-20.04 (oldrel-1), Check ubuntu-20.04 (devel), Check ubuntu-20.04 (oldrel-2)

[krlmlr]

Thanks! Should be good now.

[aviator-app]

This pull request failed to merge: some CI status(es) failed. Remove the blocked label to re-queue.

Failed CI(s): Check macOS-latest (release)

[krlmlr]

@Antonov548: We now have compilation warnings on a few platforms only, e.g., on macOS:

  rinterface.c:6349:84: warning: variable 'c_outfile' is uninitialized when used here [-Wuninitialized]
  rinterface.c:8381:58: warning: variable 'c_instream' is uninitialized when used here [-Wuninitialized]
  rinterface.c:8441:59: warning: variable 'c_outstream' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10886:33: warning: variable 'c_a' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10886:38: warning: variable 'c_b' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10886:43: warning: variable 'c_eps' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10910:31: warning: variable 'c_a' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10910:36: warning: variable 'c_b' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10910:41: warning: variable 'c_eps' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10917:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11610:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11632:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11646:28: warning: variable 'c_igraph_errno' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11653:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11761:31: warning: variable 'version_string' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11762:31: warning: variable 'major' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11763:31: warning: variable 'minor' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11764:31: warning: variable 'subminor' is uninitialized when used here [-Wuninitialized]

Is this dead code? We can remove in rinterface.c and reconcile later, we have drift anyway.

There are more failures on Windows.

Can you please push to this branch?

[Antonov548]

@Antonov548: We now have compilation warnings on a few platforms only, e.g., on macOS:

  rinterface.c:6349:84: warning: variable 'c_outfile' is uninitialized when used here [-Wuninitialized]
  rinterface.c:8381:58: warning: variable 'c_instream' is uninitialized when used here [-Wuninitialized]
  rinterface.c:8441:59: warning: variable 'c_outstream' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10886:33: warning: variable 'c_a' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10886:38: warning: variable 'c_b' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10886:43: warning: variable 'c_eps' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10910:31: warning: variable 'c_a' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10910:36: warning: variable 'c_b' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10910:41: warning: variable 'c_eps' is uninitialized when used here [-Wuninitialized]
  rinterface.c:10917:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11610:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11632:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11646:28: warning: variable 'c_igraph_errno' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11653:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11761:31: warning: variable 'version_string' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11762:31: warning: variable 'major' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11763:31: warning: variable 'minor' is uninitialized when used here [-Wuninitialized]
  rinterface.c:11764:31: warning: variable 'subminor' is uninitialized when used here [-Wuninitialized]

Is this dead code? We can remove in rinterface.c and reconcile later, we have drift anyway.

There are more failures on Windows.

Can you please push to this branch?

Would we like to keep synchronized generated code with functions.yml?

[krlmlr]

We reconcile at some point, yes, but for now, drift is fine. I want to move to autogenerating everything, any Stimulus changes might have to be reverted anyway. We can edit interface.c and aaa-auto.R directly until after the release. Michael Antonov ***@***.***> schrieb am Fr. 12. Jan. 2024 um 16:06:

…

@Antonov548 <https://github.com/Antonov548>: We now have compilation warnings on a few platforms only, e.g., on macOS: rinterface.c:6349:84: warning: variable 'c_outfile' is uninitialized when used here [-Wuninitialized] rinterface.c:8381:58: warning: variable 'c_instream' is uninitialized when used here [-Wuninitialized] rinterface.c:8441:59: warning: variable 'c_outstream' is uninitialized when used here [-Wuninitialized] rinterface.c:10886:33: warning: variable 'c_a' is uninitialized when used here [-Wuninitialized] rinterface.c:10886:38: warning: variable 'c_b' is uninitialized when used here [-Wuninitialized] rinterface.c:10886:43: warning: variable 'c_eps' is uninitialized when used here [-Wuninitialized] rinterface.c:10910:31: warning: variable 'c_a' is uninitialized when used here [-Wuninitialized] rinterface.c:10910:36: warning: variable 'c_b' is uninitialized when used here [-Wuninitialized] rinterface.c:10910:41: warning: variable 'c_eps' is uninitialized when used here [-Wuninitialized] rinterface.c:10917:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized] rinterface.c:11610:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized] rinterface.c:11632:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized] rinterface.c:11646:28: warning: variable 'c_igraph_errno' is uninitialized when used here [-Wuninitialized] rinterface.c:11653:10: warning: variable 'r_result' is uninitialized when used here [-Wuninitialized] rinterface.c:11761:31: warning: variable 'version_string' is uninitialized when used here [-Wuninitialized] rinterface.c:11762:31: warning: variable 'major' is uninitialized when used here [-Wuninitialized] rinterface.c:11763:31: warning: variable 'minor' is uninitialized when used here [-Wuninitialized] rinterface.c:11764:31: warning: variable 'subminor' is uninitialized when used here [-Wuninitialized] Is this dead code? We can remove in rinterface.c and reconcile later, we have drift anyway. There are more failures on Windows. Can you please push to this branch? Would we like to keep synchronized generated code with functions.yml? — Reply to this email directly, view it on GitHub <#1012 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANJGSZPRLZECFYX2IUTSB3YOFGQJAVCNFSM6AAAAABAZLGH5KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBZGQ2TQNBXHE> . You are receiving this because your review was requested.Message ID: ***@***.***>

[szhorvat]

Beware that most of these "uninitialized when used here" warning indicate actual bugs! If the affected function is used, that's a problem we need to fix now. Hopefully none of them are used?

[krlmlr]

Now there's only Windows and macOS failing, for good reason, I think.

[Antonov548]

Now there's only Windows and macOS failing, for good reason, I think.

Yes, checking

[szhorvat]

@Antonov548 Why did you make this change? %d is only for int, and the return type of Rf_xlength() is system-dependent (may not be compatible with int!), but always fits in size_t. I chose %zu and a cast to size_t on purpose.

[Antonov548]

zu is not compatible with some versions of compiler. Maybe good solution will be to use lu?

[szhorvat]

What specific compiler is it not compatible with?

[szhorvat]

zu is standard in both C99 and C++11. Could it be that the proper standard is not set? I'd be very surprised to see any still-relevant compiler not support it.

[szhorvat]

According to tests wit Godbolt, works with Clang 3.4 and GCC 4.8. igraph itself wouldn't support anything earlier.

[Antonov548]

@szhorvat https://stackoverflow.com/questions/68900199/how-to-get-mingw-gcc-to-recognize-the-zu-format-specifier-for-size-t

Hm, looks like there still no agreement for zu.

[szhorvat]

What that SO answer is saying is that it does actually work but MinGW's GCC incorrectly warns about it. That is very disappointing.

You should be aware that on Windows the long type is 32-bit wide. Using long here is actually wrong. Can't we just use -Wno-format specifically on Windows?

[szhorvat]

@Antonov548 Can you try to use PRIuPTR instead? Here is an example:

https://godbolt.org/z/jcWrvWo9b

PRIuPTR should be defined to a string that is the appropriate format specifier for uintptr_t (which should fit size_t). I'm curious to see what this is with MinGW.

[Antonov548]

Seems uintptr_t works well. Let's see in ci.
I guess it's better to leave all warning enabled.

[szhorvat]

Yes, it's better to leave warnings enabled on all platforms.

Someone just told me about the __USE_MINGW_ANSI_STDIO macro. Defining this to either 1 or 0 may help (unclear).

But if PRIuPTR works, let's just stick to that, as it is standard.

[maelle]

@Antonov548 thanks! What are the windows and sanitizer failures?

[maelle]

I see #1110

[Antonov548]

@Antonov548 thanks! What are the windows and sanitizer failures?

On windows there is warning in vendor folder, precise in core igraph. Not sure why the are not ignored. I though that vendor folder is ignored.

[maelle]

True, ^vendor$ is listed in .Rbuildignore so they should be ignored 🤔

[szhorvat]

@Antonov548 As a general rule, never use long in igraph code. long has an unpredictable width, and will cause trouble on Windows (where it is 32-bit).