Turns out we already implemented the kind PDT as well. Moving fast. But the len PDT is still missing, so that would be a good project.
You can join us at https://lfortran.zulipchat.com/ and we can brainstorm some good ideas. I think the best ones are to simply compile more codes and fix whatever bugs come up. In terms of features I think we support all of Fortran now, except len PDT and coarrays. But we still have bugs, so fixing those is what is needed.
You can also pick some performance project to improve runtime performance. Or improving do concurrent offloading to GPUs.
My name is Ayushi Shivhare, and I am a 2nd year Computer Science student . I am interested in open-source development and currently exploring contributions in the Fortran-Lang ecosystem as part of my preparation for GSoC 2026.
My programming experience includes C++, Python, JavaScript, and React.js. I also work with frontend technologies such as HTML, Bootstrap and Tailwind CSS. I am familiar with Git and GitHub workflows and have started contributing to open-source projects.
Recently I submitted my first contribution to the Fortran-Lang website to fix a UI layout issue on the packages page (search box overlap).
I am currently learning more about Fortran and scientific computing, and I am interested in contributing to projects such as the Fortran website, fpm, and stdlib.
I look forward to learning from the community and would appreciate guidance on beginner-friendly issues where I can contribute further.
Hi! I recently introduced myself and submitted PR #640. I’d love to contribute more to the website or related repositories. If there are any issues or tasks suitable for beginners that I
could help with, I’d be happy to work on them. Thanks for your guidance!
I’ve been investigating issue #478 (Markdown list in argument docstring causes next argument to indent) in the fortls repository.
While debugging the hover documentation generation, I traced the formatting logic to:
fortls/parsers/internal/subroutine.py
fortls/parsers/internal/function.py
In both places the hover documentation is assembled using:
" \n".join(docs)
During testing I noticed that the extra space before the newline may cause Markdown to interpret the next parameter documentation as a continuation of the previous list.
As an experiment, I tried changing it to:
"\n".join(docs)
With this change, the hover output in VS Code appears to match the expected behavior described in the issue—the next parameter documentation is no longer indented under the previous bullet list.
However, when running the test suite, some tests fail due to formatting differences compared to the current expected output (for example test/test_server_documentation.py).
Before committing or opening a PR, I wanted to confirm:
Is modifying the join separator in these functions the correct approach for fixing this issue?
Or should this formatting be handled earlier in the documentation parsing stage?
If this approach seems reasonable, I’d be happy to prepare a PR implementing the fix.
I’m Zainab Travadi, a 3rd year Computer Science student at Parul University, Vadodara, India. I’m interested in contributing to the fpm (Fortran Package Manager) project for GSoC 2026, specifically the Extended Testing Support idea mentored by Sebastian Ehlert and Brad Richardson.
I’ve been exploring the fpm codebase over the past few weeks and have opened a few pull requests to get familiar with the code:
PR #1259 — Fixed LD_LIBRARY_PATH handling for shared libraries during fpm test
PR #1263 — Improved diagnostics when command execution fails silently in run()
PR #1261 — Standardized compilation error message wording in fpm_backend.F90
I’ve also been working on my proposal, focusing on extending the test_config_t structure to support custom arguments, environment variables, runners, and resource files — essentially bringing fpm’s testing configuration closer to what tools like CMake’s CTest offer.
I’d love any feedback from the community or mentors on the implementation direction, particularly around backward compatibility and whether the manifest parsing approach I’m planning aligns with fpm’s existing conventions.
Hello all, the contributor proposals are now open, deadline is March 31, 18:00 UTC. Looking forward to your proposals and thank you so much for showing interest and helping develop community.
My advice would be to spend time on single proposal, polish it and make it the best. That’s what I did. However, lot of people tend to submit multiple proposals. Nothing wrong on either side. I’m not sure on PDT support with LFortran at this moment, there is some work going on. Priority wise, compiling code is always at the highest priority. You can check on LFortran zulip and decide accordingly.
I can mentor it. Submit a good proposal and we’ll select based on merit. We’ll find mentors for good proposals. Make sure you get at least one PR merged before the deadline.
Thanks for the update! I’m working on my proposal for the Extended Testing Support project under fpm and plan to submit before the deadline. Looking forward to any feedback from mentors!
These projects were accidentally listed, porting them from previous GSoCs.
I think that will be challenging for two reasons. I made this project because I envisioned a specific solution but no full specs doc exists.
Secondly, there aren’t any existing contributors to the project familiar with the codebase to supervise you. Your mentor should bring in the planning and expertise, and currently there isn’t an active contributor in vscode-fortran-support that is available to supervise.
Hi everyone, I’m Sudhanshu, 2nd-year undergrad at IIT Dhanbad. I’m focused on the linear algebra and sparse matrices project for GSoC 2026.
I’ve submitted a PR implementing permutation matrix support, Issue #891: PR #1155.It adds permutation_t type with O(n) vector storage,10 operations including dgetrf LAPACK pivot conversion, 12 unit tests, and 221x speedup over dense matmul permutations.
I’m planning to work on the remaining related issues like numeric constants (#910), sparse MKL backend (#934), and some additional scope as well. Would appreciate feedback on the PR and any additional proposal scope suggestions from mentors.
Hi everyone, I’m Raghava, 2nd year undergrad at SAHE University Andhra Pradesh, India and I am interested in contributing to LFortran for GSoC 2026.
I have a strong interest in low level systems and compilers.
I previously worked on building a toy LLVM compiler so I am familiar with parsing,ASTs and LLVM IR.
I am particularly interested in the projects Compile any Fortran code or Implementation of features on the ASR and LLVM level.
But the len PDT is still missing, so that would be a good project.