This function is called repeatedly by syntax-ppss and so needs to be fast. We adopt a simpler mechanism for determining whether we are in a macro.

Fixes #208

Since nobody seems to have time for maintaining the package, I would propose that I take care of this. Rustic now has some users and maybe we should suggest to use it instead of rust-mode for emacs26+. However it would be nice to get some help with this(rust-mode + rustic).

What do you think ?

It is random, I have no idea how to reproduce it.

Time to time when I save current buffer with rust-mode, let's call it a.rs, emacs does not save it, and instead it open buffer stdin, in other words I press C-x s and current buffer change to "stdin" buffer. This buffer is empty, and a.rs still in modified state. I switch back to a.rs, try to save it and again empty stdin instead of a.rs.

So actually I can not save my rust buffer, I have to set "Rust Format On Save" to off to make possible save, or change mode from rust-mode to text-mode.

This bug appear only recently, so I suppose it is related to last "rustfmt" changes in master.

GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10) of 2019-08-29 rust-mode 20200229.1547

I'm experiencing serious slowdowns when entering insert mode & navigating in general all of a sudden. Not sure what the cause is but figured I'd create an issue as it doesn't happen with rust-mode turned off.

Here's the output from the profiler-report:

Function                            Cpu samples   %

timer-event-handler                       13844  92%
command-execute                             782   5%
 ...                                        187   1%
redisplay_internal (C function)             169   1%
eldoc-pre-command-refresh-echo-area           5   0%
sp--save-pre-command-state                    3   0%

If I expand timer-event-handler, most of the CPU is being hogged on rust-in-macro within the up-list function. Also backward-up-list hogs a good chunk of CPU.

 - apply                                                         2171  77%
  - hl-paren-highlight                                           2090  74%
   - scan-sexps                                                  2077  74%
    - internal--syntax-propertize                                2077  74%
     - syntax-propertize                                         2077  74%
      - rust-syntax-propertize                                   2073  74%
       - rust-ordinary-lt-gt-p                                   2073  74%
        - rust-in-macro                                          1955  69%
         + rust-in-macro                                         1615  57%
         + backward-up-list                                       241   8%
         + rust-rewind-irrelevant                                  95   3%
         + rust-looking-back-ident                                  4   0%
        + rust-in-str-or-cmnt                                     118   4%

Anyone experienced anything similar?

Same issue on current nightly & stable (1.17) I've tried with a clean .spacemacs file and without any additional packages. It's only when rust-mode is enabled I run into this slowdown.

The file I'm working on is less than 1k lines.

Also as an aside, I've tried Emacs24, Ubuntu 15.04, 16.04 and now upgraded to 16.10. This is on a Virtual machine.

Description:	Ubuntu 16.10
Release:	16.10
Codename:	yakkety

Hello,

