This patch merges the `libsync` crate into `libstd`, undoing part of the
facade. This is in preparation for ultimately merging `librustrt`, as
well as the upcoming rewrite of `sync`.
Because this removes the `libsync` crate, it is a:
[breaking-change]
However, all uses of `libsync` should be able to reroute through
`std::sync` and `std::comm` instead.
r? @alexcrichton
"_" should keep the default syntax class (symbol, not word). This
allows, e.g., `forward-word' to behave in the familiar way, jumping to
underscores within a function or variable name.
This patch merges the `libsync` crate into `libstd`, undoing part of the
facade. This is in preparation for ultimately merging `librustrt`, as
well as the upcoming rewrite of `sync`.
Because this removes the `libsync` crate, it is a:
[breaking-change]
However, all uses of `libsync` should be able to reroute through
`std::sync` and `std::comm` instead.
Using the current directory may not always be appropriate, for example in
the case where it will unnecessarily trigger a backup to be made.
The only risk with this change is that systems might not have a mktemp.
I am not aware of such a system, but have not tested on Windows. It is
working on a basic Ubuntu and OS X installation.
Looks like I made my previous PR a little too hastily. =)
This PR fixes a couple issues that I discovered with my previous revision:
1. Updated the errorformat to ignore "pointer lines" so that they don't show up in the output (with quickfix jumping, they're redundant and unnecessary).
2. Renamed a couple variables to be more in line with Cargo's terminology (`g:cargo_toml_name` should now be `g:cargo_manifest_name`).
3. Added support for errors reported with absolute paths (looks to be the case when compiling an executable instead of a library).
4. Most importantly, added support for errors reported while compiling a dependency. When building a Cargo package with local dependencies, if one of those dependencies failed to compile, the quickfix would be completely broken as it assumed that all errors were relative to the local manifest, or the closest Cargo.toml. With this update, it now pays attention to lines that end with `(file://<path>)`, and from then on adjusts all errors to be relative to `<path>`.
As a side note, that `<path>` output is somewhat broken on Windows. While `file:///home/damien/...` on *Nix is a valid URI, `file:///C:/Users/damien/...` on Windows is not, because `C:/` (or whatever the drive is) should take the place of the third slash which is *Nix's root, not be appended to it. I added a workaround for this in my script, but I figured I'd mention it to see if this is a bug in how Rust formats paths.
Vim plugins shouldn't override user settings unless they ask!
Stops the plugin from modifying the users settings by default
instead makes them opt-in with `g:rust_recommended_style`
Fixies #11671
This commit changes default relative libdir 'lib' to a relative libdir calculated using LIBDIR provided by --libdir configuration option. In case if no option was provided behavior does not change.
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
"_" should keep the default syntax class (symbol, not word). This
allows, e.g., `forward-word' to behave in the familiar way, jumping to
underscores within a function or variable name.
not in hardcoded libdir path. If there was no LIBDIR provided
during configuration fallback to hardcoded paths.
Thanks to Jan Niklas Hasse for solution and to Alex Crichton for improvements.
Closes#11671
This implements a considerable portion of rust-lang/rfcs#369 (tracked in #18640). Some interpretations had to be made in order to get this to work. The breaking changes are listed below:
[breaking-change]
- `core::num::{Num, Unsigned, Primitive}` have been deprecated and their re-exports removed from the `{std, core}::prelude`.
- `core::num::{Zero, One, Bounded}` have been deprecated. Use the static methods on `core::num::{Float, Int}` instead. There is no equivalent to `Zero::is_zero`. Use `(==)` with `{Float, Int}::zero` instead.
- `Signed::abs_sub` has been moved to `std::num::FloatMath`, and is no longer implemented for signed integers.
- `core::num::Signed` has been removed, and its methods have been moved to `core::num::Float` and a new trait, `core::num::SignedInt`. The methods now take the `self` parameter by value.
- `core::num::{Saturating, CheckedAdd, CheckedSub, CheckedMul, CheckedDiv}` have been removed, and their methods moved to `core::num::Int`. Their parameters are now taken by value. This means that
- `std::time::Duration` no longer implements `core::num::{Zero, CheckedAdd, CheckedSub}` instead defining the required methods non-polymorphically.
- `core::num::{zero, one, abs, signum}` have been deprecated. Use their respective methods instead.
- The `core::num::{next_power_of_two, is_power_of_two, checked_next_power_of_two}` functions have been deprecated in favor of methods defined a new trait, `core::num::UnsignedInt`
- `core::iter::{AdditiveIterator, MultiplicativeIterator}` are now only implemented for the built-in numeric types.
- `core::iter::{range, range_inclusive, range_step, range_step_inclusive}` now require `core::num::Int` to be implemented for the type they a re parametrized over.
I noticed today that `move` wasn't getting highlighted in my editor of choice (emacs), so I went ahead and added it as a keyword in the emacs, vim, and kate editor files. Apparently it has already been done for gedit.
Based on Windows bundle feedback we got to date,
- We *do* want to prefer the bundled linker: The external one might be for the wrong architecture (e.g. 32 bit vs 64 bit). On the other hand, binutils don't add many new features these days, so using an older bundled linker is not likely to be a problem.
- We *do* want to prefer bundled libraries: The external ones might not have the symbols we expect (e.g. what's needed for DWARF exceptions vs SjLj). Since `-L rustlib/<triple>/lib` appears first on the linker command line, it's a good place to keep our platform libs that we want to be found first.
Closes#18325, closes#17726.
`as` (already for a long time) and `move` (which was only added recently, AFAIK) are not marked as keywords in Vim syntax file, so they are not highlighted as keywords in Rust sources. This PR fixes this.
This commit renames a number of extension traits for slices and string
slices, now that they have been refactored for DST. In many cases,
multiple extension traits could now be consolidated. Further
consolidation will be possible with generalized where clauses.
The renamings are consistent with the [new `-Prelude`
suffix](https://github.com/rust-lang/rfcs/pull/344). There are probably
a few more candidates for being renamed this way, but that is left for
API stabilization of the relevant modules.
Because this renames traits, it is a:
[breaking-change]
However, I do not expect any code that currently uses the standard
library to actually break.
Closes#17917
Unicode characters and strings.
Use `\u0080`-`\u00ff` instead. ASCII/byte literals are unaffected.
This PR introduces a new function, `escape_default`, into the ASCII
module. This was necessary for the pretty printer to continue to
function.
RFC #326.
Closes#18062.
[breaking-change]
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
This wasn’t really consistent with other things; the last section of the
import was not highlighted in any other case.
Also `use {foo, bar};` was having the foo and bar not highlighted, where
they would have been as separate statements.
This change is an implementation of [RFC 69][rfc] which adds a third kind of
global to the language, `const`. This global is most similar to what the old
`static` was, and if you're unsure about what to use then you should use a
`const`.
The semantics of these three kinds of globals are:
* A `const` does not represent a memory location, but only a value. Constants
are translated as rvalues, which means that their values are directly inlined
at usage location (similar to a #define in C/C++). Constant values are, well,
constant, and can not be modified. Any "modification" is actually a
modification to a local value on the stack rather than the actual constant
itself.
Almost all values are allowed inside constants, whether they have interior
mutability or not. There are a few minor restrictions listed in the RFC, but
they should in general not come up too often.
* A `static` now always represents a memory location (unconditionally). Any
references to the same `static` are actually a reference to the same memory
location. Only values whose types ascribe to `Sync` are allowed in a `static`.
This restriction is in place because many threads may access a `static`
concurrently. Lifting this restriction (and allowing unsafe access) is a
future extension not implemented at this time.
* A `static mut` continues to always represent a memory location. All references
to a `static mut` continue to be `unsafe`.
This is a large breaking change, and many programs will need to be updated
accordingly. A summary of the breaking changes is:
* Statics may no longer be used in patterns. Statics now always represent a
memory location, which can sometimes be modified. To fix code, repurpose the
matched-on-`static` to a `const`.
static FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
change this code to:
const FOO: uint = 4;
match n {
FOO => { /* ... */ }
_ => { /* ... */ }
}
* Statics may no longer refer to other statics by value. Due to statics being
able to change at runtime, allowing them to reference one another could
possibly lead to confusing semantics. If you are in this situation, use a
constant initializer instead. Note, however, that statics may reference other
statics by address, however.
* Statics may no longer be used in constant expressions, such as array lengths.
This is due to the same restrictions as listed above. Use a `const` instead.
[breaking-change]
Closes#17718
[rfc]: https://github.com/rust-lang/rfcs/pull/246
The tables in libunicode are far too large to want to be inlined into any other
program, so these tables are all going to remain `static`. For them to be legal,
they cannot reference one another by value, but instead use references now.
This commit also modifies the src/etc/unicode.py script to generate the right
tables.
Apart from making the build system determine the LLDB version, this PR also fixes an issue with enums in LLDB pretty printers. In order for GDB's pretty printers to know for sure if a field of some value is an enum discriminant, I had rustc mark discriminant fields with the `artificial` DWARF tag. This worked out nicely for GDB but it turns out that one can't access artificial fields from LLDB. So I changed the debuginfo representation so that enum discriminants are marked by the special field name `RUST$ENUM$DISR` instead, which works in both cases.
The PR does not activate the LLDB test suite yet.
LLDB doesn't allow for reading 'artifical' fields (fields that are generated by the compiler). So do not mark, slice fields, enum discriminants, and GcBox value fields as artificial.
This makes the windows `make dist` target start producing binary tarballs, and tweaks install.sh so they work, in preparation for working on a combined Rust+Cargo installer.
Modify the system %PATH% environment variable instead of the current
user's %PATH% environment. The current user will be an admin user
that may not be the same user who originally started the installer.
Closes#17570.
There are currently two huge problems with the indent file:
1. Long list-like things cannot be indented. See #14446 for one example. Another one is long enums with over 100 lines, including comments. The indentation process stops after 100 lines and the rest is in column 0.
2. In certain files, opening a new line at mod level is extremely slow. See [this](https://github.com/mahkoh/posix.rs/blob/master/src/unistd/mod.rs) for an example. Opening a line at the very end and holing \<cr> down will freeze vim temporarily.
The reason for 1. is that cindent doesn't properly indent things that end with a `,` and the indent file tries to work around this by using the indentation of the previous line. It does this by recursively calling a function on the previous lines until it reaches the start of the block. Naturally O(n^2) function calls don't scale very well. Instead of recalculating the indentation of the previous line, we will now simply use the given indentation of the previous line and let the user deal with the rest. This is sufficient unless the user manually mis-indents a line.
The reason for 2. seems to be function calls of the form
```
searchpair('{\|(', '', '}\|)', 'nbW', 's:is_string_comment(line("."), col("."))')
```
I've no idea what this even does or why it is there since I cannot reproduce the mistake cindent is supposed to make without this fix. Therefore I've simply removed that part.
This is part of the migration of crates into the Cargo ecosystem. There
is now an external repository https://github.com/rust-lang/num for bignums.
The single use of libnum elsewhere in the repository is for a shootout
benchmark, which is being moved into the external crate.
Due to deprecation, this is a:
[breaking-change]
Currently the ZSH completions are quite old an nearly useless. This
brings them up to be compatible with current rust and makes them far
more useful.
Closes#17305
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'
Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
gcc, ld, ar, dlltool, windres go into $(RUST)/bin/rustlib/<triple>/bin/
platform libraries and startup objects got into $(RUST)/bin/rustlib/<triple>/lib/
This builds on https://github.com/rust-lang/rust/pull/17109, putting the target triple into the installer name so that we can have both 32-bit and 64-bit.
The resulting installers will be called `rust-0.12.0-pre-x86_64-w64-mingw32.exe`, etc.
This unifies the `non_snake_case_functions` and `uppercase_variables` lints
into one lint, `non_snake_case`. It also now checks for non-snake-case modules.
This also extends the non-camel-case types lint to check type parameters, and
merges the `non_uppercase_pattern_statics` lint into the
`non_uppercase_statics` lint.
Because the `uppercase_variables` lint is now part of the `non_snake_case`
lint, all non-snake-case variables that start with lowercase characters (such
as `fooBar`) will now trigger the `non_snake_case` lint.
New code should be updated to use the new `non_snake_case` lint instead of the
previous `non_snake_case_functions` and `uppercase_variables` lints. All use of
the `non_uppercase_pattern_statics` should be replaced with the
`non_uppercase_statics` lint. Any code that previously contained non-snake-case
module or variable names should be updated to use snake case names or disable
the `non_snake_case` lint. Any code with non-camel-case type parameters should
be changed to use camel case or disable the `non_camel_case_types` lint.
[breaking-change]
When MSYS shell executes program, if its arguments look like MSYS paths,
MSYS automatically converts them into Windows paths.
For example, `/c/path:/d/path` becomes `C:\path;D:\path`.
However, if there is only one path e.g. `/c/path`, it becomes `C:/path`.
maketest.py reverts the behavior to reduce confusion between MSYS and
Windows, but it didn't handle the `/c/path` case. This patch fixes the
issue.
Fixes#15297Fixes#15250
We shouldn't be setting any settings in the syntax file. Better to put
them in the ftplugin, where they won't be pulled in by :syn-include and
can be cleaned up when changing the filetype.
We shouldn't be setting conceallevel in the syntax file. Besides not
being able to undo this if we switch to another syntax later, it also
interferes with embedding rust in other filetypes (such as markdown).
Instead, set it in the ftplugin, where it belongs.
We shouldn't be setting conceallevel in the syntax file. Besides not
being able to undo this if we switch to another syntax later, it also
interferes with embedding rust in other filetypes (such as markdown).
Instead, set it in the ftplugin, where it belongs.
These are like the existing bsearch methods but if the search fails,
it returns the next insertion point.
The new `binary_search` returns a `BinarySearchResult` that is either
`Found` or `NotFound`. For convenience, the `found` and `not_found`
methods convert to `Option`, ala `Result`.
Deprecate bsearch and bsearch_elem.
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
This leaves the `Share` trait at `std::kinds` via a `#[deprecated]` `pub use`
statement, but the `NoShare` struct is no longer part of `std::kinds::marker`
due to #12660 (the build cannot bootstrap otherwise).
All code referencing the `Share` trait should now reference the `Sync` trait,
and all code referencing the `NoShare` type should now reference the `NoSync`
type. The functionality and meaning of this trait have not changed, only the
naming.
Closes#16281
[breaking-change]
Previously the implementation detection regex would detect
`impl fmt::Show for MyStruct` as `fmt`. Now it will be detected as
`fmt::Show for MyStruct`. Implementations such as `impl MyStruct` will
still be detected as `MyStruct`.
This adds a new `Recompositions` iterator, which performs canonical composition on the result of the `Decompositions` iterator (which is canonical or compatibility decomposition). In effect this implements Unicode normalization forms C and KC.
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
… and color (raw) strings as such in attributes.
This fixes cases where a string contains ] inside an attribute:
that ] used to incorrectly end the attribute coloring.
For large (many lines) doc comments, I’ve found preferable to use
`#![doc = r#"..."#]` to avoid prefixing every line with `//!`.
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
Here’s what the Vim manual says in *:syn-include*:
:sy[ntax] include [@{grouplist-name}] {file-name}
All syntax items declared in the included file will have the
"contained" flag added. In addition, if a group list is
specified, all top-level syntax items in the included file will
be added to that list.
We had two rules for `rustModPath`, one `contained` and the other not.
The effect was that the second (now renamed to `rustModPathInUse`) was
being included in the group list, and thus that all identifiers were
being highlighted as `Include`, which is definitely not what we wanted.
This PR adds the LLDB autotests to the debuginfo test suite so I don't have to keep rebasing them locally. They are still disabled by default in `tests.mk`. One of the commits also contains a Python pretty printer which can make LLDB print values with Rust syntax. This was mainly added to deal with output format differences between LLDB versions but you can also use it for your normal LLDB debugging sessions.
```
// The following LLDB commands will load and activate the Rust printers
command script import ./src/etc/lldb_rust_formatters.py
type summary add --no-value --python-function lldb_rust_formatters.print_val -x .* --category Rust
type category enable Rust
```
Expect some rough edges with these, they have not been tested apart from there use in the autotests...
Tweak the text editing settings (softtabstop, textwidth, etc).
Add some settings to turn on folding and colorcolumn.
Add the undo_ftplugin changes that my previous patch forgot.
- Graphemes and GraphemeIndices structs implement iterators over
grapheme clusters analogous to the Chars and CharOffsets for chars in
a string. Iterator and DoubleEndedIterator are available for both.
- tidied up the exports for libunicode. crate root exports are now moved
into more appropriate module locations:
- UnicodeStrSlice, Words, Graphemes, GraphemeIndices are in str module
- UnicodeChar exported from char instead of crate root
- canonical_combining_class is exported from str rather than crate root
Since libunicode's exports have changed, programs that previously relied
on the old export locations will need to change their `use` statements
to reflect the new ones. See above for more information on where the new
exports live.
closes#7043
[breaking-change]
If ldconfig fails it emits a warning. This is very possible when installing
to a non-system directory, so the warning tries to indicate that it may
not be a problem.
If ldconfig fails it emits a warning. This is very possible when installing
to a non-system directory, so the warning tries to indicate that it may
not be a problem.
This adds detection of the relevant LD_LIBRARY_PATH-like environment variable
and appropriately sets it when testing whether binaries can run or not.
Additionally, the installation prints a recommended value if one is necessary.
Closes#15545
Add libunicode; move unicode functions from core
- created new crate, libunicode, below libstd
- split `Char` trait into `Char` (libcore) and `UnicodeChar` (libunicode)
- Unicode-aware functions now live in libunicode
- `is_alphabetic`, `is_XID_start`, `is_XID_continue`, `is_lowercase`,
`is_uppercase`, `is_whitespace`, `is_alphanumeric`, `is_control`, `is_digit`,
`to_uppercase`, `to_lowercase`
- added `width` method in UnicodeChar trait
- determines printed width of character in columns, or None if it is a non-NULL control character
- takes a boolean argument indicating whether the present context is CJK or not (characters with 'A'mbiguous widths are double-wide in CJK contexts, single-wide otherwise)
- split `StrSlice` into `StrSlice` (libcore) and `UnicodeStrSlice` (libunicode)
- functionality formerly in `StrSlice` that relied upon Unicode functionality from `Char` is now in `UnicodeStrSlice`
- `words`, `is_whitespace`, `is_alphanumeric`, `trim`, `trim_left`, `trim_right`
- also moved `Words` type alias into libunicode because `words` method is in `UnicodeStrSlice`
- unified Unicode tables from libcollections, libcore, and libregex into libunicode
- updated `unicode.py` in `src/etc` to generate aforementioned tables
- generated new tables based on latest Unicode data
- added `UnicodeChar` and `UnicodeStrSlice` traits to prelude
- libunicode is now the collection point for the `std::char` module, combining the libunicode functionality with the `Char` functionality from libcore
- thus, moved doc comment for `char` from `core::char` to `unicode::char`
- libcollections remains the collection point for `std::str`
The Unicode-aware functions that previously lived in the `Char` and `StrSlice` traits are no longer available to programs that only use libcore. To regain use of these methods, include the libunicode crate and `use` the `UnicodeChar` and/or `UnicodeStrSlice` traits:
extern crate unicode;
use unicode::UnicodeChar;
use unicode::UnicodeStrSlice;
use unicode::Words; // if you want to use the words() method
NOTE: this does *not* impact programs that use libstd, since UnicodeChar and UnicodeStrSlice have been added to the prelude.
closes#15224
[breaking-change]
This adds detection of the relevant LD_LIBRARY_PATH-like environment variable
and appropriately sets it when testing whether binaries can run or not.
Additionally, the installation prints a recommended value if one is necessary.
The latest change to aturon/rust-guidelines states that lines must not
exceed 99 characters. This gets rid of the 80/100 split, so we don't
need to customize colorcolumn amymore.
Setting softtabstop makes <Del> delete 4 spaces as if it were a tab.
Setting textwidth allows comments to be wrapped automatically. It's set
at 80, which is the recommended line length for Rust programs. There are
suggestions that it should be 79, but our current style guide says 80 so
that's what we're matching.
A new setting g:rust_colorcolumn sets colorcolumn as well, to +1,101.
This indicates both the textwidth and the second stricter line length of
100 that our style guide lists.
- created new crate, libunicode, below libstd
- split Char trait into Char (libcore) and UnicodeChar (libunicode)
- Unicode-aware functions now live in libunicode
- is_alphabetic, is_XID_start, is_XID_continue, is_lowercase,
is_uppercase, is_whitespace, is_alphanumeric, is_control,
is_digit, to_uppercase, to_lowercase
- added width method in UnicodeChar trait
- determines printed width of character in columns, or None if it is
a non-NULL control character
- takes a boolean argument indicating whether the present context is
CJK or not (characters with 'A'mbiguous widths are double-wide in
CJK contexts, single-wide otherwise)
- split StrSlice into StrSlice (libcore) and UnicodeStrSlice
(libunicode)
- functionality formerly in StrSlice that relied upon Unicode
functionality from Char is now in UnicodeStrSlice
- words, is_whitespace, is_alphanumeric, trim, trim_left, trim_right
- also moved Words type alias into libunicode because words method is
in UnicodeStrSlice
- unified Unicode tables from libcollections, libcore, and libregex into
libunicode
- updated unicode.py in src/etc to generate aforementioned tables
- generated new tables based on latest Unicode data
- added UnicodeChar and UnicodeStrSlice traits to prelude
- libunicode is now the collection point for the std::char module,
combining the libunicode functionality with the Char functionality
from libcore
- thus, moved doc comment for char from core::char to unicode::char
- libcollections remains the collection point for std::str
The Unicode-aware functions that previously lived in the Char and
StrSlice traits are no longer available to programs that only use
libcore. To regain use of these methods, include the libunicode crate
and use the UnicodeChar and/or UnicodeStrSlice traits:
extern crate unicode;
use unicode::UnicodeChar;
use unicode::UnicodeStrSlice;
use unicode::Words; // if you want to use the words() method
NOTE: this does *not* impact programs that use libstd, since UnicodeChar
and UnicodeStrSlice have been added to the prelude.
closes#15224
[breaking-change]
This will break code that used the old `Index` trait. Change this code
to use the new `Index` traits. For reference, here are their signatures:
pub trait Index<Index,Result> {
fn index<'a>(&'a self, index: &Index) -> &'a Result;
}
pub trait IndexMut<Index,Result> {
fn index_mut<'a>(&'a mut self, index: &Index) -> &'a mut Result;
}
Closes#6515.
[breaking-change]
Platform-detection code from `configure` copied over to `install.sh`
in order to special case the lib dir being `bin` on Windows instead
of `lib`.
Short-term fix for #13810.
Part of #14248
Main authors:
- @Ryman: OK
- @TeXitoi: OK
- @pcwalton: OK
Minor authors:
- @brson: OK
- @alexcrichton: OK
- @kballard: OK
Remark: @tedhorst was a main contributor, but its contribution
disapear with @pcwalton rewrite at af4ea11
@brson OK?
Part of #14248
Main authors:
- @Ryman: OK
- @TeXitoi: OK
- @pcwalton: OK
Minor authors:
- @brson: OK
- @alexcrichton: OK
- @kballard: OK
Remark: @tedhorst was a main contributor, but its contribution
disapear with @pcwalton rewrite at af4ea11
Replace its usage with byte string literals, except in `bytes!()` tests.
Also add a new snapshot, to be able to use the new b"foo" syntax.
The src/etc/2014-06-rewrite-bytes-macros.py script automatically
rewrites `bytes!()` invocations into byte string literals.
Pass it filenames as arguments to generate a diff that you can inspect,
or `--apply` followed by filenames to apply the changes in place.
Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
Define a command :Run to compile and run the current file. This supports
unnamed buffers (by writing to a temporary file). See the comment above
the command definition for notes on usage.
Define <D-r> and <D-R> mappings for :Run to make it easier to invoke in
MacVim.
Define a command :Expand to display the --pretty expanded output for the
current file. This can be configured to use different pretty types. See
the comment above the command definition for notes on usage.
Create an autoload file and put function definitions there to speed up
load time.
This addresses the font lock regression introduced by the earlier pull
request #14818 - attributes are no longer be highligted inside of comments
and strings.
Also add some font lock test infrastructure and some tests for attribute
font locking.
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.
There were a few notable changes and a few breaking changes as part of this
movement:
* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
It is now a private module with types/functions being reexported under
`sync::comm`. This is a breaking change for any existing users of duplex
streams.
* All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
live under `std::sync`. They will forever live at this location, but they may
move to libsync if the `std::task` module moves as well.
[breaking-change]
Part of #14248
Main contributors are @pcwalton, @alexcrichton and me. Only
@dguenther appear in git blame as a minor contribution, but it is
only adding the rust license, so removed by this relicensing.
part of #14248, fix#14420
Removed @richo's contribution (outdated comment)
Quoting @brson: let's move forward with this one. The only
statement I'm missing is @richo's and it sounds like his was a
minor patch.
This is part of the ongoing renaming of the equality traits. See #12517 for more
details. All code using Eq/Ord will temporarily need to move to Partial{Eq,Ord}
or the Total{Eq,Ord} traits. The Total traits will soon be renamed to {Eq,Ord}.
cc #12517
[breaking-change]
Attempt to highlight the placement expression in a `box (expr) foo`
expression. Also treat GC as a keyword within the placement expression.
This doesn't work correctly for arbitrary expressions. Notably, this
makes no attempt at balancing delimiters. I believe handling that will
require rewriting the syntax rules to add a region for every pair of
delimiters. That may be a desirable thing to do in the end, because we
can then rewrite our indent rules based on the syntax and get rid of
cindent(), but for the time being, we'll just live with the limitation.
Two line summary: Distinguish HOST_RPATH and TARGET_RPATH; added
RPATH_LINK_SEARCH; skip tests broken in stage1; general cleanup.
`HOST_RPATH_VAR$(1)_T_$(2)_H_$(3)` and `TARGET_RPATH_VAR$(1)_T_$(2)_H_$(3)`
both match the format of the old `RPATH_VAR$(1)_T_$(2)_H_$(3)` (which
is still being set the same way that it was before, to one of either
HOST/TARGET depending on what stage we are building). Namely, the format
is <XXX>_RPATH_VAR = "<LD_LIB_PATH_ENVVAR>=<COLON_SEP_PATH_ENTRIES>"
What this commit does:
* Pass both of the (newly introduced) HOST and TARGET rpath setup vars
to `maketest.py`
* Update `maketest.py` to no longer update the LD_LIBRARY_PATH itself
Instead, it passes along the HOST and TARGET rpath setup vars in
environment variables `HOST_RPATH_ENV` and `TARGET_RPATH_ENV`
* Also, pass the current stage number to maketest.py; it in turn
passes it (via an env var) to run-make tests.
This allows the run-make tests to selectively change behavior
(e.g. turn themselves off) to deal with incompatibilities with
e.g. stage1.
* Cleanup: Distinguish in tools.mk between the command to run (`RUN`)
and the file to generate to drive that command (`RUN_BINFILE`). The
main thing this enables is that `RUN` can now setup the
`TARGET_RPATH_ENV` without having to dirty up the runner code in
each of the `run-make` Makefiles.
* Cleanup: Factored out commands to delete dylib/rlib into
REMOVE_DYLIBS/REMOVE_RLIBS.
There were places where we were only calling `rm $(call DYLIB,foo)`
even though we really needed to get rid of the whole glob (at least
based on alex's findings on #13753 that removing the symlink does not
suffice).
Therefore rather than peppering the code with the awkward
`rm $(TMPDIR)/$(call DYLIB_GLOB,foo)`, I instead introduced a common
`REMOVE_DYLIBS` user function that expands into that when called.
After I adding an analogous `REMOVE_RLIBS`, I changed all of the
existing calls that rm dylibs or rlibs to use these routines
instead.
Note that the latter is not a true refactoring since I may have
changed cases where it was our intent to only remove the sym-link.
(But if that is the case, then we need to more deeply investigate
alex's findings on #13753 where the system was still dynamically
loading up the non-symlinked libraries that it finds on the load
path.)
* Added RPATH_LINK_SEARCH command and use it on Linux.
On some platforms, namely Linux, when you have libboot.so that has
its internal rpath set (to e.g. $(ORIGIN)/path/to/HOSTDIR), the
linker still complains when you do the link step and it does not
know where to find libraries that libboot.so depends upon that live
in HOSTDIR (think e.g. librustuv.so).
As far as I can tell, the GNU linker will consult the
LD_LIBRARY_PATH as part of the linking process to find such
libraries. But if you want to be more careful and not override
LD_LIBRARY_PATH for the `gcc` invocation, then you need some other
way to tell the linker where it can find the libraries that
libboot.so needs. The solution to this on Linux is the
`-Wl,-rpath-link` command line option.
However, this command line option does not exist on Mac OS X, (which
appears to be figuring out how to resolve the libboot.dylib
dependency by some other means, perhaps by consulting the rpath
setting within libboot.dylib).
So, in order to abstract over this distinction, I added the
RPATH_LINK_SEARCH macro to the run-make infrastructure and added
calls to it where necessary to get Linux working. On architectures
other than Linux, the macro expands to nothing.
* Disable miscellaneous tests atop stage1.
* An especially interesting instance of the previous bullet point:
Excuse regex from doing rustdoc tests atop stage1.
This was a (nearly-) final step to get `make check-stage1` working
again.
The use of a special-case check for regex here is ugly but is
analogous other similar checks for regex such as the one that landed
in PR #13844.
The way this is written, the user will get a reminder that
doc-crate-regex is being skipped whenever their rules attempt to do
the crate documentation tests. This is deliberate: I want people
running `make check-stage1` to be reminded about which cases are
being skipped. (But if such echo noise is considered offensive, it
can obviously be removed.)
* Got windows working with the above changes.
This portion of the commit is a cleanup revision of the (previously
mentioned on try builds) re-architecting of how the LD_LIBRARY_PATH
setup and extension is handled in order to accommodate Windows' (1.)
use of `$PATH` for that purpose and (2.) use of spaces in `$PATH`
entries (problematic for make and for interoperation with tools at
the shell).
* In addition, since the code has been rearchitected to pass the
HOST_RPATH_DIR/TARGET_RPATH_DIR rather than a whole sh
environment-variable setting command, there is no need to for the
convert_path_spec calls in maketest.py, which in fact were put in
place to placate Windows but were now causing the Windows builds to
fail. Instead we just convert the paths to absolute paths just like
all of the other path arguments.
Also, note for makefile hackers: apparently you cannot quote operands
to `ifeq` in Makefile (or at least, you need to be careful about
adding them, e.g. to only one side).
There's no need to include this specific flag just for android. We can
already deal with what it tries to solve by using -C linker=/path/to/cc
and -C ar=/path/to/ar. The Makefiles for rustc already set this up when
we're crosscompiling.
I did add the flag to compiletest though so it can find gdb. Though, I'm
pretty sure we don't run debuginfo tests on android anyways right now.
[breaking-change]
The Normalizations iterator has been renamed to Decompositions.
It does not currently include all forms of Unicode normalization,
but only encompasses decompositions.
If implemented recomposition would likely be a separate iterator
which works on the result of this one.
[breaking-change]
cindent handles the following case incorrectly:
impl X {
b: int,
//
c: int,
}
if you try and insert a new line after the `c` declaration.
To fix this, fix the get_line_trimmed() function to work properly, and
then extend GetRustIndent to keep searching backwards until it finds a
non-blank line after trimming. This lets it handle the trailing comma
case properly, as if the comment were never there.
Fixes#14041.
If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.
Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.
If an unbalanced [ exists in a string or comment, this should not be
considered when calculating the indent at the top level.
Similarly, when testing for ({/}) to see if we're at the top level to
begin with, strings and comments should be skipped.
The change in #13600 was incorrect, containing a bad regular expression;
inside an indent function, errors are silently ignored (and the ``~=``
operation will return 0), so it just always failed, causing the cases
that were supposed to be caught to not be caught and making things like
the ``match`` example shown above or struct field definitions regress.
I have fixed the regular expression to what it should have been. This is
still imperfect, of course, not handling cases like where the first
argument to a function is a function call (``foo(bar(),``), but it'll do
for now.
This is a bit of an interesting upgrade to LLVM. Upstream LLVM has started using C++11 features, so they require a C++11 compiler to build. I've updated all the bots to have a C++11 compiler, and they appear to be building LLVM successfully:
* Linux bots - I added gcc/g++ 4.7 (good enough)
* Android bots - same as the linux ones
* Mac bots - I installed the most recent command line tools for Lion which gives us clang 3.2, but LLVM wouldn't build unless it was explicitly asked to link to `libc++` instead of `libstdc++`. This involved tweaking `mklldeps.py` and the `configure` script to get things to work out
* Windows bots - mingw-w64 has gcc 4.8.1 which is sufficient for building LLVM (hurray!)
* BSD bots - I updated FreeBSD to 10.0 which brought with it a relevant version of clang.
The largest fallout I've seen so far is that the test suite doesn't work at all on FreeBSD 10. We've already stopped gating on FreeBSD due to #13427 (we used to be on freebsd 9), so I don't think this puts us in too bad of a situation. I will continue to attempt to fix FreeBSD and the breakage on there.
The LLVM update brings with it all of the recently upstreamed LLVM patches. We only have one local patch now which is just an optimization, and isn't required to use upstream LLVM. I want to maintain compatibility with LLVM 3.3 and 3.4 while we can, and this upgrade is keeping us up to date with the 3.5 release. Once 3.5 is release we will in theory no longer require a bundled LLVM.
When calling a function, or anything with nested parens,
default to cindent's indent. The least error-prone way I
could think of identifying this is to look for a line
that ends with a ',', as well as a non-zero number of
any character except parens before the comma, and
then an open paren.
This will overlap with the previous rule accounting for
function definitions, but that should be fine because
it is also using cindent.
