Issues using Metals (Scala Lanugage Server) with Chipyard in VSCode #986
Comments
|
I suspect that maybe the sriracha plugin isn't playing nice with bloop? At one point we supported a native bloop build in CY, you could try going back to the point at which we removed it and see if you could get VSCode to work from there. I'm assuming metal's is calling "sbt bloopInstall" based on some default configuration? So if you go back in time you can see what we had to do to get |
|
Sriracha is the plugin we're using to support both source and published dependencies of chisel & firrtl, hence their missing *.jsons. |
|
Thanks for taking a look @davidbiancolin! Ya I remember #613, although it looks like the changes you needed to make to support
I gather that Metals is essentially supposed to take care of all of that. However, the idea of sbt-sriracha not playing nicely with Metals seems very plausible. To explore this further, I checked out aad28dc (the commit that merged #613 into In case it's useful, here's the Metals log file from this experiment: metals.log |
|
The no definition found thing is symptomatic of an earlier compile problem. Now it seems like the scala compiler itself is out when it's trying to compile the firrtl interpreter. Did you try this in a fresh repo? |
|
Yup, I just tried this again in a fresh repo (clone chipyard, checkout aad28dc, init submodules, populate I also tried commenting out that block of code in |
|
Right, part of why i thought it might be sriracha in the first place was because chisel.json and firrtl.json weren't being generated during bloopInstall. This too appears to be the case on that earlier version (hence your firrtl imports failing). I'd need to have a closer look at the build.sbt, but figuring out why those json files aren't being generated is the crux of the issue. |
|
Ah, this is a good clue, I'll look into this more: scalacenter/bloop#675 |
|
Well, all I could find through GitHub-issue-spelunking was references to this bloop option. I tried enabling it, but the results weren't any different. Then I noticed that it looks like this option is enabled by default, so it makes sense that the outcome is the same. Anyway, that doesn't seem to resolve the issue. |
|
So, I noticed this PR was merged into Rocket Chip recently: chipsalliance/rocket-chip#2846 If that's the dependency-tracking plan going forward for Chipyard as well, then I don't know how much it makes sense to try and fix the interaction between sbt-sriracha and Metals. Any ideas if Chipyard is also going to migrate towards non-source dependencies for chisel/firrtl? |
|
That is the plan. It is a substantially bigger under taking here though. |
|
Same error here, it looks like that metals only load project in chipyard/build.sbt, but firrtl locates in chipyard/tools/firrtl/build.sbt.The same for project Chisel. Is there any way to source firrtl/Chisel? |
|
I think it's probably not worthwhile to spend a lot of time debugging this until #1054 is merged into |
|
So I actually just tried checking out the
Here are some of the warning messages I saw in the Metals log: There was only one compilation error message from bloop, which was on line 106 of It looks like since |
|
When we did have native bloop support, IIRC i had to separately run bloopInstall the jsons from both chipyard and FireSim. I think in VSCode you should be able to provide a different build server intialization script to do the slightly more complicated multi-step bloopInstall -- i'd suggest looking at that. |
|
@tymcauley Is this better now that the Chisel 3.5 / publish-deps stuff is merged in? |
It looks like this are the same as described in this comment: #986 (comment) Which is to say, working in any project that isn't the actual |
|
Now that we have this stuff merged in i'll take the time in the next few weeks to figure out what's up. At SiFive we're using VSCode for most of our dev so i want to get this working in FireSim (and thus Chipyard) for my colleagues. |
|
So i got vscode X metals to work under FireSim-as-top, and i think i had the same problem you had @tymcauley. If bloop isn't installed (listed as a plugin in plugins.sbt), the metals plugin will generally install it for you. However, it's not sufficient to do this just in FireSim or just in Chipyard, it needs to be done in both. Of course, VSCode doesn't know to do that. The workaround is to just add Bloop as a plugin to both FireSIm and Chipyard and tell VSCode that Bloop already installed in the metals plugin. In FireSim as top, i had to use a slightly different SBT launch command but that may not be true of Chipyard. |
Impact: other
Tell us about your environment:
Chipyard Version: Current
devbranch (64aa972)OS: macOS 11.6
Other:
What is the current behavior?
I'm trying to get Metals up and running for Chipyard, but running into a number of issues (can't find many definitions, lots of spurious errors in the workspace related to the
chisel3package not getting linked in properly, etc). Here is how I set it up:./scripts/init-submodules-no-riscv-tools.shchipyardfolder to a new workspace, open up a Scala file (I chosegenerators/chipyard/src/main/scala/IOBinders.scala), install the Metals extension, and then Metals prompts me to import the workspace. It runs for awhile, and then spits out a number of errors.Once Metals runs, you can find its log file at
.metals/metals.log(located in the root of the chipyard repo). I have attached that file here: metals.logInside
IOBinders.scala, if I right-click onIOBinderTupleon line 59, and choose "Go to Definition", it takes me there (line 30 of the same file). However, if I do the same forLazyModuleon line 81, I get the message "No definition found for 'LazyModule'". In both cases, I see this message show up inmetals.log:What is the expected behavior?
I should be able to find type definitions, variable definitions/references across files/modules/subprojects.
Other information
No idea if it's best to discuss this problem in the Chipyard repo, but this should be a good place to start. There are a few especially concerning notes in
metals.log, but it's hard for me to know which of them are serious and which are red herrings.These could explain the fact that I can't see definitions of types like
UInt.Anecdotally, I seem to recall that I was able to get the rocket-chip repo working quite well with metals a month ago or so, but I didn't do a lot of experimentation.
This is a Scala compiler error, but I have no idea how much it actually affects Metals:
The text was updated successfully, but these errors were encountered: