Integrate StaticLint and SymbolServer - #61
Conversation
git-subtree-dir: packages/JSONRPC git-subtree-split: 9e022c861a42677062dd015872aa16e4d45526d1
git-subtree-dir: packages/JSON git-subtree-split: 4b3913d58f04cc5bb2f8d23c6ef82e0fbed20525
…CancellationTokens'
git-subtree-dir: packages/CancellationTokens git-subtree-split: 9130370b57161b38d5a8b2bb0f947f60d7adc988
…s, and make other CI tweaks (#104) * Run CI on Julia 1.12 and 1.13-nightly * Better handling of 32-bit vs 64-bit * Upgrade actions to latest versions * Use Codecov token when uploading to Codecov * Set `GITHUB_TOKEN` permissions to read-only * CI: Skip intermediate builds, and cancel intermediate PR builds * CI: Set up Dependabot to automatically update GitHub Actions (#105) * Don't use a custom job name * Native Julia builds for Apple Silicon macOS are only available for Julia 1.8 and later * Reduce the number of macOS jobs * Add some comments * Add some more comments
…project_rel_path(...)` (#106) * Copy the contents of `src/julia-1.11` to `src/julia-1.13`, and use `src/julia-1.13` for Julia 1.13+ * Julia 1.13+: Use `safe_realpath(manifest_rel_path(...))` instead of `project_rel_path(...)` * Better debug-log printing of exceptions Co-authored-by: Frames White <oxinabox@ucc.asn.au> * Add trailing newline character (for POSIX compliance) --------- Co-authored-by: Frames White <oxinabox@ucc.asn.au>
|
|
|
Ah, I forgot to add all the package old things :) I have all of that in the testitemcintroller package, I'll add it. And I think yes? At least some basic functionality? For the scientific use case I just still think we should support old versions, replication code sticks around for a long time... |
|
So right now we're starting the JDP with whatever version That seems a bit ... unprincipled? Imho this either needs too be the exact same binary as whatever is running in JW, or one selected based on env compat bounds (which adds the complication of requiring juliaup to be installed and having that channel). For now at least I think I'd prefer the one-binary solution. |
|
I think just launching If Juliaup is installed, then this should opt into the entire override hierarchy of Juliaup, i.e. if someone has the manifest-specific Julia launch on then it will use that, or a directory override should work, or the env var, or whatever. If Juliaup isn't installed, then it will just pick whatever Julia is on the I don't think we should use the Julia version the LS is running in, as that is going to always be the |
|
Yes. We can't really assume that |
This reverts commit a3b21f0.
git-subtree-dir: packages-old/v1.5/CodeTracking git-subtree-split: cec7c3f6b46013527e5fa717b9693811275e07f2
…old/v1.5/CodeTracking'
…8721d1 git-subtree-dir: packages-old/v1.5/JuliaInterpreter git-subtree-split: 398721d10be2edf40883a11b98e210ccda5393e3
…old/v1.5/JuliaInterpreter'
…a01bb3 git-subtree-dir: packages-old/v1.5/LoweredCodeUtils git-subtree-split: 6fa01bb38cd4533e10d4cb8108b5c9474f2c5387
…old/v1.5/LoweredCodeUtils'
…cf2bd5f4 git-subtree-dir: packages-old/v1.5/OrderedCollections git-subtree-split: cf2bd5f4fc602ad949a07f0f1e9907cfc363d5f1
…old/v1.5/OrderedCollections'
git-subtree-dir: packages-old/v1.5/Revise git-subtree-split: 5f428c97229cdefdb5a237b743b941caf0640697
git-subtree-dir: packages-old/v1.9/CodeTracking git-subtree-split: 4f3819cb000df5c8deb8211e36f4b742bbe023b8
…old/v1.9/CodeTracking'
…21a756 git-subtree-dir: packages-old/v1.9/JuliaInterpreter git-subtree-split: 0421a756327370fcfc886d0e1b5a3973098e8207
…old/v1.9/JuliaInterpreter'
…b2566b git-subtree-dir: packages-old/v1.9/LoweredCodeUtils git-subtree-split: 6bb2566bc2e23cb733df628886d8640c8eaf5c03
…old/v1.9/LoweredCodeUtils'
git-subtree-dir: packages-old/v1.9/Revise git-subtree-split: 48b46b7337728a897ca8da37da9229559a2f3127
|
I've reverted that commit now and added all the old packages, so the dynamic feature processes should now (maybe) run on old Julia versions. |
Salsa PR #61 is merged and the env-sharing change is committed, so both leave the live backlog; remaining items renumbered. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
6 participants
I'm not sure this will work out, but so far it seems fairly promising. The idea is that we just move the existing content of both packages in here so simplify development.
I also started to change StaticLint so that everything in the
metafield inEXPRis now stored in a side table, that makes everything work fairly nicely with the functional Salsa.jl approach.Still lots of stuff to do, though...
List of PRs that were merged into
mainin various packages and still need to be incorporated here:name === nothingStaticLint.jl#429using Base: fooin baremodule StaticLint.jl#433