1. 15 Mar, 2021 2 commits
  2. 14 Mar, 2021 8 commits
  3. 12 Mar, 2021 1 commit
  4. 10 Mar, 2021 1 commit
  5. 09 Mar, 2021 2 commits
  6. 08 Mar, 2021 4 commits
  7. 06 Mar, 2021 2 commits
  8. 05 Mar, 2021 1 commit
  9. 04 Mar, 2021 9 commits
    • Christian Hergert's avatar
      meson-templates: use master for template · b25aa272
      Christian Hergert authored
      We can change this once things have been released, but its nice to keep
      it pinned to the same version as GNOME Builder itself.
    • Christian Hergert's avatar
    • Christian Hergert's avatar
      rust-analyzer: be more defensive · 73f0844c
      Christian Hergert authored
      Squash some potential runtime warnings.
    • Christian Hergert's avatar
      rust-analyzer: use rust-analyzer from SDKs when possible · 5fc67891
      Christian Hergert authored
      This is a fairly large rework of this code, so some things are better,
      some things fell through the cracks.
      First, what was removed:
       * Downloading and installing of rust-analyzer
      In most cases this is fine. Because with SDKs from Flathub, we will already
      have the rust-analyzer available now that SDK extensions are automatically
      resolved and installed.
      For cases where people are developing on their host, it's almost certain
      they already have rust-analyzer, so no need for us to manage installing
      that with all the annoyances that go with it.
      The RustAnalyzerService now defers the work of locating the rust-analyzer
      binary as well as creating a launcher with all the proper environment
      setup to the new RustAnalyzerPipelineAddin. This gets updated every time
      the pipeline changes so the RustAnalyzerService will track that and
      replace the launcher on the subprocess supervisor.
      When the subprocess supervisor spawns a new rust-analyzer, the LSP client
      is replaced with one talking to the new daemon over stdin/stdout.
      Initial startup of rust-analyzer was quite slow which appeared to be
      because of double compilation. There isn't an obvious way to specify how
      to use shared build directory when you're doing out of tree builds, but
      setting CARGO_TARGET_DIR and CARGO_HOME can help us when we're building
      GNOME application templates. So basically we just check to see if we're
      building with meson and override those.
      It's not clear to me if there is still double compilation going on, but
      at least I don't get a target/ directory in both builddir and the source
      tree now. So at least there is that.
      Our Cargo plugin alread sets some of these variables, so they can be
      inheritted by using a launcher from the build pipeline.
      Tested with a GNOME application template and Cargo template, both seemed
      to work fine.
      If you have time, please help test this before GNOME 40.
      Signed-off-by: Christian Hergert's avatarChristian Hergert <chergert@redhat.com>
    • Christian Hergert's avatar
      threading: keep identifier around for debug purposes · 73ba910e
      Christian Hergert authored
      It's nice to give a better error/debug message about the process that
      had been executing.
    • Christian Hergert's avatar
      lsp: provide information via workspaceFolders · fa7aa04a
      Christian Hergert authored
      This is a duplication of other information, but it seems to get things
      going further for newer LSPs.
    • Christian Hergert's avatar
    • Christian Hergert's avatar
    • Christian Hergert's avatar
      completion: handle loss of client · 4c3ab66d
      Christian Hergert authored
  10. 03 Mar, 2021 6 commits
  11. 02 Mar, 2021 4 commits