- 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.
The goal of the snapshot bots is to produce binaries which can run in as many
locations as possible. Currently we build on Centos 6 for this reason, but with
LLVM's update to C++11, this reduces the number of platforms that we could
possibly run on.
This adds a --enable-llvm-static-stdcpp option to the ./configure script for
Rust which will enable building a librustc with a static dependence on
libstdc++. This normally isn't necessary, but this option can be used on the
snapshot builders in order to continue to make binaries which should be able to
run in as many locations as possible.
When clang is enabled, also pass through --enable-libcpp to LLVM's configure
command line to help it pick up the most recent c++ runtime library. This also
changes the mklldeps.py script to pick up on whether LLVM was linked against
stdc++ or c++ based on the --cxxflags that llvm-config prints.
In an ongoing attempt to update LLVM, the bots need to update their C compilers
to something that supports c++11 (LLVM recently switched). The OSX bots are
running Lion (10.7), which only supports up to gcc 4.2 and clang 3.2. Apparently
the libstdc++ is too old (even on the most updated command line tools) for LLVM,
but using libc++ instead appears to work just fine.
* Use `setq-local` instead of `(set (make-local-variable 'var) value)`. Provides a version for older Emacsen.
* Remove use of `cl.el`.
* Use \' in file regexp instead of line end match $.
* Use type for `defcustom` and add parent group.
* Use `setq-local' instead of (set (make-local-variable ...) value).
Provides a version for older Emacsen.
* Remove use of `cl.el'.
* Use \' in file regexp instead of line end match $.
* Use type for defcustom and add parent group.
Few places where previous version of tidy script cannot find XXX:
* inside one-line comment preceding by a few spaces;
* inside multiline comments (now it finds it if multiline comment starts
on the same line with XXX).
Change occurences of XXX found by new tidy script.
Rust currently defaults to `RelocPIC` regardless. This patch adds a new
codegen option that allows choosing different relocation-model. The
available models are:
- default (Use the target-specific default model)
- static
- pic
- no-pic
For a more detailed information use `llc --help`
Rust currently defaults to `RelocPIC` regardless. This patch adds a new
codegen option that allows choosing different relocation-model. The
available models are:
- default (Use the target-specific default model)
- static
- pic
- no-pic
For a more detailed information use `llc --help`
Closes#13285 (rustc: Stop using LLVMGetSectionName)
Closes#13280 (std: override clone_from for Vec.)
Closes#13277 (serialize: add a few missing pubs to base64)
Closes#13275 (Add and remove some ignore-win32 flags)
Closes#13273 (Removed managed boxes from libarena.)
Closes#13270 (Minor copy-editing for the tutorial)
Closes#13267 (fix Option<~ZeroSizeType>)
Closes#13265 (Update emacs mode to support new `#![inner(attribute)]` syntax.)
Closes#13263 (syntax: Remove AbiSet, use one Abi)
This performs a few touch-ups to the OSX installer:
* A rust logo is shown during installation
* The installation happens to /usr/local by default (instead of /)
* A new welcome screen is shown that's slightly more relevant
This performs a few touch-ups to the OSX installer:
* A rust logo is shown during installation
* The installation happens to /usr/local by default (instead of /)
* A new welcome screen is shown that's slightly more relevant
Summary:
So far, we've used the term POD "Plain Old Data" to refer to types that
can be safely copied. However, this term is not consistent with the
other built-in bounds that use verbs instead. This patch renames the Pod
kind into Copy.
RFC: 0003-opt-in-builtin-traits
Test Plan: make check
Reviewers: cmr
Differential Revision: http://phabricator.octayn.net/D3
Several things here:
* Cleanup
* Fix build targets for building .pkg so that it works and works for all hosts
* Adds support for nightly artifacts
* Put docs in a location suitable for upload to s3 during 'make dist'
* Add coverage of unix binary installers to 'distcheck'
* Fix 'distcheck'
* Change 'dist' to build source tarballs, binary tarballs and OS X packages
This commit shreds all remnants of libextra from the compiler and standard
distribution. Two modules, c_vec/tempfile, were moved into libstd after some
cleanup, and the other modules were moved to separate crates as seen fit.
Closes#8784Closes#12413Closes#12576
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>
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.
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.
