This commit is a second pass stabilization for the `std::comm` module,
performing the following actions:
* The entire `std::comm` module was moved under `std::sync::mpsc`. This movement
reflects that channels are just yet another synchronization primitive, and
they don't necessarily deserve a special place outside of the other
concurrency primitives that the standard library offers.
* The `send` and `recv` methods have all been removed.
* The `send_opt` and `recv_opt` methods have been renamed to `send` and `recv`.
This means that all send/receive operations return a `Result` now indicating
whether the operation was successful or not.
* The error type of `send` is now a `SendError` to implement a custom error
message and allow for `unwrap()`. The error type contains an `into_inner`
method to extract the value.
* The error type of `recv` is now `RecvError` for the same reasons as `send`.
* The `TryRecvError` and `TrySendError` types have had public reexports removed
of their variants and the variant names have been tweaked with enum
namespacing rules.
* The `Messages` iterator is renamed to `Iter`
This functionality is now all `#[stable]`:
* `Sender`
* `SyncSender`
* `Receiver`
* `std::sync::mpsc`
* `channel`
* `sync_channel`
* `Iter`
* `Sender::send`
* `Sender::clone`
* `SyncSender::send`
* `SyncSender::try_send`
* `SyncSender::clone`
* `Receiver::recv`
* `Receiver::try_recv`
* `Receiver::iter`
* `SendError`
* `RecvError`
* `TrySendError::{mod, Full, Disconnected}`
* `TryRecvError::{mod, Empty, Disconnected}`
* `SendError::into_inner`
* `TrySendError::into_inner`
This is a breaking change due to the modification of where this module is
located, as well as the changing of the semantics of `send` and `recv`. Most
programs just need to rename imports of `std::comm` to `std::sync::mpsc` and
add calls to `unwrap` after a send or a receive operation.
[breaking-change]
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.
This commit shuffles around some CLI flags of the compiler to some more stable
locations with some renamings. The changes made were:
* The `-v` flag has been repurposes as the "verbose" flag. The version flag has
been renamed to `-V`.
* The `-h` screen has been split into two parts. Most top-level options (not
all) show with `-h`, and the remaining options (generally obscure) can be
shown with `--help -v` which is a "verbose help screen"
* The `-V` flag (version flag now) has lost its argument as it is now requested
with `rustc -vV` "verbose version".
* The `--emit` option has had its `ir` and `bc` variants renamed to `llvm-ir`
and `llvm-bc` to emphasize that they are LLVM's IR/bytecode.
* The `--emit` option has grown a new variant, `dep-info`, which subsumes the
`--dep-info` CLI argument. The `--dep-info` flag is now deprecated.
* The `--parse-only`, `--no-trans`, and `--no-analysis` flags have
moved behind the `-Z` family of flags.
* The `--debuginfo` and `--opt-level` flags were moved behind the top-level `-C`
flag.
* The `--print-file-name` and `--print-crate-name` flags were moved behind one
global `--print` flag which now accepts one of `crate-name`, `file-names`, or
`sysroot`. This global `--print` flag is intended to serve as a mechanism for
learning various metadata about the compiler itself.
No warnings are currently enabled to allow tools like Cargo to have time to
migrate to the new flags before spraying warnings to all users.
followed by a semicolon.
This allows code like `vec![1i, 2, 3].len();` to work.
This breaks code that uses macros as statements without putting
semicolons after them, such as:
fn main() {
...
assert!(a == b)
assert!(c == d)
println(...);
}
It also breaks code that uses macros as items without semicolons:
local_data_key!(foo)
fn main() {
println("hello world")
}
Add semicolons to fix this code. Those two examples can be fixed as
follows:
fn main() {
...
assert!(a == b);
assert!(c == d);
println(...);
}
local_data_key!(foo);
fn main() {
println("hello world")
}
RFC #378.
Closes#18635.
[breaking-change]
Was testing rustup on a very minimal Debian installation and got errors during the install process (error occurred in `install.sh` of the Rust nightly.)
Noticed that Rustup was downloading the i686 nightly instead of x86-64. Installing `file` fixed the problem, and this patch adds the probe to ensure file is installed before attempting to use it.
There may still be an issue with the i686 installation, I did not investigate further.
Was testing rustup on a very minimal Debian installation and got errors during the install process (error occurred in `install.sh` of the Rust nightly.)
Noticed that Rustup was downloading the i686 nightly instead of x86-64. Installing `file` fixed the problem, and this patch adds the probe to ensure file is installed before attempting to use it.
There may still be an issue with the i686 installation, I did not investigate further.
This commit collapses the various prelude traits for slices into just one trait:
* SlicePrelude/SliceAllocPrelude => SliceExt
* CloneSlicePrelude/CloneSliceAllocPrelude => CloneSliceExt
* OrdSlicePrelude/OrdSliceAllocPrelude => OrdSliceExt
* PartialEqSlicePrelude => PartialEqSliceExt
This commit collapses the various prelude traits for slices into just one trait:
* SlicePrelude/SliceAllocPrelude => SliceExt
* CloneSlicePrelude/CloneSliceAllocPrelude => CloneSliceExt
* OrdSlicePrelude/OrdSliceAllocPrelude => OrdSliceExt
* PartialEqSlicePrelude => PartialEqSliceExt
- Support gcc-less installation on Windows. To do so in unattended mode run:`<intaller>.exe /TYPE=compact /SILENT`.
- Do not require admin privileges to install.
cc #19519
In regards to:
https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729
This commit:
* Changes the #deriving code so that it generates code that utilizes fewer
reexports (in particur Option::* and Result::*), which is necessary to
remove those reexports in the future
* Changes other areas of the codebase so that fewer reexports are utilized
This closes#19168. It's possible that if the downloading of `rustup.sh`
is interrupted, bad things could happen, such as running a naked
"rm -rf /" instead of "rm -rf /path/to/tmpdir". This wraps rustup.sh's
functionality in a function that gets called at the last time that should
protect us from these truncation errors.
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 `//!`.
