| Age | Commit message (Collapse) | Author | Lines |
|---|
|
* Chan<T> => Sender<T>
* Port<T> => Receiver<T>
* Chan::new() => channel()
* constructor returns (Sender, Receiver) instead of (Receiver, Sender)
* local variables named `port` renamed to `rx`
* local variables named `chan` renamed to `tx`
Closes #11765
|
|
* Chan<T> => Sender<T>
* Port<T> => Receiver<T>
* Chan::new() => channel()
* constructor returns (Sender, Receiver) instead of (Receiver, Sender)
* local variables named `port` renamed to `rx`
* local variables named `chan` renamed to `tx`
Closes #11765
|
|
Remove whitespace
Update documentation for to_uppercase, to_lowercase
|
|
|
|
|
|
The rust-mode-indent-line function had a check, which ran after all the
calculations for how to indent had already happened, that skipped
actually performing the indent if the line was already at the right
indentation.
Because of that, the cursor did not jump to the indentation if the line
wasn't changing. This was particularly annoying if there was nothing
but spaces on the line and you were at the beginning of it--it looked
like the indent just wasn't working.
This removes the check and adds test cases to cover this.
|
|
|
|
This functionality is not super-core and so doesn't need to be included
in std. It's possible that std may need rand (it does a little bit now,
for io::test) in which case the functionality required could be moved to
a secret hidden module and reexposed by librand.
Unfortunately, using #[deprecated] here is hard: there's too much to
mock to make it feasible, since we have to ensure that programs still
typecheck to reach the linting phase.
|
|
- remove `node.js` dep., it has no effect as of #12747 (1)
- switch between LaTeX compilers, some cleanups
- CSS: fixup the print stylesheet, refactor highlighting code (2)
(1): `prep.js` outputs its own HTML directives, which `pandoc` cannot recognize when converting the document into LaTeX (this is why the PDF docs have never been highlighted as of now).
Note that if we were to add the `.rust` class to snippets, we could probably use pandoc's native highlighting capatibilities i.e. Kate ([here is](http://adrientetar.github.io/rust-tuts/tutorial/tutorial.pdf) an example of that).
(2): the only real highlighting change is for lifetimes which are now brown instead of red, the rest is just refactor of twos shades of red that look the same.
Also I made numbers highlighting for src in rustdoc a tint more clear so that it is less bothering.
@alexcrichton, @huonw
Closes #9873. Closes #12788.
|
|
|
|
|
|
|
|
`prep.js` outputs its own HTML directives, which `pandoc` cannot
recognize when converting the document into LaTeX (this is why the
PDF docs have never been highlighted as of now).
Note that if we were to add the `.rust` class to snippets, we could
probably use pandoc's native highlighting capatibilities i.e. Kate.
|
|
This converts it to be very similar to crates.mk, with a single list of
the documentation items creating all the necessary bits and pieces.
Changes include:
- rustdoc is used to render HTML & test standalone docs
- documentation building now obeys NO_REBUILD=1
- testing standalone docs now obeys NO_REBUILD=1
- L10N is slightly less broken (in particular, it shares dependencies
and code with the rest of the code)
- PDFs can be built for all documentation items, not just tutorial and
manual
- removes the obsolete & unused extract-tests.py script
- adjust the CSS for standalone docs to use the rustdoc syntax
highlighting
|
|
The incompatibility of rust-mode with global-whitespace-mode warned
about in the README was actually fixed by commit 581b3db3b3. Remove the
warning from the README and close #3994.
|
|
The incompatibility of rust-mode with global-whitespace-mode warned
about in the README was actually fixed by commit 581b3db3b3. Remove the
warning from the README and close #3994.
|
|
This commit let librustc automatically pickup LDFLAGS dependencies
inherited from LLVM, which may otherwise result in undefined
references to external symbols under certain linking environment.
A symptom of this issue is eg. a failure when trying to link against
librustc (due to unresolved ffi_*i symbols), while using a system-wide
LLVM.
Signed-off-by: Luca Bruno <lucab@debian.org>
|
|
vim: Tweak how comment nesting works
Reviewed-by: brson
|
|
Before it would only catch lines starting `fn` or `pub fn`.
Now it can cope with:
- attributes (e.g. `#[test] fn`)
- external functions (e.g. `extern fn`, `extern "C" fn`)
- unsafe functions (e.g. `unsafe fn`)
… and any correct combination of these
(e.g. `#[test] extern "C" unsafe fn`).
|
|
|
|
(Expressed another way: make `[[` et al. work with the curly brace at
the end of a line as is standard Rust style, not just at the start is it
is by default in Vim, from K&R style.)
This came out of #11492, where a simpler but less effective technique
was initially proposed; some discussion of the techniques, ways and
means can be found there.
There are still a few caveats:
- Operator-pending mode behaves differently to the standard behaviour:
if inside curly braces, it should delete up to and including the
closing of the outermost curly brace (that doesn't seem to me
consistent with documented behaviour, but it's what it does). Actual
behaviour (the more logical and consistent, in my opinion): up to the
start of the next outermost curly brace.
- With folding enabled (`set fdm=syntax`), `[[` and `]]` do not behave
as they should: the default behaviour treats an entire closed fold as
one line for these purposes while this code does not (I explicitly
`set nofoldenable` in the function—the side-effects are worse with
folds enabled), leading to unexpected behaviour, the worst of which is
`[[` and/or `]]` not working in visual mode on a closed fold (visual
mode keeps it at the extreme end of the region line of the folded
region, so it's always going back to the opening line of that fold and
immediately being shoved back to the end by visual mode).
- `[[` and `]]` are operating inside comments, whereas the standard
behaviour skips comments.
- The viewport position is sometimes changed when it should not be
necessary.
|
|
|
|
This means it gets highlighted as Error by default.
|
|
Just like the bare keyword `crate` is highlighted as Error (a little
dubious, actually, given macros), `mod` is invalid after `extern`: it's
obsolete syntax.
|
|
|
|
I've added details in the description of each comment as to what it does, which I won't redundantly repeat here in the PR. They all relate to indentation in the emacs rust-mode.
What I will note here is that this closes #8787. It addresses the last remaining case (not in the original issue description but in a comment), of indenting `match` statements. With the changes here, I believe every problem described in the issue description or comments of #8787 is addressed.
|
|
This involves passing through LD_LIBRARY_PATH through more places, specifically
in the compiletest, run-make, and doctest runners.
|
|
Don't try to match line comments inside of a comment block. That makes
no sense and can highlight differently for people who override their
highlights.
Similarly, don't match a doc-comment inside of a comment block. It
shouldn't be highlighted differently unless it's actually a doc-comment
(and nested comments are obviously not doc comments).
Fixes #12307.
|
|
|
|
These two containers are indeed collections, so their place is in
libcollections, not in libstd. There will always be a hash map as part of the
standard distribution of Rust, but by moving it out of the standard library it
makes libstd that much more portable to more platforms and environments.
This conveniently also removes the stuttering of 'std::hashmap::HashMap',
although 'collections::HashMap' is only one character shorter.
|
|
|
|
This changes the indent to calculate positions relative to the enclosing
block (or braced/parenthesized expression), rather than by an absolute
nesting level within the whole file. This allows things like this to
work:
let x =
match expr {
Pattern => ...
}
With the old method, only one level of nesting would be added within the
match braces, so "Pattern" would have ended up aligned with the match.
The other change is that multiple parens/braces on the same line only
increase the indent once. This is a very common case for passing
closures/procs. The absolute nesting method would do this:
spawn(proc() {
// Indented out two indent levels...
})
whereas the code in this commit does this:
spawn(proc() {
// Indented out only one level...
})
|
|
When indenting a non-blank line, stay at the same cursor position
relative to the content after indenting.
|
|
Aligns to the same column if the previous line ends in a single '|' (but
not a '||').
|
|
This patch merges IterBytes and Hash traits, which clears up the
confusion of using `#[deriving(IterBytes)]` to support hashing.
Instead, it now is much easier to use the new `#[deriving(Hash)]`
for making a type hashable with a stream hash.
Furthermore, it supports custom non-stream-based hashers, such as
if a value's hash was cached in a database.
This does not yet replace the old IterBytes-hash with this new
version.
|
|
This involves passing through LD_LIBRARY_PATH through more places, specifically
in the compiletest, run-make, and doctest runners.
|
|
|
|
This is part of the effort to simplify `std::num`, as tracked in issue #10387. It is also a step towards a proper IEEE-754 trait (see #12281).
|
|
|
|
Work toward #9876.
This adds `prepare.mk`, which is simply a more heavily-parameterized `install.mk`, then uses `prepare` to implement both `install` and the windows installer (`dist`). Smoke tested on both Linux and Windows.
|
|
This is part of the effort to simplify `std::num`, as tracked in issue #10387.
|
|
These are adequately covered by the Tuple2 trait.
|
|
|
|
This was previously implemented, and it just needed a snapshot to go through
|
|
|
|
|
|
|
|
|
|
These seem to be causing iloops on the bots. Let's rather see the errors.
|
|
|
