You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+19-6Lines changed: 19 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,14 +19,20 @@ will not be reflected, unless you use `Revise`.
19
19
20
20
## For all changes
21
21
22
-
1. Run `make check-whitespace` before creating the PR to make sure you're not committing any whitespace errors.
22
+
1. Run `make fix-whitespace` before creating the PR to make sure you're not committing any whitespace errors.
23
23
24
24
## Building Julia
25
25
26
26
If you made changes to the runtime (any files in `src/`), you will need to rebuild
27
27
julia. Run `make -j` to rebuild julia. This process may take up to 10 minutes
28
28
depending on your changes.
29
29
30
+
After making changes, run static analysis checks:
31
+
- First run `make -C src install-analysis-deps` to initialize dependencies (only needed once the first time).
32
+
- Run `make -C src analyze-<filename> --output-sync -j8` (replace `<filename>` with the basename of any C or C++ file you modified, excluding headers).
33
+
- Tests can also be rerun individually with `clang-sa-<filename>`, `clang-sagc-<filename>` or `clang-tidy-<filename>`.
34
+
- If `clang-sagc-<filename>` fails, it may require adding `JL_GC_PUSH` statements, or `JL_GC_PROMISE_ROOTED` statements., or require fixing locks. Remember arguments are assumed rooted, so check the callers to make sure that is handled. If the value is being temporarily moved around in a struct or arraylist, `JL_GC_PROMISE_ROOTED(struct->field)` may be needed as a statement (it return void) immediately after reloading the struct before any use of struct. Put that promise as early in the code as is legal, near the definition not the use.
35
+
30
36
## Using Revise
31
37
32
38
If you have made changes to files included in the system image (base/ or stdlib/),
@@ -76,6 +82,13 @@ When modifying external dependencies (patches in `deps/patches/` or version upda
76
82
- Prefer using the full upstream commit in `git am` format (e.g., `git format-patch`) which includes proper commit metadata
77
83
3. When updating dependency versions, ensure all associated patches still apply
78
84
85
+
### External JLLs
86
+
87
+
To update a JLL to the latest version:
88
+
- Update the version number in the appropriate jll folder
89
+
- If the dependencies in the upstream jll changed, update the Project.toml
90
+
- Run `make -f contrib/refresh_checksums.mk <jll>` to update the checksums. This may take a few minutes.
91
+
79
92
### Writing code
80
93
After writing code, look up the docstring for each function you used. If there
81
94
are recommendations or additional considerations that apply to these functions,
@@ -85,7 +98,7 @@ make sure to take them into account.
85
98
- Do not `ccall` runtime C functions directly if there are existing wrappers for the function.
86
99
- Do not explicitly add a module prefix if the code you're adding is in the same module. E.g. do not use `Base.` for code in Base unless required.
87
100
88
-
## Commit message formatting
101
+
## Commit messages and pull requests
89
102
90
103
When writing commit messages, follow the format "component: Brief summary" for
91
104
the title. In the body of the commit message, provide a brief prose summary
@@ -97,7 +110,7 @@ If your change fixes one or more issues, use the syntax "Fixes #" at the end of
97
110
When referencing external GitHub PRs or issues, use proper GitHub interlinking format (e.g., `owner/repo#123` for PRs/issues).
98
111
When fixing CI failures, include the link to the specific CI failure in the commit message.
99
112
100
-
When creating pull requests, if the pull request consists of one commit only,
101
-
use the body of the commit for the body of the pull request. If there are multiple
102
-
commits in the pull request, follow the same guidelines for the pull request
103
-
as for the commit body.
113
+
When creating pull requests:
114
+
1. If the pull request consists of one commit only, use the body of the commit for the body of the pull request.
115
+
2. If there are multiple commits in the pull request, follow the same guidelines for the pull request as for the commit body.
116
+
3. Make sure that the base commit of the pull request is recent (within the past two days) - if not rebase your changes first.
0 commit comments