`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 restores the old behaviour (as compared to building PDF versions of
all standalone docs), because some of the guides use unicode characters,
which seems to make pdftex unhappy.
parsing limitations.
Sundown parses
```
~~~
as a valid codeblock (i.e. mismatching delimiters), which made using
rustdoc on its own documentation impossible (since it used nested
codeblocks to demonstrate how testable codesnippets worked).
This modifies those snippets so that they're delimited by indentation,
but this then means they're tested by `rustdoc --test` & rendered as
Rust code (because there's no way to add `notrust` to
indentation-delimited code blocks). A comment is added to stop the
compiler reading the text too closely, but this unfortunately has to be
visible in the final docs, since that's the text on which the
highlighting happens.
E.g. this stops check-...-doc rules for `rustdoc.md` and `librustdoc`
from stamping on each other, so that they are correctly built and
tested. (Previously only the rustdoc crate was tested.)
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
This new SVH is used to uniquely identify all crates as a snapshot in time of
their ABI/API/publicly reachable state. This current calculation is just a hash
of the entire crate's AST. This is obviously incorrect, but it is currently the
reality for today.
This change threads through the new Svh structure which originates from crate
dependencies. The concept of crate id hash is preserved to provide efficient
matching on filenames for crate loading. The inspected hash once crate metadata
is opened has been changed to use the new Svh.
The goal of this hash is to identify when upstream crates have changed but
downstream crates have not been recompiled. This will prevent the def-id drift
problem where upstream crates were recompiled, thereby changing their metadata,
but downstream crates were not recompiled.
In the future this hash can be expanded to exclude contents of the AST like doc
comments, but limitations in the compiler prevent this change from being made at
this time.
Closes#10207
The compiler itself doesn't necessarily need any features of green threading
such as spawning tasks and lots of I/O, so libnative is slightly more
appropriate for rustc to use itself.
This should also help the rusti bot which is currently incompatible with libuv.
tidy has some limitations (e.g. the "checked in binaries" check doesn't
and can't actually check git), and so it's useful to run tests without
running tidy occasionally.
This trades an O(n) allocation + memcpy for a O(1) proc allocation (for
the destructor). Most users only need &[u8] anyway (all of the users in
the main repo), and so this offers large gains.
These two containers are indeed collections, so their place is in
libcollections, not in libstd. There will always be a hash map as part of the
standard distribution of Rust, but by moving it out of the standard library it
makes libstd that much more portable to more platforms and environments.
This conveniently also removes the stuttering of 'std::hashmap::HashMap',
although 'collections::HashMap' is only one character shorter.
Two optimizations:
1. Compress `foo.bc` in each rlib with `flate`. These are just taking up space and are only used with LTO, no need for LTO to be speedy.
2. Stop install `librustc.rlib` and friends, this is a *huge* source of bloat. There's no need for us to install static libraries for these components.
cc #12440
tidy has some limitations (e.g. the "checked in binaries" check doesn't
and can't actually check git), and so it's useful to run tests without
running tidy occasionally.
You rarely want to statically link against librustc and friends, so there's no
real reason to install the rlib version of these libraries, especially because
the rlibs are massive.
LLVM's tools are not contained in the local directory if --llvm-root is used by
the ./configure script. This fixes the installation path to be the root provided
by --llvm-root.
The new methodology can be found in the re-worded comment, but the gist of it is
that -C prefer-dynamic doesn't turn off static linkage. The error messages
should also be a little more sane now.
Closes#12133
The new methodology can be found in the re-worded comment, but the gist of it is
that -C prefer-dynamic doesn't turn off static linkage. The error messages
should also be a little more sane now.
Closes#12133
Work toward #9876.
This adds `prepare.mk`, which is simply a more heavily-parameterized `install.mk`, then uses `prepare` to implement both `install` and the windows installer (`dist`). Smoke tested on both Linux and Windows.
Because the build system treats Makefile.in and the .mk files slightly
differently (.in is copied, .mk are included), this makes the system
more uniform. Fewer build system changes will require a complete
reconfigure.
Currently when you run `make -jN` it's likely that you'll remove compiler-rt and
then it won't get cp'd back into the right place. I believe the reason for this
is that the compiler-rt library target never got updated so make decided it
never needed to copy the files back into place. The files were all there at the
beginning of `make`, but then we may clean out the stage0 versions if we unzip
the snapshot again.
Includes an upstream commit by pcwalton to improve codegen of our enums getting
moved around.
This also introduces a new commit on top of our stack of patches to fix a mingw32 build issue. I have submitted the patch upstream: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140210/204653.html
I verified that this builds on the try bots, which amazes me because I think that c++11 is turned on now, but I guess we're still lucky!
Closes#10613 (pcwalton's patch landed)
Closes#11992 (llvm has removed these options)
Two unfortunate allocations were wrapping a proc() in a proc() with
GreenTask::build_start_wrapper, and then boxing this proc in a ~proc() inside of
Context::new(). Both of these allocations were a direct result from two
conditions:
1. The Context::new() function has a nice api of taking a procedure argument to
start up a new context with. This inherently required an allocation by
build_start_wrapper because extra code needed to be run around the edges of a
user-provided proc() for a new task.
2. The initial bootstrap code only understood how to pass one argument to the
next function. By modifying the assembly and entry points to understand more
than one argument, more information is passed through in registers instead of
allocating a pointer-sized context.
This is sadly where I end up throwing mips under a bus because I have no idea
what's going on in the mips context switching code and don't know how to modify
it.
Closes#7767
cc #11389
Previously crates like `green` and `native` would still depend on their
parents when running `make check-stage2-green NO_REBUILD=1`, this
ensures that they only depend on their source files.
Also, apply NO_REBUILD to the crate doc tests, so, for example,
`check-stage2-doc-std` will use an already compiled `rustdoc` directly.
These are ancient. I removed a bunch of questions that are less relevant - or completely unrelevant, updated other entries, and removed things that are already better expressed elsewhere.
libextra is currently being split into several crates. This commit adds
them all to the dist target in order to have them in the final tarballs.
Signed-off-by: Luca Bruno <lucab@debian.org>
src/README.txt has been renamed in a30d61b05a, make dist is
thus failing as unable to find it.
This commit makes the dist target working again.
Signed-off-by: Luca Bruno <lucab@debian.org>
Part of #8784
Changes:
- Everything labeled under collections in libextra has been moved into a new crate 'libcollection'.
- Renamed container.rs to deque.rs, since it was no longer 'container traits for extra', just a deque trait.
- Crates that depend on the collections have been updated and dependencies sorted.
- I think I changed all the imports in the tests to make sure it works. I'm not entirely sure, as near the end of the tests there was yet another `use` that I forgot to change, and when I went to try again, it started rebuilding everything, which I don't currently have time for.
There will probably be incompatibility between this and the other pull requests that are splitting up libextra. I'm happy to rebase once those have been merged.
The tests I didn't get to run should pass. But I can redo them another time if they don't.
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes#9795Closes#8968
This has been a long time coming. Conditions in rust were initially envisioned
as being a good alternative to error code return pattern. The idea is that all
errors are fatal-by-default, and you can opt-in to handling the error by
registering an error handler.
While sounding nice, conditions ended up having some unforseen shortcomings:
* Actually handling an error has some very awkward syntax:
let mut result = None;
let mut answer = None;
io::io_error::cond.trap(|e| { result = Some(e) }).inside(|| {
answer = Some(some_io_operation());
});
match result {
Some(err) => { /* hit an I/O error */ }
None => {
let answer = answer.unwrap();
/* deal with the result of I/O */
}
}
This pattern can certainly use functions like io::result, but at its core
actually handling conditions is fairly difficult
* The "zero value" of a function is often confusing. One of the main ideas
behind using conditions was to change the signature of I/O functions. Instead
of read_be_u32() returning a result, it returned a u32. Errors were notified
via a condition, and if you caught the condition you understood that the "zero
value" returned is actually a garbage value. These zero values are often
difficult to understand, however.
One case of this is the read_bytes() function. The function takes an integer
length of the amount of bytes to read, and returns an array of that size. The
array may actually be shorter, however, if an error occurred.
Another case is fs::stat(). The theoretical "zero value" is a blank stat
struct, but it's a little awkward to create and return a zero'd out stat
struct on a call to stat().
In general, the return value of functions that can raise error are much more
natural when using a Result as opposed to an always-usable zero-value.
* Conditions impose a necessary runtime requirement on *all* I/O. In theory I/O
is as simple as calling read() and write(), but using conditions imposed the
restriction that a rust local task was required if you wanted to catch errors
with I/O. While certainly an surmountable difficulty, this was always a bit of
a thorn in the side of conditions.
* Functions raising conditions are not always clear that they are raising
conditions. This suffers a similar problem to exceptions where you don't
actually know whether a function raises a condition or not. The documentation
likely explains, but if someone retroactively adds a condition to a function
there's nothing forcing upstream users to acknowledge a new point of task
failure.
* Libaries using I/O are not guaranteed to correctly raise on conditions when an
error occurs. In developing various I/O libraries, it's much easier to just
return `None` from a read rather than raising an error. The silent contract of
"don't raise on EOF" was a little difficult to understand and threw a wrench
into the answer of the question "when do I raise a condition?"
Many of these difficulties can be overcome through documentation, examples, and
general practice. In the end, all of these difficulties added together ended up
being too overwhelming and improving various aspects didn't end up helping that
much.
A result-based I/O error handling strategy also has shortcomings, but the
cognitive burden is much smaller. The tooling necessary to make this strategy as
usable as conditions were is much smaller than the tooling necessary for
conditions.
Perhaps conditions may manifest themselves as a future entity, but for now
we're going to remove them from the standard library.
Closes#9795Closes#8968
This commit removes the -c, --emit-llvm, -s, --rlib, --dylib, --staticlib,
--lib, and --bin flags from rustc, adding the following flags:
* --emit=[asm,ir,bc,obj,link]
* --crate-type=[dylib,rlib,staticlib,bin,lib]
The -o option has also been redefined to be used for *all* flavors of outputs.
This means that we no longer ignore it for libraries. The --out-dir remains the
same as before.
The new logic for files that rustc emits is as follows:
1. Output types are dictated by the --emit flag. The default value is
--emit=link, and this option can be passed multiple times and have all options
stacked on one another.
2. Crate types are dictated by the --crate-type flag and the #[crate_type]
attribute. The flags can be passed many times and stack with the crate
attribute.
3. If the -o flag is specified, and only one output type is specified, the
output will be emitted at this location. If more than one output type is
specified, then the filename of -o is ignored, and all output goes in the
directory that -o specifies. The -o option always ignores the --out-dir
option.
4. If the --out-dir flag is specified, all output goes in this directory.
5. If -o and --out-dir are both not present, all output goes in the directory of
the crate file.
6. When multiple output types are specified, the filestem of all output is the
same as the name of the CrateId (derived from a crate attribute or from the
filestem of the crate file).
Closes#7791Closes#11056Closes#11667
This commit removes the -c, --emit-llvm, -s, --rlib, --dylib, --staticlib,
--lib, and --bin flags from rustc, adding the following flags:
* --emit=[asm,ir,bc,obj,link]
* --crate-type=[dylib,rlib,staticlib,bin,lib]
The -o option has also been redefined to be used for *all* flavors of outputs.
This means that we no longer ignore it for libraries. The --out-dir remains the
same as before.
The new logic for files that rustc emits is as follows:
1. Output types are dictated by the --emit flag. The default value is
--emit=link, and this option can be passed multiple times and have all
options stacked on one another.
2. Crate types are dictated by the --crate-type flag and the #[crate_type]
attribute. The flags can be passed many times and stack with the crate
attribute.
3. If the -o flag is specified, and only one output type is specified, the
output will be emitted at this location. If more than one output type is
specified, then the filename of -o is ignored, and all output goes in the
directory that -o specifies. The -o option always ignores the --out-dir
option.
4. If the --out-dir flag is specified, all output goes in this directory.
5. If -o and --out-dir are both not present, all output goes in the current
directory of the process.
6. When multiple output types are specified, the filestem of all output is the
same as the name of the CrateId (derived from a crate attribute or from the
filestem of the crate file).
Closes#7791Closes#11056Closes#11667
- `extra::json` didn't make the cut, because of `extra::json` required
dep on `extra::TreeMap`. If/when `extra::TreeMap` moves out of `extra`,
then `extra::json` could move into `serialize`
- `libextra`, `libsyntax` and `librustc` depend on the newly created
`libserialize`
- The extensions to various `extra` types like `DList`, `RingBuf`, `TreeMap`
and `TreeSet` for `Encodable`/`Decodable` were moved into the respective
modules in `extra`
- There is some trickery, evident in `src/libextra/lib.rs` where a stub
of `extra::serialize` is set up (in `src/libextra/serialize.rs`) for
use in the stage0 build, where the snapshot rustc is still making
deriving for `Encodable` and `Decodable` point at extra. Big props to
@huonw for help working out the re-export solution for this
extra: inline extra::serialize stub
fix stuff clobbered in rebase + don't reexport serialize::serialize
no more globs in libserialize
syntax: fix import of libserialize traits
librustc: fix bad imports in encoder/decoder
add serialize dep to librustdoc
fix failing run-pass tests w/ serialize dep
adjust uuid dep
more rebase de-clobbering for libserialize
fixing tests, pushing libextra dep into cfg(test)
fix doc code in extra::json
adjust index.md links to serialize and uuid library
Previously, the check-fast and check-lite test suites weren't picking up all
target crates, rather just std/extra. In order to ensure that all of our crates
work on windows, I've modified these rules to build the test suites for all
TARGET_CRATES members. Note that this still excludes rustc/syntax/rustdoc.
In line with the dissolution of libextra - #8784 - this moves arena and glob into
their own respective modules. Updates .gitignore with the entries
doc/{arena,glob} in accordance.
This changes android testing to upload *all* target crates rather than just a
select subset. This should unblock #11867 which is introducing a libglob
dependency in testing.
This changes android testing to upload *all* target crates rather than just a
select subset. This should unblock #11867 which is introducing a libglob
dependency in testing.
In line with the dissolution of libextra - #8784 - moves arena to its own library libarena.
Changes based on PR #11787. Updates .gitignore to ignore doc/arena.
It was decided a long, long time ago that libextra should not exist, but rather its modules should be split out into smaller independent libraries maintained outside of the compiler itself. The theory was to use `rustpkg` to manage dependencies in order to move everything out of the compiler, but maintain an ease of usability.
Sadly, the work on `rustpkg` isn't making progress as quickly as expected, but the need for dissolving libextra is becoming more and more pressing. Because of this, we've thought that a good interim solution would be to simply package more libraries with the rust distribution itself. Instead of dissolving libextra into libraries outside of the mozilla/rust repo, we can dissolve libraries into the mozilla/rust repo for now.
Work on this has been excruciatingly painful in the past because the makefiles are completely opaque to all but a few. Adding a new library involved adding about 100 lines spread out across 8 files (incredibly error prone). The first commit of this pull request targets this pain point. It does not rewrite the build system, but rather refactors large portions of it. Afterwards, adding a new library is as simple as modifying 2 lines (easy, right?). The build system automatically keeps track of dependencies between crates (rust *and* native), promotes binaries between stages, tracks dependencies of installed tools, etc, etc.
With this newfound buildsystem power, I chose the `extra::flate` module as the first candidate for removal from libextra. While a small module, this module is relative complex in that is has a C dependency and the compiler requires it (messing with the dependency graph a bit). Albeit I modified more than 2 lines of makefiles to accomodate libflate (the native dependency required 2 extra lines of modifications), but the removal process was easy to do and straightforward.
---
Testing-wise, I've cross-compiled, run tests, built some docs, installed, uninstalled, etc. I'm still working out a few kinks, and I'm sure that there's gonna be built system issues after this, but it should be working well for basic use!
cc #8784
This is hopefully the beginning of the long-awaited dissolution of libextra.
Using the newly created build infrastructure for building libraries, I decided
to move the first module out of libextra.
While not being a particularly meaty module in and of itself, the flate module
is required by rustc and additionally has a native C dependency. I was able to
very easily split out the C dependency from rustrt, update librustc, and
magically everything gets installed to the right locations and built
automatically.
This is meant to be a proof-of-concept commit to how easy it is to remove
modules from libextra now. I didn't put any effort into modernizing the
interface of libflate or updating it other than to remove the one glob import it
had.
Before this patch, if you wanted to add a crate to the build system you had to
change about 100 lines across 8 separate makefiles. This is highly error prone
and opaque to all but a few. This refactoring is targeted at consolidating this
effort so adding a new crate adds one line in one file in a way that everyone
can understand it.
The new macro loading infrastructure needs the ability to force a
procedural-macro crate to be built with the host architecture rather than the
target architecture (because the compiler is just about to dlopen it).
The official documentation sorely needs an explanation of the rust runtime and what it is exactly, and I want this guide to provide that information.
I'm unsure of whether I've been too light on some topics while too heavy on others. I also feel like a few things are still missing. As always, feedback is appreciated, especially about things you'd like to see written about!
If we bootstrap a cross compile from a stage1 compiler, then the stage1 compiler
already knows about the rustc => rustlib change, so we need to not add the extra
flag if it's a stage0 version of a target from a stage1 of another target.
If we bootstrap a cross compile from a stage1 compiler, then the stage1 compiler
already knows about the rustc => rustlib change, so we need to not add the extra
flag if it's a stage0 version of a target from a stage1 of another target.
This reorganizes the documentation index to be more focused on the in-tree docs, and to clean up the style, and it also adds @steveklabnik's pointer guide.
All the copying of files amongst one another was apparently causing something to
get corrupted. Instead of having files fly around, just update the directories
to link to.
The makefiles and the windows installer disagree on the name of this file. In practical terms this change only means that the '-pre' installers will be named 'rust-0.9-pre-install.exe' instead 'rust-0.9-install.exe'.
This is not done yet but I'm posting it to get feedback.
The wiki has a ton of different tutorials/manuals/faq and so forth. Instead of migrating all of them right now, I just migrated the following:
* The general main wiki page
* Language FAQ
* Project FAQ
If this feels reasonable, please comment so that I can continue with confidence.
Ensure configure creates doc/guides directory
Fix configure makefile and tests
Remove old guides dir and configure option, convert testing to guide
Remove ignored files
Fix submodule issue
prepend dir in makefile so that bor knows how to build the docs
S to uppercase
In a multi-host build the mklldeps.py tool is getting called before
all the llvm-configs are built. I am not actually sure the cause. I
had convinced myself that DEF_LLVM_RULES needed to be called before
the llvmdeps.rs rule, but now looking at it again I can't see why.
This pull request extracts all scheduling functionality from libstd, moving it into its own separate crates. The new libnative and libgreen will be the new way in which 1:1 and M:N scheduling is implemented. The standard library still requires an interface to the runtime, however, (think of things like `std::comm` and `io::println`). The interface is now defined by the `Runtime` trait inside of `std::rt`.
The booting process is now that libgreen defines the start lang-item and that's it. I want to extend this soon to have libnative also have a "start lang item" but also allow libgreen and libnative to be linked together in the same process. For now though, only libgreen can be used to start a program (unless you define the start lang item yourself). Again though, I want to change this soon, I just figured that this pull request is large enough as-is.
This certainly wasn't a smooth transition, certain functionality has no equivalent in this new separation, and some functionality is now better enabled through this new system. I did my best to separate all of the commits by topic and keep things fairly bite-sized, although are indeed larger than others.
As a note, this is currently rebased on top of my `std::comm` rewrite (or at least an old copy of it), but none of those commits need reviewing (that will all happen in another pull request).
It only really makes sense to run tests for the build target anyway because it's
not guaranteed that you can execute other targets.
This is blocking the next snapshot
The rmake tests should depend on the target libraries (for linking), not just
the host libraries (for running). The host file dependencies are also correct
now because HLIBRUSTC_DEFAULT doesn't actually exist.
Note that this removes a number of run-pass tests which are exercising behavior
of the old runtime. This functionality no longer exists and is thoroughly tested
inside of libgreen and libnative. There isn't really the notion of "starting the
runtime" any more. The major notion now is "bootstrapping the initial task".
Turns out libuv's build system doesn't like us telling them that the build
directory is a relative location, as it always spits out a warning about a
circular dependency being dropped. By using an absolute path, turns out the
warnings isn't spit out, who knew?
Closes#11067
Turns out libuv's build system doesn't like us telling them that the build
directory is a relative location, as it always spits out a warning about a
circular dependency being dropped. By using an absolute path, turns out the
warnings isn't spit out, who knew?
Closes#11067
rustdoc:
- fix search-bar layout
doc: CSS:
- switch to native pandoc toc depth
- rm some dead code
- clamp width to be readable (we're not Wikipedia!)
- don't background-color titles, it's bloating
- make syntax-highlighting colors inline with rust-lang.org
- space indents
@alexcrichton
This replaces the link meta attributes with a pkgid attribute and uses a hash
of this as the crate hash. This makes the crate hash computable by things
other than the Rust compiler. It also switches the hash function ot SHA1 since
that is much more likely to be available in shell, Python, etc than SipHash.
Fixes#10188, #8523.
Right now multiple targets/hosts is broken because the libdir passed for all of
the LLVM libraries is for the wrong architecture. By using the right arch
(target, not host), everything is linked and assembled just fine.
In order to keep up to date with changes to the libraries that `llvm-config`
spits out, the dependencies to the LLVM are a dynamically generated rust file.
This file is now automatically updated whenever LLVM is updated to get kept
up-to-date.
At the same time, this cleans out some old cruft which isn't necessary in the
makefiles in terms of dependencies.
Closes#10745Closes#10744
The main one removed is rust_upcall_reset_stack_limit (continuation of #10156),
and this also removes the upcall_trace function. The was hidden behind a
`-Z trace` flag, but if you attempt to use this now you'll get a linker error
because there is no implementation of the 'upcall_trace' function. Due to this
no longer working, I decided to remove it entirely from the compiler (I'm also a
little unsure on what it did in the first place).
Turns out that we only want to install the target rlibs, not the host rlibs.
I had it backwards the first time, then mixed up the second time, but this time
should get it right.
There's no need for host rlib files because none of them are needed at runtime.
CFG_BUILD_DIR, CFG_LLVM_SRC_DIR and CFG_SRC_DIR all have trailing
slashes, by definition, so this is correct.
(This is purely cosmetic; the doubled slash is ignored by all the tools we're using.)
This infrastructure is meant to support runnings tests that involve various
interesting interdependencies about the types of crates being linked or possibly
interacting with C libraries. The goal of these make tests is to not restrict
them to a particular test runner, but allow each test to run its own tests.
To this end, there is a new src/test/run-make directory which has sub-folders of
tests. Each test requires a `Makefile`, and running the tests constitues simply
running `make` inside the directory. The new target is `check-stageN-rmake`.
These tests will have the destination directory (as TMPDIR) and the local rust
compiler (as RUSTC) passed along to them. There is also some helpful
cross-platform utilities included in src/test/run-make/tools.mk to aid with
compiling C programs and running them.
The impetus for adding this new test suite is to allow various interesting forms
of testing rust linkage. All of the tests initially added are various flavors of
compiling Rust and C with one another as well as just making sure that rust
linkage works in general.
Closes#10434
This commit alters the build process of the compiler to build a static
librustrt.a instead of a dynamic version. This means that we can stop
distributing librustrt as well as default linking against it in the compiler.
This also means that if you attempt to build rust code without libstd, it will
no longer work if there are any landing pads in play. The reason for this is
that LLVM and rustc will emit calls to the various upcalls in librustrt used to
manage exception handling. In theory we could split librustrt into librustrt and
librustupcall. We would then distribute librustupcall and link to it for all
programs using landing pads, but I would rather see just one librustrt artifact
and simplify the build process.
The major benefit of doing this is that building a static rust library for use
in embedded situations all of a sudden just became a whole lot more feasible.
Closes#3361
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes#552
Explicitly have the only C++ portion of the runtime be one file with exception
handling. All other runtime files must now live in C and be fully defined in C.
Largely, this is just being more specific about where tags get searched
for to remove external dependencies like src/llvm, which reduces the
number of tags *enormously* and significantly increases the usefulness
of the tags file as it is then focusing on 240K lines of Rust code
and 4.5K of C++ rather than just shy of 1M lines of C++ code (mostly
from LLVM) and another 100K lines of Rust tests and a diverse collection
of other languages.
src/rustllvm/RustWrapper.cpp and src/rustllvm/PassWrapper.cpp are
getting tags made, but I'm not sure if that's desirable or not. At
worst, it's not a significant wrong.
A future, desirable step is producing tags for just libstd and libextra
for the use of people using Rust-the-language rather than working on
Rust itself.
Since tutorial/manual files are stored on static.rust-lang.org, browsers
try to fetch the favicon from there while it should be retrieved from the
main domain.
Added two new rules to create epubs out of the tutorial and reference manual source files. This is useful and doesn't add any new dependencies to the build process.
- remove /usr/include from the include path since the iOS SDK provides the correct version
- `_NSGetEnviron()` is private and not available on iOS
- `.align` without an argument is not allowed with the Apple tools. 2^2 should be the default alignment
- ignore error messages for XCode < 5
- pass include path to libuv
This binds to the appropriate pthreads_* and Windows specific functions
and calls them from Rust. This allows for removal of the C++ support
code for threads.
Fixes#10162
This commit moves all thread-blocking I/O functions from the std::os module.
Their replacements can be found in either std::rt::io::file or in a hidden
"old_os" module inside of native::file. I didn't want to outright delete these
functions because they have a lot of special casing learned over time for each
OS/platform, and I imagine that these will someday get integrated into a
blocking implementation of IoFactory. For now, they're moved to a private module
to prevent bitrot and still have tests to ensure that they work.
I've also expanded the extensions to a few more methods defined on Path, most of
which were previously defined in std::os but now have non-thread-blocking
implementations as part of using the current IoFactory.
The api of io::file is in flux, but I plan on changing it in the next commit as
well.
Closes#10057
Pandoc can create epub verions of the markdown files. Since the docs
are lengthy, epubs are handy to have around. Two rules to create epub
versions of the reference manual and the main tutorial are added here.
Signed-off-by: Noufal Ibrahim <noufal@nibrahim.net.in>
New standards have arisen in recent months, mostly for the use of
rustpkg, but the main Rust codebase has not been altered to match these
new specifications. This changeset rectifies most of these issues.
- Renamed the crate source files `src/libX/X.rs` to `lib.rs`, for
consistency with current styles; this affects extra, rustc, rustdoc,
rustpkg, rustuv, std, syntax.
- Renamed `X/X.rs` to `X/mod.rs,` as is now recommended style, for
`std::num` and `std::terminfo`.
- Shifted `src/libstd/str/ascii.rs` out of the otherwise unused `str`
directory, to be consistent with its import path of `std::ascii`;
libstd is flat at present so it's more appropriate thus.
While this removes some `#[path = "..."]` directives, it does not remove
all of them, and leaves certain other inconsistencies, such as `std::u8`
et al. which are actually stored in `src/libstd/num/` (one subdirectory
down). No quorum has been reached on this issue, so I felt it best to
leave them all alone at present. #9208 deals with the possibility of
making libstd more hierarchical (such as changing the crate to match the
current filesystem structure, which would make the module path
`std::num::u8`).
There is one thing remaining in which this repository is not
rustpkg-compliant: rustpkg would have `src/std/` et al. rather than
`src/libstd/` et al. I have not endeavoured to change that at this point
as it would guarantee prompt bitrot and confusion. A change of that
magnitude needs to be discussed first.
This commit removes the propagation of `link_args` attributes across crates. The first commit message has the reasons as to why. Additionally, this starts statically linking some C/C++ helper libraries that we have to their respective crates instead of throwing then in librustrt and then having everything depend on librustrt.
The major downside of this movement is that we're losing the ability to control visible symbols. I couldn't figure out a way to internalize symbols from a static library during the linking process, so everyone who links to librustdoc will be able to use its sundown implementation (not exactly ideal). I'm not entirely sure how to fix this (beyond generating a list of all public symbols, including rust ones, and passing that to the linker), but we may have a much easier time with this once we start using llvm's linker toolchain.
There's certainly a lot more possibilities in where this can go, but I didn't want to go too deep just yet. The main idea here is to stop propagating linker arguments and then see how we're able to start statically linking libraries as a result.
r? @catamorphism, you're going to be working on linking soon, so feel free to completely throw this away for something else!
Similarly to the previous commit, libuv is only used by this library, so there's
no need for it to be linked into librustrt and available to all crates by
default.
Previously we were actually overwriting `CFG_{HOST,TARGET,BUILD}` with `CFG_{HOST,TARGET,BUILD}_TRIPLE(S)` since configure tested for the legacy one by checking if it was empty which would never be the case. That meant it wouldn't split up multiple triples and just treat it as one long triple.
This pull also fixes the rules that were changed when librustuv was added to use the right CFG_ vars and removes the legacy flags.
Allows an enum with a discriminant to use any of the primitive integer types to store it. By default the smallest usable type is chosen, but this can be overridden with an attribute: `#[repr(int)]` etc., or `#[repr(C)]` to match the target's C ABI for the equivalent C enum.
Also adds a lint pass for using non-FFI safe enums in extern declarations, checks that specified discriminants can be stored in the specified type if any, and fixes assorted code that was assuming int.
The actual fix would be to make rustpkg use `rustc::monitor` so it picks
up anything special that rustc needs, but for now let's keep the tests
from breaking.
There are a few reasons that this is a desirable move to take:
1. Proof of concept that a third party event loop is possible
2. Clear separation of responsibility between rt::io and the uv-backend
3. Enforce in the future that the event loop is "pluggable" and replacable
Here's a quick summary of the points of this pull request which make this
possible:
* Two new lang items were introduced: event_loop, and event_loop_factory.
The idea of a "factory" is to define a function which can be called with no
arguments and will return the new event loop as a trait object. This factory
is emitted to the crate map when building an executable. The factory doesn't
have to exist, and when it doesn't then an empty slot is in the crate map and
a basic event loop with no I/O support is provided to the runtime.
* When building an executable, then the rustuv crate will be linked by default
(providing a default implementation of the event loop) via a similar method to
injecting a dependency on libstd. This is currently the only location where
the rustuv crate is ever linked.
* There is a new #[no_uv] attribute (implied by #[no_std]) which denies
implicitly linking to rustuv by default
Closes#5019
This drops more of the old C++ runtime to rather be written in rust. A few
features were lost along the way, but hopefully not too many. The main loss is
that there are no longer backtraces associated with allocations (rust doesn't
have a way of acquiring those just yet). Other than that though, I believe that
the rest of the debugging utilities made their way over into rust.
Closes#8704
This drops more of the old C++ runtime to rather be written in rust. A few
features were lost along the way, but hopefully not too many. The main loss is
that there are no longer backtraces associated with allocations (rust doesn't
have a way of acquiring those just yet). Other than that though, I believe that
the rest of the debugging utilities made their way over into rust.
Closes#8704
api::install_pkg now accepts an argument that's a list of
(kind, path) dependency pairs. This allows custom package scripts to
declare C dependencies, as is demonstrated in
rustpkg::tests::test_c_dependency_ok.
Closes#6403
OS X 10.9's linker has a bug that results in it failing to preserve
DWARF unwind information when passed the -no_compact_unwind flag.
This flag is passed on OS X because the unwind information for
__morestack cannot be represented by the compact unwind format.
We can work around this problem by using a more targeted approach
to disabling compact unwind information. The OS X linker looks for
a particular pattern in the DWARF unwind information and will not
attempt to convert the unwind information to the compact format.
The pattern in question is the return address register being saved
twice to the same location.
Fixes#6849.
OS X 10.9's linker has a bug that results in it failing to preserve
DWARF unwind information when passed the -no_compact_unwind flag.
This flag is passed on OS X because the unwind information for
__morestack cannot be represented by the compact unwind format.
We can work around this problem by using a more targeted approach
to disabling compact unwind information. The OS X linker looks for
a particular pattern in the DWARF unwind information and will not
attempt to convert the unwind information to the compact format.
The pattern in question is the return address register being saved
twice to the same location.
Fixes#6849.
It seems like rusti has been removed, except for one reference in one Makefile. This reference breaks building rust on my computer because the "all-target" rule has rusti as a target.
~~~~
make: *** No rule to make target `x86_64-unknown-linux-gnu/stage2/bin/rusti', needed by `all-target-x86_64-unknown-linux-gnu-host-x86_64-unknown-linux-gnu'. Stop.
~~~~
Removing this line fixes things for me.
This commit re-introduces the functionality of __morestack in a way that it was
not originally anticipated. Rust does not currently have segmented stacks,
rather just large stack segments. We do not detect when these stack segments are
overrun currently, but this commit leverages __morestack in order to check this.
This commit purges a lot of the old __morestack and stack limit C++
functionality, migrating the necessary chunks to rust. The stack limit is now
entirely maintained in rust, and the "main logic bits" of __morestack are now
also implemented in rust as well.
I put my best effort into validating that this currently builds and runs successfully on osx and linux 32/64 bit, but I was unable to get this working on windows. We never did have unwinding through __morestack frames, and although I tried poking at it for a bit, I was unable to understand why we don't get unwinding right now.
A focus of this commit is to implement as much of the logic in rust as possible. This involved some liberal usage of `no_split_stack` in various locations, along with some use of the `asm!` macro (scary). I modified a bit of C++ to stop calling `record_sp_limit` because this is no longer defined in C++, rather in rust.
Another consequence of this commit is that `thread_local_storage::{get, set}` must both be flagged with `#[rust_stack]`. I've briefly looked at the implementations on osx/linux/windows to ensure that they're pretty small stacks, and I'm pretty sure that they're definitely less than 20K stacks, so we probably don't have a lot to worry about.
Other things worthy of note:
* The default stack size is now 4MB instead of 2MB. This is so that when we request 2MB to call a C function you don't immediately overflow because you have consumed any stack at all.
* `asm!` is actually pretty cool, maybe we could actually define context switching with it?
* I wanted to add links to the internet about all this jazz of storing information in TLS, but I was only able to find a link for the windows implementation. Otherwise my suggestion is just "disassemble on that arch and see what happens"
* I put my best effort forward on arm/mips to tweak __morestack correctly, we have no ability to test this so an extra set of eyes would be useful on these spots.
* This is all really tricky stuff, so I tried to put as many comments as I thought were necessary, but if anything is still unclear (or I completely forgot to take something into account), I'm willing to write more!
This commit resumes management of the stack boundaries and limits when switching
between tasks. This additionally leverages the __morestack function to run code
on "stack overflow". The current behavior is to abort the process, but this is
probably not the best behavior in the long term (for deails, see the comment I
wrote up in the stack exhaustion routine).
As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
Closes#9925
Sadly, there's a lack of resources for maintaining the `rust` tool,
and we decided in the 2013-10-08 Rust team meeting that it's better
to remove it altogether than to leave it in a broken state.
This deletion is without prejudice. If a person or people appear who
would like to maintain the tool, we will probably be happy to
resurrect it!
Closes#9775
This lets the C++ code in the rt handle the (slightly) tricky parts of
random number generation: e.g. error detection/handling, and using the
values of the `#define`d options to the various functions.
This will make sure that system files that rust binaries depend on in Windows get packaged into stage0 snapshots as well as into Windows installer.
Currently these include `libgcc_s_dw2-1.dll`, `libstdc++-6.dll` and `libpthread-2.dll`. Note that the latter will need to be changed to `pthreadGC2.dll` once Windows build bots get upgraded to mingw 4.0
Closes#9252Closes#5878Closes#9218Closes#5712
This change adds --soft-float option for generating
software floating point library calls.
It also implies using soft float ABI, that is the same as llc.
It is useful for targets that have no FPU.
This modifies the command-line usage of rustdoc to intake its own JSON output as
well as a rust source file. This also alters the command line from
`rustdoc input file` to `rustdoc file` with the input/output formats specified
as -r and -w, respectively.
When using a JSON input, no passes or plugins are re-run over the json, instead
the output is generated directly from the JSON that was provided. Passes and
plugins are still run on rust source input, however.
This change adds -Z soft-float option for generating
software floating point library calls.
It also implies using soft float ABI, that is the same as llc.
It is useful for targets that have no FPU.
They're getting smaller each time though!
The highlight of this round is source files in documentation. Still trying to figure out the best syntax-highlighting solution.
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
Three things in this commit:
1. Actually build the rustpkg tutorial. I didn't know I needed this when
I first wrote it.
2. Link to it rather than the manual from the
tutorial.
3. Update the headers: most of them were one level too deeply
nested.
Removes old rustdoc, moves rustdoc_ng into its place instead (plus drops the _ng
suffix). Also shreds all reference to rustdoc_ng from the Makefile rules.
This large commit implements and `html` output option for rustdoc_ng. The
executable has been altered to be invoked as "rustdoc_ng html <crate>" and
it will dump everything into the local "doc" directory. JSON can still be
generated by changing 'html' to 'json'.
This also fixes a number of bugs in rustdoc_ng relating to comment stripping,
along with some other various issues that I found along the way.
The `make doc` command has been altered to generate the new documentation into
the `doc/ng/$(CRATE)` directories.
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
Because less C++ is better C++!
Some of the functions could be converted to rust, but the functions dealing with
signals were moved to rust_builtin.cpp instead (no reason to keep the original
file around for one function).
Closes#2674
This patch fixes some errors of MIPS target, however, MIPS C ABI is still broken. I will send another PR to fix the problem.
Because MIPS target has no "generic" CPU name, I add --target-cpu and --target-feature to RUST_FLAGS. In order to workaround the "compact frame descriptions incompatible with DWARF2 .eh_frame" problem, the linker I used is CXX but not CC.
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
Note that some `rustdoc_ng` tests were removed, but @cmr says they weren't supposed to be there in the first place. The rustdoc_ng code should also be included in `make install` and `make dist` now.
This works by adding this directory to GCC include search path before mingw system headers directories,
so we can intercept their inclusions and add missing definitions without having to modify files in mingw/include.
Now rustdoc_ng will be built as both a binary and a library (using the same
rules as all the other binaries that rust has). Furthermore, this will also
start building rustdoc_ng unit tests (and running them).
This is a reopening of the libuv-upgrade part of #8645. Hopefully this won't
cause random segfaults all over the place. The windows regression in testing
should also be fixed (it shouldn't build the whole compiler twice).
A notable difference from before is that gyp is now a git submodule instead of
always git-cloned at make time. This allows bundling for releases more easily.
Closes#8850
The new glob tests created tmp/glob-tests as a directory, but the never removed
it. The `make clean` target then attempted to `rm -f` on this, but it couldn't
remove the directory. This both changes the clean target to `rm -rf` tmp files,
and also alters the tests to delete the directory that all the files are added
into.
This should make benchmarks easier to understand. But, it doesn't work.
BENCH_RS in mk/tests.mk has everything, from what I can tell in remake, but
only those that are direct children of src/test/bench get build and run.
@graydon, can you lend your expertise? I can't make heads or tails of this
makefile.
It turns out that gyp (libuv's new build system) wants x64 for a 64-bit x86
architecture and ia32 for a 32-bit architecture, so this performs the relevant
mapping and then invokes libuv's configure script with the appropriate target
architecture.
This can be verified by running make with VERBOSE=1 and seeing that beforehand
on a 64-bit build libuv was passed "-arch i386" and now it's passed
"-arch x86_64"
Closes#8826
The syntax of the script requires python < 3, and so does our build system so we
can just use CFG_PYTHON to run the script. This prevents build failures where
`python` is actually python3 or later.
There were two main differences with the old libuv and the master version:
1. The uv_last_error function is now gone. The error code returned by each
function is the "last error" so now a UvError is just a wrapper around a
c_int.
2. The repo no longer includes a makefile, and the build system has change.
According to the build directions on joyent/libuv, this now downloads a `gyp`
program into the `libuv/build` directory and builds using that. This
shouldn't add any dependences on autotools or anything like that.
Closes#8407Closes#6567Closes#6315
This makes it relatively easy for us to split testsuite load between machines in buildbot. I've added buildbot-side support for setting up builders with -a.b suffixes (eg. linux-64-opt-vg-0.5, linux-64-opt-vg-1.5, linux-64-opt-vg-2.5, linux-64-opt-vg-3.5, linux-64-opt-vg-4.5 causes the valgrind-supervised testsuite to split 5 ways across hosts).
We currently have no need for the frame pointers on any platform. They
may eventually be needed on platforms without an equivalent to the DWARF
call frame information to walk the stack in the garbage collector.
Closes#7477
`stdtest` and `extratest` expects to be able to write to `tmp` directory under the current working directory, so the first commit creates `tmp` directory and changes the directory before running tests.
The second commit adds `--bench` argument to test runs and copies metrics from the remote device.
r? @graydon Also, notably, make rustpkgtest depend on the rustpkg executable (otherwise, tests that shell out to rustpgk might run when rustpkg doesn't exist).
Get rid of special cases for names beginning with "rust-" or
containing hyphens, and just store a Path in a package ID. The Rust-identifier
for the crate is none of rustpkg's business.
This commit allows you to write:
extern mod x = "a/b/c";
which means rustc will search in the RUST_PATH for a package with
ID a/b/c, and bind it to the name `x` if it's found.
Incidentally, move get_relative_to from back::rpath into std::path
r? anyone
Fix#8057
This commit fixes some oversights in the Makefile where rustc could be
invoked without some of its dependencies yet in place. (I encountered
the problem in practice; its not just theoretical.)
As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one
writes an invocation of rustc where $(1) is the stage number $(2) is
the target triple $(3) is the host triple. (Other uses of the macro
may plug in actual values or different parameters in for those three
formal parameters.)
When you have invocations of $(STAGE...), you need to make sure that
its dependences are satisfied; otherwise, if someone is using `make
-jN` for certain (large-ish) `N`, one can encounter situations where
GNU make attempts to invoke `rustc` before it has actually copied some
of its libraries into place, such as libmorestack.a, which causes a
link failure when the rustc invocation attempts to link in those
libraries.
In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3),
which is described in Makefile.in as "Prerequisites for using the
stageN compiler to build target artifacts"
----
In addition to adding the extra dependences on TSREQ..., I also
replaced occurrences of the pattern:
TSREQ$(1)_T_$(2)_H_$(3)
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2))
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2))
with:
SREQ$(1)_T_$(2)_H_$(3)
which is equivalent to the above, as defined in Makefile.in
----
Finally, for the cases where TSREQ was missing in tests.mk, I went
ahead and put in a dependence on SREQ rather than just TSREQ, since it
was not clear to me how one could expect to compile those cases
without stdlib and extralib.
(It could well be that I should have gone ahead and done the same in
other cases where I saw TSREQ was missing, and put SREQ in those
cases as well. But this seemed like a good measure for now, without
needing to tax my understanding of the overall makefile
infrastructure much further.)
Remove directive, if present, from CFG_RUSTC_FLAGS.
Fix#7898.
(One alternative tack is to build up distinct CFG_TEST_RUSTC_FLAGS
alongside CFG_RUSTC_FLAGS; but currently debug is the only --cfg flag
ever added to CFG_RUSTC_FLAGS; the other contents of CFG_RUSTC_FLAGS
are a mix of -Z flags and a few other switches like O, which seem to
make sense to propogate to the tests.)
This should get us over the hump of activating basic ratcheting on codegen tests, at least. It also puts in place optional (disabled by default) ratcheting on all #[bench] tests, and records all metrics from them to harvestable .json files in any case.
This commit fixes some oversights in the Makefile where rustc could be
invoked without some of its dependencies yet in place. (I encountered
the problem in practice; its not just theoretical.)
As written in Makefile.in, $(STAGE$(1)_T_$(2)_H_$(3)) is the way one
writes an invocation of rustc where $(1) is the stage number $(2) is
the target triple $(3) is the host triple. (Other uses of the macro
may plug in actual values or different parameters in for those three
formal parameters.)
When you have invocations of $(STAGE...), you need to make sure that
its dependences are satisfied; otherwise, if someone is using `make
-jN` for certain (large-ish) `N`, one can encounter situations where
GNU make attempts to invoke `rustc` before it has actually copied some
of its libraries into place, such as libmorestack.a, which causes a
link failure when the rustc invocation attempts to link in those
libraries.
In this case, the main prerequisite to add is TSREQ$(1)_T_$(2)_H_$(3),
which is described in Makefile.in as "Prerequisites for using the
stageN compiler to build target artifacts"
----
In addition to adding the extra dependences on TSREQ..., I also
replaced occurrences of the pattern:
TSREQ$(1)_T_$(2)_H_$(3)
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_STDLIB_$(2))
$$(TLIB$(1)_T_$(2)_H_$(3))/$(CFG_EXTRALIB_$(2))
with:
SREQ$(1)_T_$(2)_H_$(3)
which is equivalent to the above, as defined in Makefile.in
----
Finally, for the cases where TSREQ was missing in tests.mk, I went
ahead and put in a dependence on SREQ rather than just TSREQ, since it
was not clear to me how one could expect to compile those cases
without stdlib and extralib.
(It could well be that I should have gone ahead and done the same in
other cases where I saw TSREQ was missing, and put SREQ in those
cases as well. But this seemed like a good measure for now, without
needing to tax my understanding of the overall makefile
infrastructure much further.)
When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)
When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.
The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.
Fixes#3225 (at least in terms of mitigating the multiple library
problem by proactively warning the user about it.)
This is a small follow-up fix to the previous commit: I needed
to quote the right-hand side of the definition for the variable
MATCHES, to handle the case where there are more than one previously
installed libraries in the target directory.
Namely, switched in many places to using GNU make provided functions
for directory listing and text processing, rather than spawning a
shell process to do that work.
In the process of the revision, learned about Target-specific
variables, which were very applicable to INSTALL_LIB (which, on a
per-recipe basis, was always receiving the same actual arguments for
its first two formal parameters in every invocation).
http://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html
(We might be able to make use of those in future refactorings.)
----
Also adds a cleanup pass to get-snapshot.py as well, since the same
problem arises when we unpack libraries from the snapshot archive into
a build directory with a prior snapshot's artifacts. (I put this step
into the python script rather than the makefile because I wanted to
delay the cleanup pass until after we have at least successfully
downloaded the tarball. That way, if the download fails, you should
not destroy the previous unarchived snapshot libraries and build
products.)
----
Also reverted whitespace changes to minimize diff.
I plan to put them back in in a dedicated commit elsewhere.
As per https://mail.mozilla.org/pipermail/rust-dev/2013-July/004685.html
This is the initial machinery to setup the l10n infrastructure for markdown documentation.
A new "docs-l10n" target will take care of generating, updating and then building .pot and .po files, and later on the final .md.
This commit includes the .pot for all current .md docs; they can be feed directly to Mozilla Verbatim if wanted.
Please note that po4a only provides the orig.md -> .pot -> l10n.po -> l10n.md flow. The l10n.md -> l10n.html generation is not currently built in the makefile, as no language has been enabled.
This commit add a new "docs-l10n" make target which uses po4a to:
* create .pot (PO templates) from markdown doc
* update templates and po for enabled languages
* generate translated markdown for completed (> 80%) translations
Currently, no language has been activated.
Signed-off-by: Luca Bruno <lucab@debian.org>
When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)
When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.
The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.
This makes it possible for us to trigger the llvm-clean make-target by checking in a change that touches rustllvm/llvm-auto-clean-stamp. Most developers don't need to see or know about this, but when you push a change that "needs an LLVM rebuild", even if not otherwise obvious, this should give a mechanism to do it.
- Fix stat struct for Android (found by SEGV at run-pass/stat.rs)
- Adjust some test cases to rpass for Android
- Modify some script to rpass for Android
Apparently the standard --build and --host flags don't actually
_do_ anything. This re-uses the libuv flags, since they are the
same for getting jemalloc to cross-compile
Fix#6805: add --enable-ccache configure option to prefix compiler invocations with `ccache` to attempt to reuse common results, e.g. for LLVM (re)builds.
The information at developer [Note-ccache](../../wiki/Note-ccache) and at [ccache and clang concerns](http://petereisentraut.blogspot.fr/2011/09/ccache-and-clang-part-2.html) were what drove my introduction of the `-Qunused-arguments` and `CCACHE_CPP2` options. (Though I did confirm first-hand that at least the first really is necessary.)
Yes, one certainly can re-route how `gcc` and `clang` are resolved in one's PATH and use that as a way to invoke `ccache`. But I personally do not want to introduce that change to my own PATH, and this seems like a small enough change that it does not hurt to add it, at least for now. (I don't know what form it would take when we move over to `rustpkg`.)
Most of the relevant information can be found in the commit messages.
r? @brson - I just wanted to make sure the make changes aren't completely bogus
This would close#2400, #6517, and #6489 (although a run through incoming-full on linux would have to confirm the latter two)
This way a cross-compiled rustc's answer to host_triple() is correct. The return
value of host_triple() reflects the actual host triple that the compiler was
build for, not the triple the compiler is being built on
Refactor the optimization passes to explicitly use the passes. This commit
just re-implements the same passes as were already being run.
It also adds an option (behind `-Z`) to run the LLVM lint pass on the
unoptimized IR.
This updates the bundled linenoise library, and explicitly builds it with UTF8 support. This way rusti correctly handles utf8 characters when doing line operations.
Closes#6681
This lets us use #ifdefs to determine which stage of the build we happen
to be in, which is useful in the event we need to make changes to rustrt
that are incompatible with the code generated by stage0.
This should help pave the way to completing #6575, which will likely
require changes to type signatures for spawn_fn & glue_fn in rustrt.
It uses the private field of TCB head to store stack limit. I tested on my Raspberry PI. A simple hello world program ran without any problem. However, for a more complex program, it segfaulted as #6231.
* They didn't work before, because the location of the tests caused the
'sysroot' option to crate lookup to be wrong for finding the correct stage's
core/std libraries. This moves the compiled tests from the $host/test
directory into a $host/$stage/test directory. This means that the sysroot will
be correct and the core/std libraries can actually be found
* The LLVM bindings apparently aren't threadsafe, so we can't run multiple tests
in parallel.
fix for #6279#6253
mk: rt.mk regression patch for mingw32 after #6176
currently do not pass optimization option just make it works only
mk: target.mk host.mk fix for duplicated rules of mingw32 after #6235
It can be simply fixed with CFG_LIB check whether bin or lib however considering multiple target triples with linux and windows, CFG_LIB needs to configurable #5223 and #5577
Support #5297
install.mk : install-runtime-target added for conveneice
automatically push runtime library to android device
test.mk : expanded to support android test automation with adb
compiletest : expanded to support android test automation with adb
This is an attempt to address Issue #3326 by adding [*order-only*][1]
prerequsites of each build product on the directory where it is to go.
It is important that the prerequisites be order-only, since the
timestamp on a parent directory is not relevant to whether a product
is out of date; the parent directory merely needs to exist.
(This use case of generating target directories was provided as an
[example][2] of how order-only prequisites are used.)
[1]: http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html
[2]: http://www.kolpackov.net/pipermail/notes/2004-January/000001.html
