The escaped newline in the middle of the variable reference breaks the
short hash substitution, leaving the link text exmpty; rewrap so that
each replacement is on its own line.
The escaped newline in the middle of the variable reference breaks the
short hash substitution, leaving the link text exmpty; rewrap so that
each replacement is on its own line.
Remove superfluous parentheses from the CTAGS_LOCATIONS expression.
Fixes the following error when executing `make TAGS.vi`:
/bin/sh: -c: line 0: syntax error near unexpected token `)'
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.
For more context, see the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230)
[breaking-change]
This commit removes the `librustuv` crate.
See the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230) for more context.
See [green-rs](https://github.com/alexcrichton/green-rs/) for a possible
migration path if you wish to continue using green-threaded I/O. The
library provides its own I/O API surface.
[breaking-change]
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.
Setting LC_ALL to C helps keep gdb's output consistent ('print' gives us expected output). This fixes#17423. I do not have access to a windows/mac machines to test this. I've only tested it on an x86_64 linux box.
Right now, libuv will **always** be built for the host system (at least when building on OSX) because the information about the cross compiler is never actually passed to GYP. I don't know how anybody has been managing to build cross compilers with this.
Note that, at least on OSX, there is a bug in GYP that will send clang flags to non-clang compilers and it will still attempt to use Xcode's libtool, so this doesn't completely fix the problem of cross-compiling on an OSX host, but it's a start.
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
This updates our build system to prefer `i686-w64-mingw32` as the 32-bit windows triple instead of `i686-pc-mingw32`. This is an interim step to make the build artifacts consistent until https://github.com/rust-lang/rust/issues/15717 is done.
The Guide isn't 100% perfect, but it's basically complete. It's
certainly better than the tutorial is. Time to start pointing more
people its way.
I also just made it consistent to call all things 'guides' rather than
tutorials.
Fixes#9874. This is the big one.
And two bugs that just go away.
Fixes#14503.
Fixes#15009.
The Guide isn't 100% perfect, but it's basically complete. It's
certainly better than the tutorial is. Time to start pointing more
people its way.
I also just made it consistent to call all things 'guides' rather than
tutorials.
Fixes#9874. This is the big one.
And two bugs that just go away.
Fixes#14503.
Fixes#15009.
gcc, ld, ar, dlltool, windres go into $(RUST)/bin/rustlib/<triple>/bin/
platform libraries and startup objects got into $(RUST)/bin/rustlib/<triple>/lib/
Bugs in pdflatex (#12804) are preventing the guide from landing (https://github.com/rust-lang/rust/pull/16657). This solves the immediate problem by changing the build system to prefer lualatex, xelatex to pdflatex (which is apparently obsolete). Because the xelatex on the snapshot bot seems to completely ignore the `-output-directory` option, I also had to frob the makefiles a bit for that case.
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.
Currently `./configure --llvm-root=...` and similar flags will break incremental builds by forcing reconfiguration on every `make`. This happens because `reconfig.mk` incorrectly treats submodules in the `-` (uninitialized) state as requiring reconfiguration, and `./configure` deliberately deinitializes unneeded submodules. The fix is to reconfigure only when submodules are in the `+` state (wrong commit checked out).
The performance hit from these checks is significant, but unoptimized
builds are already incredibly slow. Enabling these checks results in
better test coverage since there are bots doing unoptimized builds, and
the cost is relatively small in the context of an unoptimized build.
This also allows using `JEMALLOC_FLAGS` to override the default
configure flags.
When running `sudo make install`, we only want to run the actual install
as root, the building of the documentation and the distribution folder
should happen as the non-root user.
Related to #13728.
Our implementation of ebml has diverged from the standard in order
to better serve the needs of the compiler, so it doesn't make much
sense to call what we have ebml anyore. Furthermore, our implementation
is pretty crufty, and should eventually be rewritten into a format
that better suits the needs of the compiler. This patch factors out
serialize::ebml into librbml, otherwise known as the Really Bad
Markup Language. This is a stopgap library that shouldn't be used
by end users, and will eventually be replaced by something better.
[breaking-change]
Not included are two required patches:
* LLVM: segmented stack support for DragonFly [1]
* jemalloc: simple configure patches
[1]: http://reviews.llvm.org/D4705
We'll use this to run a subset of the test suite onto a dedicated
bot.
This puts the grammar tests and the pretty-printer tests under
check-secondary. It leanves the pretty tests under plain `check`
for now, until the new bot is added to take over.
Because check-secondary is not run as part of `make check` there
will be a set of tests that most users never run and are only
checked by bors. I think this will be ok because grammar tests
should rarely regress, and the people regressing such tests
should have the fortitude to deal with it.
The alignment of the line continuation backslashes is rather inconsistent. These commits solve that by removing the extra whitespace and adding a space where there previously was none. An alternative solution would be to fix the alignment.
Three small changes:
1. Re-organize headers in the Strings guide so they show up correctly.
2. build the strings guide with the other docs
3. include the strings guide in the list of guides
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]
- unicode tests live in coretest crate
- libcollections str tests need UnicodeChar trait.
- libregex perlw tests were checking a char in the Alphabetic category,
\x2161. Confirmed perl 5.18 considers this a \w character. Changed to
\x2961, which is not \w as the test expects.
This commit disables rustc's emission of rpath attributes into dynamic libraries
and executables by default. The functionality is still preserved, but it must
now be manually enabled via a `-C rpath` flag.
This involved a few changes to the local build system:
* --disable-rpath is now the default configure option
* Makefiles now prefer our own LD_LIBRARY_PATH over the user's LD_LIBRARY_PATH
in order to support building rust with rust already installed.
* The compiletest program was taught to correctly pass through the aux dir as a
component of LD_LIBRARY_PATH in more situations.
The major impact of this change is that neither rustdoc nor rustc will work
out-of-the-box in all situations because they are dynamically linked. It must be
arranged to ensure that the libraries of a rust installation are part of the
LD_LIBRARY_PATH. The default installation paths for all platforms ensure this,
but if an installation is in a nonstandard location, then configuration may be
necessary.
Additionally, for all developers of rustc, it will no longer be possible to run
$target/stageN/bin/rustc out-of-the-box. The old behavior can be regained
through the `--enable-rpath` option to the configure script.
This change brings linux/mac installations in line with windows installations
where rpath is not possible.
Closes#11747
[breaking-change]
- 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]
