| Age | Commit message (Collapse) | Author |
|---|
|
|
|
rust-mode identifies the "<<" as open angle brackets in
let x = a[i][(1 << i)];
This patch fixes the problem by changing rust-is-in-expression-context
to treat "]" as starting an expression in brace context.
Fixes #212
|
|
|
|
Highlight interpolation in arguments to print! &c.
|
|
Change rust-beginning-of-defun to keep searching when it stops in a
comment or a string. Fixes #222.
|
|
|
|
`union` is a contextual keyword, so highlight it in the correct
context. Otherwise, treat `union` similarly to `struct`.
|
|
|
|
|
|
|
|
|
|
Add context-sensitive fontification for the "default" keyword.
|
|
This patch fixes a bug I found where rust-mode would misindent code
like:
fn each_split_within<'a, F>(ss: &'a str, lim: usize, mut it: F)
-> bool where F: FnMut(&'a str) -> bool {
}
fn test_split_within() {
}
In particular the second "fn" would be indented a level.
On the "fn" line, rust-mode-indent-line was calling
rust-beginning-of-defun, which would go to the previous defun. Fixing
this required moving the definition of rust-top-item-beg-re higher in
the file, before its first use (recent versions of Emacs insist on
this). And, this required removing the "^" from this regexp, which is
ok because the sole use is already adding a "^". Additionally, I moved
the "\\_>" into the regexp, rather than have it added at the point of
use, so that the new use would also benefit.
This patch includes two new test cases.
|
|
fix syntax of "<" appearing after "?"
|
|
Syntax propertize
|
|
The "<" syntax-setting code could be confused after a "?". This patch
changes the code to treat "?" as an "ambiguous operator" and adjust
according to further context.
Fixes #200
|
|
Set open-paren-in-column-0-is-defun-start to nil in rust-mode. This
setting is a performance hack in Emacs, at the expense of correctness in
some cases. However, due to the syntax-ppss cache, I doubt whether this
hack is needed for Rust code.
Fixes #107
|
|
font-lock-syntactic-keywords have been obsolete since Emacs 24.1, the
earliest version supported by rust-mode. Instead, modes are
encouraged to use syntax-propertize-function.
syntax-propertize-function provides a generally better experience.
Syntax propertization is not tied to font lock,so angle bracket
matching will still work when font-lock is disabled. There's no
longer a need to call font-lock-fontify-buffer or font-lock-ensure
(you can see this in the tests). The resulting code is also shorter.
I removed a few tests:
* font-lock-raw-string-constant was written assuming font-lock based
syntax propertization, but that's no longer the case.
* font-lock-extend-region-in-string and
rust-test-revert-hook-preserves-point both called functions that no
longer exist.
There's a fix for a hidden bug in rust-is-in-expression-context. This
previously could signal in some situations, but the signal was hidden
by font-lock. It was visible now when running tests, hence the new
call to condition-case.
I suspect this might fix #192, but I haven't tried it.
|
|
rust-mode-tests.el uses "&optional &rest" in some function signatures.
This was never really correct, and newer versions of Emacs complain
about it. &rest implies &optional, so removing &optional is all that is
needed.
|
|
Fixes #188.
|
|
Previously, indentation went wrong when the comment on the line above
looked like a method call/member access:
fn main() {
// Lorem ipsum lorem ipsum lorem ipsum lorem.ipsum
foo.bar()
}
With this patch:
fn main() {
// Lorem ipsum lorem ipsum lorem ipsum lorem.ipsum
foo.bar()
}
Also, a blank line or a comment broke method-chain indentation:
fn main() {
something.a.do_it
// A comment
.aligned
.more_alignment();
}
With this patch:
fn main() {
something.a.do_it
// A comment
.aligned
.more_alignment();
}
Note that comments interleaving a method chain are not aligned with the
'.' of the method chain.
|
|
Before applying #169 the new test fails with a stack overflow, with #169
it passes.
|
|
Otherwise, rust-format-buffer always moves point to the end of the
buffer.
|
|
Always check whether we're not in a string or comment when looking for
the `where` keyword. Use two helpers for this: `rust-looking-at-where`
and `rust-rewind-to-where`.
|
|
When looking for a `where` in
`rust-rewind-to-beginning-of-current-level-expr`, check that it is not
part of a string or comment.
|
|
|
|
This removes the various Emacs 23 compatibility hacks.
Fixes #137.
Fixes #139.
This also obsoletes PR #141.
|
|
* There is only \u, no \U
* \u requires braces, but allows 1-6 hex digits
|
|
Use font-lock-constant-face instead of font-lock-type-face. Especially in paths, this
tones down the importance of the path prefix, and makes the suffix more visible.
|
|
|
|
Previously, we were always treating :: as a module, but Rust
allows type annotations using :: e.g.
parse::<i32>();
This also changes module highlighting so that only the module name is
highlighted, excluding the ::. This makes rust-mode consistent with
other Emacs modes, such as c++-mode and ruby-mode.
|
|
Fix #104
|
|
Fix #103
|
|
This special case broke indentation of `where` clauses.
|
|
Revisit #82. Now rustfmt has a default style for `where` clauses, it
makes sense to let rust-mode support it by default. How rust-mode
currently indents `where` clauses is totally broken anyway. The line
starting with `where` itself, the following lines that are part of the
`where` clause, and the body were all indented incorrectly. This commit
fixes this.
**Note that this commit does not prescribe a certain indentation style
for where clauses, but supports the most common ones, including
rustfmt's default.**
By choosing the location of (1) `where` and (2) the type parameter
bounds, the user can follow three major indentation styles. There is no
need for a configuration option to choose the style, as the locations of
1 and 2 dictate the style to follow. So all three styles can be used
together in the same file.
For each major style, the opening brace can be on the last line of the
type parameter bounds or on a new line (a or b in the examples). All 6
styles are supported without having to change any configuration option.
See the examples below and the new test cases.
There is one more style that is unfortunately incompatible with the
default `where` indentation style of rustfmt: when the user does not
want `where` to be indented, but aligned with the `fn` or `trait` on the
line before (see examples `foo4a` and `foo4b` below). To enable this
style, the user has to set the new option `rust-indent-where-clause` to
nil (it defaults to t).
Putting `where` and the type parameter bounds on the same line as the
function header is still supported of course (see examples `fooa` and
`foob` below). As there is no indentation, this commit does not
influence this.
Note that rust-mode's indentation has a different goal than rustfmt.
rustfmt reflows code, adds or removes line breaks, reindents, etc.
rust-mode's indentation only indents lines. The goal is not to imitate
rustfmt, but after running rustfmt on a file, reindenting it with
rust-mode should be idempotent. This way, users do not have to deal with
the eternal battle of differing indentation styles of rustfmt and
rust-mode.
The supported styles:
```rust
fn foo1a(a: A, b: B) -> C
where A: Clone + Default,
B: Eq,
C: PartialEq {
let body;
}
fn foo1b(a: A, b: B) -> C
where A: Clone + Default,
B: Eq,
C: PartialEq
{
let body;
}
```
```rust
fn foo2a(a: A, b: B) -> C where A: Clone + Default,
B: Eq,
C: PartialEq {
let body;
}
fn foo2b(a: A, b: B) -> C where A: Clone + Default,
B: Eq,
C: PartialEq
{
let body;
}
```
```rust
fn foo3a(a: A, b: B) -> C where
A: Clone + Default,
B: Eq,
C: PartialEq {
let body;
}
fn foo3b(a: A, b: B) -> C where
A: Clone + Default,
B: Eq,
C: PartialEq
{
let body;
}
```
If the user wants `foo4` instead of `foo1`, `rust-indent-where-clause`
must be set to nil. `foo2` and `foo3` are not influenced by this.
```rust
fn foo4a(a: A, b: B) -> C
where A: Clone + Default,
B: Eq,
C: PartialEq {
let body;
}
fn foo4a(a: A, b: B) -> C
where A: Clone + Default,
B: Eq,
C: PartialEq
{
let body;
}
```
Unchanged:
```rust
fn fooa(a: A, b: B) -> C where A: Clone + Default, ... {
let body;
}
fn foob(a: A, b: B) -> C where A: Clone + Default, ...
{
let body;
}
```
|
|
Correctly indent comments that come after struct members that do not
have a trailing comma.
Before:
struct A {
x: u8
// TOO FAR
}
After:
struct A {
x: u8
// CORRECT
}
|
|
Previously, code of the form:
fn foo_Bar () {}
would be incorrectly highlighted, because the regex matched on word
boundaries rather than symbol boundaries. Test added.
|
|
Recognize raw strings all the way to the end of the buffer if they are
not closed. This is not valid rust code, but the highlighting should
show the mistake.
This also eliminates glitchy behavior that can occur in this situation.
Emacs assumes that edits can't change syntax at positions before the
edit, and raw strings without this change violated this.
|
|
|
|
Add angle brackets to the list of emacs matching characters. Use
syntactic fontification to suppress this where it is not appropriate (in
less than operators, arrows, etc.) Remove the non-syntactic version
that was there previously.
For electric-pair-mode, suppress the pairing for < and > characters that
are not angle brackets.
Because syntax is used for indentation, this fixes some problems with
it, particularly when attempting to stretch type parameter lists over
multiple lines.
|
|
|
|
Factor out the method of looking for a match for a regexp, but filtering
out some of the matches with a filtering function. This will be used
again for angle bracket filtering.
This also fixes an issue with raw string handling.
|
|
Using the syntactic-face-function, we can assign the proper
`font-lock-doc-face' to doc comments ("///", "//!", "/**", "/*!").
Test changes graciously copied from https://github.com/rust-lang/rust-mode/pull/64
|
|
|
|
Thanks again to @GBGamer !
|
|
|
|
|
|
|
|
|
|
|
