[libc] Clean up unnecessary function pointers in scanf

[michaelrj-google]

The scanf reader is the abstraction that scanf uses to read from either a file or a string, similar to printf's writer. Unlike printf, however, there are only two variants of scanf: fscanf and sscanf (just scanf is the same as fscanf(stdin, ...)). This means that the stream_getc and stream_ungetc functions don't need to be pointers, they can be declared with using statements based on the current platform.

Files you'll need to edit:
libc/src/stdio/scanf_core/vfscanf_internal.h
libc/src/stdio/scanf_core/reader.h

What to do:
Move the definitions of getc and ungetc in vfscanf_internal into reader.h (along with the associated #if defined logic for each target).
Define the stream_getc and stream_ungetc functions with using statements inside of class Reader (or do something equivalent).
Clean up the relevant code.

If you have questions or need help, feel free to comment on this issue or reach out via the LLVM discord.

[llvmbot]

@llvm/issue-subscribers-libc

Author: Michael Jones (michaelrj-google)

The scanf reader is the abstraction that scanf uses to read from either a file or a string, similar to printf's writer. Unlike printf, however, there are only two variants of scanf: `fscanf` and `sscanf` (just `scanf` is the same as `fscanf(stdin, ...)`). This means that the `stream_getc` and `stream_ungetc` functions don't need to be pointers, they can be declared with `using` statements based on the current platform.

Files you'll need to edit:
libc/src/stdio/scanf_core/vfscanf_internal.h
libc/src/stdio/scanf_core/reader.h

What to do:
Move the definitions of getc and ungetc in vfscanf_internal into reader.h (along with the associated #if defined logic for each target).
Define the stream_getc and stream_ungetc functions with using statements inside of class Reader (or do something equivalent).
Clean up the relevant code.

If you have questions or need help, feel free to comment on this issue or reach out via the LLVM discord.

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: Michael Jones (michaelrj-google)

The scanf reader is the abstraction that scanf uses to read from either a file or a string, similar to printf's writer. Unlike printf, however, there are only two variants of scanf: `fscanf` and `sscanf` (just `scanf` is the same as `fscanf(stdin, ...)`). This means that the `stream_getc` and `stream_ungetc` functions don't need to be pointers, they can be declared with `using` statements based on the current platform.

Files you'll need to edit:
libc/src/stdio/scanf_core/vfscanf_internal.h
libc/src/stdio/scanf_core/reader.h

What to do:
Move the definitions of getc and ungetc in vfscanf_internal into reader.h (along with the associated #if defined logic for each target).
Define the stream_getc and stream_ungetc functions with using statements inside of class Reader (or do something equivalent).
Clean up the relevant code.

If you have questions or need help, feel free to comment on this issue or reach out via the LLVM discord.

[shawbyoung]

Could I be assigned this? @michaelrj-google

[AidanGoldfarb]

@shawbyoung are you still working on this issue? If not I would be happy to take over

[shawbyoung]

@AidanGoldfarb Yes, I was busy but now am carving out some time to put out a PR in the next few days.

[vinay-deshmukh]

@shawbyoung are you still working on this issue?

[vinay-deshmukh]

Haven't received a ping back in a week, so I've created a PR #121215

For now, build fails for me on macos/m1, but had worked once. I'm guessing based on which commit I forked, it subtly broke it later on?

[vinay-deshmukh]

@michaelrj-google

Is it currently possible to build llvm-libc in overlay mode on macos/m1?

My code (in the linked PR) is failing on 2 issues right now:

1. Mutex is not recognized as a type,

   llvm-project/libc/src/__support/File/file.h

   Line 90 in 3496e96

   Mutex mutex;

2. Macro substitutions that happen for: clearerr_unlocked, which is a macro in macos' stdio.h, but defined as a method name in

   llvm-project/libc/src/__support/File/file.h

   Line 260 in 3496e96

   void clearerr_unlocked() { err = false; }

both errors happen in the CI as well: #121215 (comment)

Would appreciate any guidance on solving the above issues as well.

[michaelrj-google]

The MacOS build is working for me right now. Here's my build process:

1. Delete CMakeCache.txt (MacOS likes to move around paths to headers after updates)
2. Run my cmake command: cmake ../runtimes -G Ninja -DLLVM_ENABLE_RUNTIMES="libc"
3. Run the tests: ninja check-libc

This works on my M1 Mac as of f9369cc