I tried investigating the window scrolling after rustfmt is run (this issue has been referenced in various forms in issues #268 #231 #251) as I am still experiencing it and imo it's pretty annoying.

I'm not an elisp expert, but I think a quick fix/workaround could be to simply nail the window start position and restore it after rustfmt has finished.

I think there may be still cases where the code reformatting can be a bit confusing (f.e. rustfmt'ing a big messed up file), but at least I'm not getting mad every time I compulsively save a buffer :-)

Can you let me know what you think of this little patch? I tested it a bit and it has greatly improved my coding experience with rustfmt.

Thanks for your time!

EDIT: I did some checks, but I'm not sure how to fix those warning that make the CI fail EDIT2: maybe fixed (not sure if fix is correct though)

Adds a command rust-edit-doctest (bound to C-c C-e by default) that opens the doctest around point in an indirect buffer and pre– as well as postprocesses it to ease editing. The indirect buffer is placed in a new rust-doctest-mode that recognizes a leading hash as a comment character. After editing, the code is replaced in the original file and the region is re-indented. Here’s a screenshot:

This is all accomplished using edit-indirect. If that package is not loaded, the keybinding is not added. I initially placed the definition of the rust-edit-doctest command itself under a conditional, but then I thought it would be more useful to have the command show an explanatory error in case it’s missing.

rust-doctest-mode doesn’t account for escaped hashes. I’m not sure how to implement that. Any suggestions would be welcome!

This is bug is similar to #231, but instead of begin of buffer, at now it jumps to the end of buffer with rust code. I have applied fix from #251

Steps to reproduce:

1. Split window by two and run compile command in the second one: C-x 2 C-x O M-x compile choose and run compilation command
2. Return back to code window and choose code at the middle of buffer and change it's formating in so way that rustfmt should modify it (Do not save buffer)
3. Jump to compilation window C-x O and press g

as result the position of cursor in buffer with rust code will change to the end of buffer.

/cc @brotzeit

Fixes #465.

When rust-syntax-propertize uses rust-macro-scopes to find ranges of text that are macro arguments, it ends up inadvertently poisoning the syntax-ppss cache by applying it to text that doesn't have the necessary syntax-table properties applied yet - the very job that rust-syntax-propertize is trying to do.

However, rust-macro-scopes does much more work than necessary. Rather than producing a list of ranges of macro arguments, we can just use the list of enclosing opening parens provided by syntax-ppss, checking each paren to see if it seems to be a macro or macro_rules call.

We have to keep syntax-ppss's cache accurate for other reasons anyway, so we might as well just use its data, rather than introducing another cache of our own - especially a problematic one (see #465).

• rust-mode.el (rust-in-macro): Consult syntax-ppss's list of enclosing parens, rather than using rust-macro-scope. Remove optional arguments, which were only used by tests. (rust-macro-scopes, rust-macro-scope): Delete. Now we just use syntax-ppss's internal cache. (rust-syntax-propertize): Don't bind rust-macro-scopes. (rust-looking-back-macro-rules): New function. (rust-looking-back-macro): Support a space between macro name and !, by consulting rust-expression-introducers. (rust-expression-introducers): New constant. Use in rust-looking-back-macro and rust-is-in-expression-context. (rust-is-in-expression-context): Use rust-expression-introducers. (rust-looking-back-ident): Don't use looking-back. We've already moved to the correct spot for looking-at, within a save-excursion.
• rust-mode-tests.el: Update tests.

I've been trying to improve some stuff. Let me know what you think about it. I can rebase if you want to merge it.

Try these commands: rust-compile rust-recompile rust-format-call rust-run-clippy

Fixes the following problem: consider code

fn foo(a: u32, b : u32) {}

Here, b was not highlighted as a variable, because the regex didn't take into account possible space before the colon.

Signed-off-by: Konstantin Kharlamov [email protected]

E.g. it takes several seconds for a keypress to appear at the bottom of a file with 400 copies of fn foo<T>() {}. Editing the same file after s/<T>/_T_/ (to preserve the size) is fine.

I am very new to emacs and are trying to set it up for rust development. When I am in a *.rs file and M-x rust-mode this error pops up:

Suspicious state from syntax checker rust-cargo: Flycheck checker rust-cargo returned 101, but its output contained no errors: error: no library targets found in package `learn_async`

Try installing a more recent version of rust-cargo, and please open a bug report if the issue persists in the latest release.  Thanks!

I updated cargo rust with: rustup update and updated all my packages with paradox. Emacs: Doom OS: Fedora config.el:

[...]
(after! rustic
  (setq lsp-rust-server 'rust-analyzer))

(use-package lsp-mode
  :ensure
  :commands lsp
  :custom
  ;; what to use when checking on-save. "check" is default, I prefer clippy
  (lsp-rust-analyzer-cargo-watch-command "clippy")
  (lsp-eldoc-render-all t)
  (lsp-idle-delay 0.6)
  ;; enable / disable the hints as you prefer:
  (lsp-rust-analyzer-server-display-inlay-hints t)
  (lsp-rust-analyzer-display-lifetime-elision-hints-enable "skip_trivial")
  (lsp-rust-analyzer-display-chaining-hints t)
  (lsp-rust-analyzer-display-lifetime-elision-hints-use-parameter-names nil)
  (lsp-rust-analyzer-display-closure-return-type-hints t)
  (lsp-rust-analyzer-display-parameter-hints nil)
  (lsp-rust-analyzer-display-reborrow-hints nil)
  :config
  (add-hook 'lsp-mode-hook 'lsp-ui-mode))

(use-package lsp-ui
  :ensure
  :commands lsp-ui-mode
  :custom
  (lsp-ui-peek-always-show t)
  (lsp-ui-sideline-show-hover t)
  (lsp-ui-doc-enable nil))

(rustic and lsp mode both don't work either but I am starting with rust-mode, because it told me to open a new issue)

This makes me share the Playpen URL directly. And this is kind of necessary for me since the region I'm out of currently, the URL shortener domain itself is blocked. Snapshot here: https://imgur.com/a/ugLLVwP

rust-run fails if cargo run needs a --bin argument, which is the case if:

1. The workspace has multiple binary targets.
2. No target is listed as the package's default-run

It is probably reasonably easy to support this. A possible interface update to rust-run could simply prompt for a target name iff both conditions above hold (multiple binary target, no default) OR it's called with an argument. The chosen target's name could be saved somewhere so further invocations of rust-run can just reuse it (unless called with an arg)

This is a quick and dirty way to get all binary targets from the current workspace, and the default target:

(let* ((json (with-temp-buffer
               (call-process "cargo" nil (current-buffer) nil
                             "metadata" "--format-version" "1")
               (goto-char (point-min))
               (json-parse-buffer)))
       ;; !! this is a bit dirty. !!
       (members (seq-map (lambda (wm)
                           (car (split-string wm " ")))
                         (gethash "workspace_members" json)))
       (targets
        (-flatten ; from dash.el, but not strictly required.
         (seq-map (lambda (v)
                    (seq-keep
                     (lambda (target)
                       (when (seq-contains-p
                              (gethash "kind" target) "bin" 'string=)
                         (gethash "name" target))) v))
                  (seq-map (lambda (package) (gethash "targets" package))
                           (seq-filter
                            (lambda (pkg) (seq-contains-p members (gethash "name" pkg)))
                            (gethash "packages" json))))))
       (default-run (gethash "default_run"
                             (car
                              (seq-filter
                               (lambda (item) (string= "raoc2021" (gethash "name" item)))
                               (gethash "packages" json))))))
  (message "Workspace members: %s" members)
  (message "Binary targets: %s" targets)
  (message "Default run target is: %s" default-run))

What do you think?

rust-beginning-of-defun skips async functions.

The problem starts at rust-mode.el:1228

(defvar rust-top-item-beg-re
  (concat "^\\s-*\\(?:priv\\|pub\\)?\\s-*"
          (regexp-opt
           '("enum" "struct" "type" "mod" "use" "fn" "static" "impl"
             "extern" "trait"))))

(defun rust-beginning-of-defun (&optional arg)
  "Move backward to the beginning of the current defun.

With ARG, move backward multiple defuns.  Negative ARG means
move forward.

This is written mainly to be used as `beginning-of-defun-function' for Rust.
Don't move to the beginning of the line. `beginning-of-defun',
which calls this, does that afterwards."
  (interactive "p")
  (re-search-backward (concat "^\\(" rust-top-item-beg-re "\\)\\_>")
                      nil 'move (or arg 1)))

rust-top-item-beg-re does not include the async keyword anywhere and therefore does not match a function with the async keyword.

I have my CARGO_HOME and RUSTUP_HOME set to ~/.loca/share/cargo and ~/.local/share/rustup respectively, all commands do find the correct binary and run the correct command, but each time I make a change to my rust source file or Cargo.toml file cargo check or cargo metadata fires up automatically using the default cargo directory which is ~/.cargo and keeps re-compiling my program which takes some time and as it is needed to get linting and all I can't skip it.

I tried editing several variables to fix the issue but nothing seems to help,

  (use-package rust-mode
    :straight t
    :hook (rust-mode . lsp-deferred)
    :config
    (with-eval-after-load "lsp-mode"
      (add-to-list 'lsp-enabled-clients 'rust-analyzer))
    :custom
    (rust-format-on-save t)
    (rust-cargo-bin "~/.local/share/rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo")
    (rust-rustfmt-bin "~/.local/share/rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustfmt")
    (lsp-rust-library-directories '("~/.local/share/cargo/registry/src" "~/.local/share/rustup/toolchains"))
    (lsp-rust-analyzer-library-directories '("~/.local/share/cargo/registry/src" "~/.local/share/rustup/toolchains")))

I added all those variables under the custom section, but nothing helps.

I had the problem with other commands not finding the binary path correctly at first, but I fixed that by installing,

  (use-package exec-path-from-shell
    :straight t)

  (when (memq window-system '(mac ns x))
    (exec-path-from-shell-initialize))

If I delete the ~/.cargo directory I get error,

LSP :: Error from the Language Server: waiting for cargo metadata or cargo check (Unknown error)

and after few seconds it starts again, creating the ~/.cargo directory and re-compiling my program.