| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
This is a rather more extensive change than the last, but *ever* so much
easier to maintain reasonably, as there's then something to track
directly.
|
|
I added a few and removed a few and corrected a couple, all with
reference to the prelude. It ends up a slightly arbitrary decision
precisely what ends up in and what doesn't, unfortunately.
|
|
- Remove highlighting of ``L"..."`` (obsolete syntax)
- Remove backslash at end of line being a line continuation always
(obsolete syntax; this only affects comments, actually)
- Add highlighting for backslash at end of line and leading whitespace
on the following line inside a string (a genuine line continuation)
|
|
opening curly brace
|
|
|
|
|
|
|
|
`default-tab-width` is standardly 8, but most programmers and style guides prefer an indentation width smaller than that. Rust itself uses 4 space indents. Most other Emacs modes define the indentation width as 4 or 2 spaces, independently of the width of a Tab character. Depending on `default-tab-width` makes especially little sense for rust-mode because it sets `indent-tabs-mode` to `nil`.
|
|
r? anybody
|
|
default-tab-width is standardly 8, but most programmers and style
guides prefer an indentation width smaller than that. Rust itself
uses 4 space indents. Most other Emacs modes define the indentation
width as 4 or 2 spaces, independently of the width of a Tab character.
Depending on default-tab-width makes especially little sense for
rust-mode because it sets indent-tabs-mode to nil.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
|
|
Fix #6887. (or rather, a bug injected by my prior commit for fixing that bug.)
|
|
This callstack changed when the FFI did. I am still a little frightened by
this suppression.
cc #8253
|
|
|
|
pnkfelix/rust/fsk-issue6887-fix-emacs-compilation-regexp, r=graydon
Fix #6887
|
|
This callstack changed when the FFI did. I am still a little frightened by
this suppression.
|
|
|
|
|
|
|
|
Fix #6887.
|
|
|
|
This adds support for performing Unicode Normalization Forms D and KD on strings.
To enable this the decomposition and canonical combining class properties are added to std::unicode.
On my system this increases libstd's size by ~250KiB.
|
|
|
|
|
|
This fixes some errors which extract_grammar.py reports, when called with
python2.7 src/etc/extract_grammar.py <doc/rust.md
|
|
add missing symnames
Signed-off-by: Jan Kobler <eng1@koblersystems.de>
|
|
|
|
Adds `--target-cpu` flag which lets you choose a more specific target cpu instead of just passing the default, `generic`. It's more or less akin to `-mcpu`/`-mtune` in clang/gcc.
|
|
the default, 'generic'.
|
|
|
|
Add new variable rust-indent-offset, defaulting to
the old value, and use it.
|
|
|
|
etc: add the `in` keyword to the emacs mode.
|
|
I suspect that this is a race between process exit and the termination of
worker threads used by libuv (if I sleep before exit it doesn't leak). This
isn't going to cause any real problems but should probably be fixed at
some point.
r? @pcwalton
cc #8253
|
|
|
|
this has been replaced by `for`
|
|
|
|
|
|
I suspect that this is a race between process exit and the termination of
worker threads used by libuv (if I sleep before exit it doesn't leak). This
isn't going to cause any real problems but should probably be fixed at
some point.
|
|
Sigil highlighting isn't perfect (especially how it handles ``&``) but
after having used it for a week I feel it to be considerably nicer than
nothing. As usual, if you don't like it, you can turn it off easily by
overriding the default highlighting.
Generics are not handled specially; this means that for something like
``S<T>``, the ``<`` and ``>`` are highlighted as operators. For myself,
I like this, and there is no way to make it properly context aware
without expanding the syntax matching enormously.
Also, special characters are highlighted properly in strings/chars, e.g.
``"\x00"`` or ``'\Ufedcba98'`` appropriately.
|
|
Allow some common ones that are good for examples, however.
Closes #3636
|
|
Allow some common ones that are good for examples, however.
|
|
The previous mode did a lot of very manual char-at-a-time parsing and was quite fragile and difficult to maintain. I talked to Marijn and he suggested I'd have better luck just rewriting it from scratch. This is the result of that effort; it seems to be faster, a bit easier on the eyes and more-or-less as well behaved when indenting. The algorithm is a bit different I suspect (it was hard to tell the previous one) but I tried to keep it simple and pleasant-looking.
|
|
|
|
Hello,
I made a tiny change to `tidy.py` so that it uses a regexp to find `// NOTE` comments. I could not find an easy way to write an automated test for this but if this is needed and possible I'd be happy to write one.
Please note that it also removes extra empty lines that appear after each of these warnings (I believe that there were not wanted).
On the performance side, `make tidy` is now a bit slower (running it 10 times in a row takes 71s on my machine, 65s before) but I don't think that it is performance sensitive.
Thanks!
|
|
See #3994.
|
|
`make tidy` now detects `//NOTE`, `// NOTE`, etc.
This also removes the extra empty line emitted after each warning.
Fixes #6060
|
|
See #3994.
|
|
rm obsolete no-op lints
|
