Anchoring the keyword as the first non-whitespace on a line may mean
that the occasional genuine-but-unconventionally-formatted tag is
missed, but it avoids a large number of false positives.
I changed the type descriptive texts about a bit too. That part's purely
cosmetic.
I also changed the ignored file list to use a filename matching the make
rule, `TAGS.vi` instead of `TAGS.vim`.
Anchoring the keyword as the first non-whitespace on a line may mean
that the occasional genuine-but-unconventionally-formatted tag is
missed, but it avoids a large number of false positives.
I changed the type descriptive texts about a bit too. That part's purely
cosmetic.
I also changed the ignored file list to use a filename matching the make
rule, `TAGS.vi` instead of `TAGS.vim`.
llvm supports both win32 native threads and pthread,
but configure tries to find pthread first.
This manually disables pthread to use native api.
This removes libpthreads-2.dll dependency on librustc.
### Remove {As,Into,To}{Option,Either,Result} traits.
Expanded, that is:
- `AsOption`
- `IntoOption`
- `ToOption`
- `AsEither`
- `IntoEither`
- `ToEither`
- `AsResult`
- `IntoResult`
- `ToResult`
These were defined for each other but never *used* anywhere. They are
all trivial and so removal will have negligible effect upon anyone.
`Either` has fallen out of favour (and its implementation of these
traits of dubious semantics), `Option<T>` → `Result<T, ()>` was never
really useful and `Result<T, E>` → `Option<T>` should now be done with
`Result.ok()` (mirrored with `Result.err()` for even more usefulness).
In summary, there's really no point in any of these remaining.
### Rename To{Str,Bytes}Consume traits to Into*.
That is:
- `ToStrConsume` → `IntoStr`;
- `ToBytesConsume` → `IntoBytes`.
rustdoc:
- fix search-bar layout
doc: CSS:
- switch to native pandoc toc depth
- rm some dead code
- clamp width to be readable (we're not Wikipedia!)
- don't background-color titles, it's bloating
- make syntax-highlighting colors inline with rust-lang.org
- space indents
@alexcrichton
### Fix up float highlighting in Vim.
This fixes a regression introduced in #10793.
Having a colorscheme which highlights Float the same as Number (I
believe most do), I hadn't noticed that having the special case of "5."
floats (which was one of the added features in #10793) last made it take
precedence, and so it was left to @thestinger to notice it.
The regression meant that in `5.0`, the `5.` was a `rustFloat` (linked
by default to `Float`) and the `0` was a `rustDecNumber` (linked by
default to `Number`), and for `5.0f32` the `5.` was a `rustFloat` and
the `0f32` was a second `rustFloat` (and thus appeared correctly, though
for the wrong reason).
### Vim keyword highlighting improvements.
- Removed the `log` keyword;
- Removed keyword duplicates;
- Highlighted `const` as `Error` rather than `StorageClass`; and
- Highlighted all the reserved keywords as `Error` rather than as
`Keyword`.
(As usual, these highlightings can be overridden if desired.)
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.
Fixes#10188, #8523.
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.
Fixes#10188, #8523.
- Removed the `log` keyword;
- Removed keyword duplicates;
- Highlighted `const` as `Error` rather than `StorageClass`; and
- Highlighted all the reserved keywords as `Error` rather than as
`Keyword`.
(As usual, these highlightings can be overridden if desired.)
This fixes a regression introduced in #10793.
Having a colorscheme which highlights Float the same as Number (I
believe most do), I hadn't noticed that having the special case of "5."
floats (which was one of the added features in #10793) last made it take
precedence, and so it was left to @thestinger to notice it.
The regression meant that in `5.0`, the `5.` was a `rustFloat` (linked
by default to `Float`) and the `0` was a `rustDecNumber` (linked by
default to `Number`), and for `5.0f32` the `5.` was a `rustFloat` and
the `0f32` was a second `rustFloat` (and thus appeared correctly, though
for the wrong reason).
Specifically, we can now use:
+ beginning-of-defun
+ end-of-defun
+ mark-defun
where "defun" means a Rust item.
+ Add tests in rust-mode-tests.el
+ Fix indentation in rust-mode-tests.el
+ Add support for trait to Imenu
In order to keep up to date with changes to the libraries that `llvm-config`
spits out, the dependencies to the LLVM are a dynamically generated rust file.
This file is now automatically updated whenever LLVM is updated to get kept
up-to-date.
At the same time, this cleans out some old cruft which isn't necessary in the
makefiles in terms of dependencies.
Closes#10745Closes#10744
- Implement comment nesting (the implementation is quite ugly at present
and is not quite correct; note the big comment in that area).
- Highlight invalid escape sequences as errors.
- Fix up various inconsistencies and incorrectnesses in number
highlighting.
- Update prelude items (``std::io::{Buffer, Writer, Reader, Seek}``).
- Highlight the ``proc`` keyword.
- Remove %-formatting sequence highlighting (a relic of old formatting).
- Don't highlight TODO in strings (it's unconventional).
This infrastructure is meant to support runnings tests that involve various
interesting interdependencies about the types of crates being linked or possibly
interacting with C libraries. The goal of these make tests is to not restrict
them to a particular test runner, but allow each test to run its own tests.
To this end, there is a new src/test/run-make directory which has sub-folders of
tests. Each test requires a `Makefile`, and running the tests constitues simply
running `make` inside the directory. The new target is `check-stageN-rmake`.
These tests will have the destination directory (as TMPDIR) and the local rust
compiler (as RUSTC) passed along to them. There is also some helpful
cross-platform utilities included in src/test/run-make/tools.mk to aid with
compiling C programs and running them.
The impetus for adding this new test suite is to allow various interesting forms
of testing rust linkage. All of the tests initially added are various flavors of
compiling Rust and C with one another as well as just making sure that rust
linkage works in general.
Closes#10434
This commit alters the build process of the compiler to build a static
librustrt.a instead of a dynamic version. This means that we can stop
distributing librustrt as well as default linking against it in the compiler.
This also means that if you attempt to build rust code without libstd, it will
no longer work if there are any landing pads in play. The reason for this is
that LLVM and rustc will emit calls to the various upcalls in librustrt used to
manage exception handling. In theory we could split librustrt into librustrt and
librustupcall. We would then distribute librustupcall and link to it for all
programs using landing pads, but I would rather see just one librustrt artifact
and simplify the build process.
The major benefit of doing this is that building a static rust library for use
in embedded situations all of a sudden just became a whole lot more feasible.
Closes#3361
Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.
Also update the manual for these changes, and modernify the EBNF for comments.
Closes#10638
This adds bindings to the remaining functions provided by libuv, all of which
are useful operations on files which need to get exposed somehow.
Some highlights:
* Dropped `FileReader` and `FileWriter` and `FileStream` for one `File` type
* Moved all file-related methods to be static methods under `File`
* All directory related methods are still top-level functions
* Created `io::FilePermission` types (backed by u32) that are what you'd expect
* Created `io::FileType` and refactored `FileStat` to use FileType and
FilePermission
* Removed the expanding matrix of `FileMode` operations. The mode of reading a
file will not have the O_CREAT flag, but a write mode will always have the
O_CREAT flag.
Closes#10130Closes#10131Closes#10121
The code was using (in the notation of Doornik 2005) `f(x_{i+1}) -
f(x_{i+2})` rather than `f(x_i) - f(x_{i+1})`. This corrects that, and
removes the F_DIFF tables which caused this problem in the first place.
They `F_DIFF` tables are a micro-optimisation (in theory, they could
easily be a micro-pessimisation): that `if` gets hit about 1% of the
time for Exp/Normal, and the rest of the condition involves RNG calls
and a floating point `exp`, so it is unlikely that saving a single FP
subtraction will be very useful (especially as more tables means more
memory reads and higher cache pressure, as well as taking up space in
the binary (although only ~2k in this case)).
Closes#10084. Notably, unlike that issue suggests, this wasn't a
problem with the Exp tables. It affected Normal too, but since it is
symmetric, there was no bias in the mean (as the bias was equal on the
positive and negative sides and so cancelled out) but it was visible as
a variance slightly lower than it should be.
There are a few reasons that this is a desirable move to take:
1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable
Here's a quick summary of the points of this pull request which make this
possible:
* Two new lang items were introduced: event_loop, and event_loop_factory.
The idea of a "factory" is to define a function which can be called with no
arguments and will return the new event loop as a trait object. This factory
is emitted to the crate map when building an executable. The factory doesn't
have to exist, and when it doesn't then an empty slot is in the crate map and
a basic event loop with no I/O support is provided to the runtime.
* When building an executable, then the rustuv crate will be linked by default
(providing a default implementation of the event loop) via a similar method to
injecting a dependency on libstd. This is currently the only location where
the rustuv crate is ever linked.
* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
implicitly linking to rustuv by default
Closes#5019
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.
