For this project, as suggested by @Adrian_Prantl, I intend to post a weekly progress report every Monday, summarizing what I've done in the last week, and what I intend to do on the current one. I believe that keeping our communication in the open will be useful in involving the community in the project, keeping myself accountable, and hopefully as a reference for future GSOC students.
This first week, I worked in getting to know LLDB better by:
Getting all enabled LLDB tests to run (and pass) on my machine.
Exploring LLDB's API through python scripting.
Overall I think my progress in the first week was alright, but not great. My main problem was that I didn't have a clear goal. Because of that, I bounced around a lot between different resources, and I couldn't measure how much I actually got done.
@Adrian_Prantl and @vedantk, I'd like to ask you guys if for this week you could give me a specific task that would help me understand LLDB better. Maybe an issue that is related to my project? Or any other task where I can measure my progress more easily. I think I'll learn more by having a clear objective of what I should do.
For now, my plans for the week are to continue exploring LLDB's API through python scripting, but, of course, these plans are open to change after your suggestions.
Hey @augusto2112, it was great to meet you last week.
Adrian and I believe you're off to a strong start. So far, you've gotten familiar with LLDB's architecture, and you've gotten your build and test environment sorted out. That's no small thing!
For the next week, we'd like to propose two concrete deliverables. The first is a hard deliverable, which we expect you to tackle this week. The second is soft: it may need to be broken up into sub-tasks (at your discretion) and tackled over multiple weeks. If the format works out we'll repeat this next week.
Fix [SR-12449] Linux - `swift` prints wrong version · Issue #54888 · apple/swift · GitHub. This is an issue where the Swift REPL prints out the wrong version on Linux. This is a chance for you to solidify your familiarity with lldb's testing harness and engage more on the Swift bug tracker. This is the hard deliverable: we expect you'll be able to tackle this in a week.
Add a swift reflection test for Linux. For example, consider starting with swift/validation-test/Reflection/reflect_UInt16.swift. Note the REQUIRES: objc_interop lit directive, which, according to test/lit.cfg is only ever defined on Apple/Darwin platforms. Does the test pass on Linux when you remove this requirement? This is the soft deliverable: it's more directly related to your project, but it's also more challenging and may need to be split up into smaller tasks. As you dive into this we encourage you to file SRs on the bug tracker to track those sub-tasks. For example, if you determine that it's necessary to add more tests for type metadata parsing on ELF, it's good practice to file an SR for that and relate it to a "parent" or "umbrella" SR that tracks Remote Mirrors work for ELF.
Good luck this week, and don't hesitate to reach out!
Hey @augusto2112, it looks like SR-12449 was a breeze, but that we're still discussing the next steps for enabling the reflection tests. If you have spare cycles, please consider these background tasks:
Scanning bugs.swift.org for interesting issues (e.g. maybe this one?). This could be a good way to get experience with handling user reports.
Investigating swift-lldb tests which are disabled on Linux to figure out why they are disabled, and how they can be fixed.
The conversation in that thread was going way over my head, so I'm also taking the time to study how Elf and Mach-O work and differ, so I can follow along with the discussion better.
Hi everyone! @vedantk, @Adrian_Prantl I decided to keep my progress reports in a single thread, so I don't clutter the page with a bunch of posts. Let me know if you'd prefer one thread per week instead.
The last week I worked on:
Issue SR-12449: a simple test revealed that the issue was already solved, so we closed it as "Done".
Issue SR-12397: I started investigating SR-12397. Haven't made much progress in this front yet either, but more because of a lack of time (as opposed to being stuck).
ELF: read a bit about ELF and how it compares to Mach-O. In case someone is curious, I read this, this, this and this.
For this week, I plan on working on issue SR-12397, and if I have any time remaining, I'll start poking around the swift-lldb tests which are disabled on Linux. If we manage to come up with a plan for the next steps on how to make SwiftReflectionTest work, I believe I should make that my top priority instead, as it's closely related to my project.
The last week I basically only worked on issue SR-12397. Some actual progress has been this week, mainly because of the help of my mentors (next time I'll ask for help sooner!). It turned out to be quite a complex issue (for me at least), however, I've learned a ton about how expressions are evaluated in LLDB and had a lot of fun working on it.
For this week the plan stays the same as last week: working on issue SR-12397, and if I have any time remaining, playing with swift-lldb tests which are disabled on Linux.
The last week I basically only worked on SR-12397. I feel like I'm very close now. I got something that generates the expected comparison expression, but fails to evaluate.
GSOC's first coding period starts officially starts today! Tomorrow I'm having a meeting with my mentors in order to align the next steps, but the plan is to start working on how to add reflection tests on Linux.
Last week I opened a PR to fix issue SR-12397, it's still not ready yet, and this issue has taken a back-seat since it's not critical for my GSOC project. I also re-started working to enable SwiftReflectionTest on Linux. My mentors and I decided to add entry points in the run-time that provides the necessary reflection metadata information (in debug mode). I'm having a little bit of trouble finding out where some of this information should come from (for example, the equivalent of _dyld_get_image_name).
This week, I'll continue to work on enabling SwiftReflectionTest.
Last week I worked 100% of the time on SwiftReflectionTest. Quite a lot of progress was made! Right now, 24 of the tests under validation-test/Reflection are passing (with 11 failures and 12 unsupported due to lack of Objective-C interop). I've opened a PR for this issue here, and a second one expanding the documentation of class metadata when there's no Objective-C interop here. I believe that the 11 remaining tests are all failing because of the same reason, which is good, since if we solve one of them, we can solve all of them. I created a new thread to discuss the current failure here.
This week I'll continue working on SwiftReflectionTest. I'm fairly confident we'll be able to finish it this week. If I have any remaining time, I'll go back to SR-12397, unless my mentors and I decide on some other higher-priority task.
Unfortunately, I wasn't able to enable SwiftReflectionTest quite yet. I had to take a step back and make some changes so it becomes easier to be enabled on Windows as well. Right now I have three pull request (one, two, three), which need to be merged so we get at least 1 passing test on Linux. I'm hopeful we'll be able to merge them this week.
This week things went a bit slowly due to WWDC. Today, we merged the first of the three PRs I mentioned last week. The second PR has all tests passing so it should also be ready to go! While I've been waiting for these PRS to be reviewed, I've been trying to figure out why the reflect_Enum_values test produces a different output of what is expected on the test (this is the only non-Foundation, non-ObjC test which does so). This is the what I would have to do next anyway, so this way I don't feel blocked. This week I'll continue working on merging the 2 remaining PRs and on reflect_Enum_values.