`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`.
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>
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.
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.
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
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.
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!
Note that this is not actually *used* by default; it is a matter of
configuration still, because you might want to:
- Compile all .rs files with `rustc %` (where each can be built itself)
- Compile all .rs files with `rustc some-file.rs` (where you are editing
part of a crate)
- Compile with a different tool, such as `make`. (In this case you might
put a `~/.vim/after/compiler/rustc.vim` to match such cases, set
makeprg and extend errorformat as appropriate. That should probably go
in a different compiler mode, e.g. make-rustc.)
To try using it, `:compiler rustc`. Then, `:make` on a file you would
run `rustc` on will work its magic, invoking rustc. To automate this,
you could have something like `autocmd FileType rust compiler rustc` in
your Vim config.
Note that this is not actually *used* by default; it is a matter of
configuration still, because you might want to:
- Compile all .rs files with `rustc %` (where each can be built itself)
- Compile all .rs files with `rustc some-file.rs` (where you are editing
part of a crate)
- Compile with a different tool, such as `make`. (In this case you might
put a `~/.vim/after/compiler/rustc.vim` to match such cases, set
makeprg and extend errorformat as appropriate. That should probably go
in a different compiler mode, e.g. make-rustc.)
To try using it, `:compiler rustc`. Then, `:make` on a file you would
run `rustc` on will work its magic, invoking rustc. To automate this,
you could have something like `autocmd FileType rust compiler rustc` in
your Vim config.
When it's a lifetime, a single quotation mark shouldn't have a matching
single quotation mark inserted after it, as delimitMate does by default.
Note that this is not without problems; a char literal coming after an
odd number of lifetime markers will have its quotation marks behave a
little strangely. That, however, is not my fault, but delimitMate's:
https://github.com/Raimondi/delimitMate/issues/135
Indentation now works correctly on subsequent lines of a multi-line
comment, whether there are leaders (` * `) or not. (Formerly it was
incorrectly doing a two-space indent if there was no leader.)
By default, this no longer puts a ` * ` leader on `/*!` comments, as
that appears to be the current convention in the Rust source code, but
that can easily be re-enabled if desired:
let g:rust_bang_comment_leader = 1
When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)
When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.
The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.
Fixes#3225 (at least in terms of mitigating the multiple library
problem by proactively warning the user about it.)
This improves things like doc comment handling when you press Enter and
making using `gf` or `<C-W>f` work on a `use x;` statement in the
current directory.
- Add fold support (NOT turned on by default)
- Highlight `::` by default
- Support the common `NOTE` as an important note
- Highlight `assert!` and `fail!` differently
- Don't highlight `deriving(...)` except in `#[...]`
Namely, switched in many places to using GNU make provided functions
for directory listing and text processing, rather than spawning a
shell process to do that work.
In the process of the revision, learned about Target-specific
variables, which were very applicable to INSTALL_LIB (which, on a
per-recipe basis, was always receiving the same actual arguments for
its first two formal parameters in every invocation).
http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html
(We might be able to make use of those in future refactorings.)
----
Also adds a cleanup pass to get-snapshot.py as well, since the same
problem arises when we unpack libraries from the snapshot archive into
a build directory with a prior snapshot's artifacts. (I put this step
into the python script rather than the makefile because I wanted to
delay the cleanup pass until after we have at least successfully
downloaded the tarball. That way, if the download fails, you should
not destroy the previous unarchived snapshot libraries and build
products.)
----
Also reverted whitespace changes to minimize diff.
I plan to put them back in in a dedicated commit elsewhere.
This fixes a segfault when configuring rust to use local-rust-root. The
libraries were renamed in the 0.6-0.7 transition, and the script was not copying
them all. I also removed the line referencing libcore (now libstd).
Adds a lint for `static some_lowercase_name: uint = 1;`. Warning by default since it causes confusion, e.g. `static a: uint = 1; ... let a = 2;` => `error: only refutable patterns allowed here`.
Continuation of #7430.
I haven't removed the `map` method, since the replacement `v.iter().transform(f).collect::<~[SomeType]>()` is a little ridiculous at the moment.
- Fix stat struct for Android (found by SEGV at run-pass/stat.rs)
- Adjust some test cases to rpass for Android
- Modify some script to rpass for Android
This switches the unicode functions in core to use static character-range tables and a binary search helper rather than open-coded switch statements. It adds about 50k of read only data to the libcore binary but cuts out a similar amount of compiled IR. Would have done it this way in the first place but we didn't have structured statics for a long time.
The local_stage0 script was not updated after commit 7dcbaed renamed
librustsyntax to libsyntax, so builds using local Rust fail due to
missing libsyntax.
Without this change, rust-mode doesn't work if 'cl hasn't been required
by something else, apparently. I'm not entirely sure what changed such
that I started seeing this problem instead of not, but maybe the emacs
world has been making progress towards not loading 'cl at runtime if
it's only needed at compile time.
(This change was previously submitted as e93a58d52 and accidentally reverted by ad8b437ad.)
Without this change, rust-mode doesn't work if 'cl hasn't been required
by something else, apparently. I'm not entirely sure what changed such
that I started seeing this problem instead of not, but maybe the emacs
world has been making progress towards not loading 'cl at runtime if
it's only needed at compile time.
These commits remove some obsolete language features, make some highlighting more correct with respect to the language spec, and introduce highlighting for macros, attributes, core traits, and the new region syntax.
Copy the keyword list from rust.vim, and add `self` so that it is highlighted
(being liberal with the correct categories).
I'm not quite willing to dive in to clean up the emacs code yet, but at least this gets a (more) modern syntax highlighting list.
- thanks to work in libuv's upstream, we can call libuv's Makefile directly
with parameters, instead of descending in gyp-uv madness and generating
our own.
Without this change, rust-mode doesn't work if 'cl hasn't been required
by something else, apparently. I'm not entirely sure what changed such
that I started seeing this problem instead of not, but maybe the emacs
world has been making progress towards not loading 'cl at runtime if
it's only needed at compile time.
Changes:
- Refactor move mode computation
- Removes move mode arguments, unary move, capture clauses
(though they still parse for backwards compatibility)
- Simplify how moves are handled in trans
- Fix a number of illegal copies that cropped up
- Workaround for bug involving def-ids in params
(see details below)
Future work (I'll open bugs for these...):
- Improve error messages for moves that are due
to bindings
- Add support for moving owned content like a.b.c
to borrow check, test in trans (but I think it'll
"just work")
- Proper fix for def-ids in params
Def ids in params:
Move captures into a map instead of recomputing.
This is a workaround for a larger bug having to do with the def-ids associated
with ty_params, which are not always properly preserved when inlining. I am
not sure of my preferred fix for the larger bug yet. This current fix removes
the only code in trans that I know of which relies on ty_param def-ids, but
feels fragile.
This may break indentation though. However, without it, vim
sees "<->" and interprets it as a "<", folloed by "->", which
it conceals as a right arrow, so I'm not sure which is worse.
