Refactors parsing of numerical literals to make it more readable.
Removes 'float'/the 'f' literal suffix and invalid character literals ''' and '\'.
Also makes attribute highlighting more robust and allows urls in attributes to be recognized.
This will make sure that system files that rust binaries depend on in Windows get packaged into stage0 snapshots as well as into Windows installer.
Currently these include `libgcc_s_dw2-1.dll`, `libstdc++-6.dll` and `libpthread-2.dll`. Note that the latter will need to be changed to `pthreadGC2.dll` once Windows build bots get upgraded to mingw 4.0
Closes#9252Closes#5878Closes#9218Closes#5712
This fixes a problem with paragraph fills: hitting M-q on a single-line-style (`//`) comment with code immediately before or after it would try to fill the code as part of the paragraph too.
This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.
For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.
The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.
Closes#8651Closes#3547Closes#2537Closes#6971Closes#9222
This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.
For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.
The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.
Closes#8651Closes#3547Closes#2537Closes#6971Closes#9222
This works by adding this directory to GCC include search path before mingw system headers directories,
so we can intercept their inclusions and add missing definitions without having to modify files in mingw/include.
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
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)
`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.)
