bors [Mon, 5 May 2014 08:41:39 +0000 (01:41 -0700)]
auto merge of #13936 : Armavica/rust/lint_check-range, r=kballard
Some cases were not correctly handled by this lint, for instance `let a = 42u8; a < 0` and `let a = 42u8; a > 255`.
It led to the discovery of two useless comparisons, which I removed.
bors [Mon, 5 May 2014 03:51:43 +0000 (20:51 -0700)]
auto merge of #13924 : gmjosack/rust/master, r=alexcrichton
Most of the links I've removed are for types that don't exist anymore with the exception of `SendReceiver` though I'm not sure how useful it is to link to that without the accompanying `Receiver` and `Sender` and I don't know how useful those links are when they're discussed below and `channel`/`sync_channel` is on the `std::comm` page already linked.
bors [Mon, 5 May 2014 01:36:43 +0000 (18:36 -0700)]
auto merge of #13865 : alexcrichton/rust/issue-13861, r=brson
Previously, windows was using the CREATE_NEW flag which fails if the file
previously existed, which differed from the unix semantics. This alters the
opening to use the OPEN_ALWAYS flag to mirror the unix semantics.
bors [Mon, 5 May 2014 00:11:42 +0000 (17:11 -0700)]
auto merge of #13905 : alexcrichton/rust/issue-13337, r=thestinger
This has long since not been too relevant since the introduction of many crate
type outputs. This commit removes the flag entirely, adjusting all logic to do
the most reasonable thing when building both a library and an executable.
bors [Sun, 4 May 2014 21:21:52 +0000 (14:21 -0700)]
auto merge of #13676 : mdinger/rust/tutorial_doc, r=pnkfelix
Improve tutorial discussion of closures, e.g. with respect to type inference and variable capture.
Fix #13621
---- original description follows
I'd like this pulled to master if possible but if not I'd appreciate comments on what I need to change. I found the closures difficult to understand as they were so I tried to explain it so I would've had an easier time understanding it. I think it's better at least, somewhat.
I don't know that everyone liked the `-> ()` I included but I thought explicit is best to aid understanding. I thought it was much harder to understand than it should have been.
[EDIT] - Clicked too early.
This doesn't `make check` without errors on my Xubuntu on Virtualbox machine. Not sure why. I don't think I changed anything problematic. I'll try `make check` on master tomorrow.
Opened https://github.com/mozilla/rust/issues/13621 regarding this.
bors [Sun, 4 May 2014 09:16:50 +0000 (02:16 -0700)]
auto merge of #13391 : smesseim/rust/apache-copyright, r=alexcrichton
The years of copyright and the name of the copyright holder were not
present in the notice.
The Apache license was added to the project in 2012, so 2012 is the
starting year. The copyright holder is the Mozilla Foundation (taken
from the MIT license).
bors [Sat, 3 May 2014 22:56:51 +0000 (15:56 -0700)]
auto merge of #13906 : alexcrichton/rust/issue-13620, r=luqmana
This ensures that private functions exported through static initializers will
actually end up being public in the object file (so other objects can continue
to reference the function).
bors [Sat, 3 May 2014 19:21:47 +0000 (12:21 -0700)]
auto merge of #13685 : Ryman/rust/issue7575, r=alexcrichton
Closes #7575.
I don't think the change from a contains lookup to an iteration of the HashSet in the resolver should be much of a burden as the set of methods with the same name should be relatively small.
bors [Sat, 3 May 2014 15:06:49 +0000 (08:06 -0700)]
auto merge of #13868 : FlaPer87/rust/opt-in-phase1, r=alexcrichton
This is a first patch towards an opt-in built-in trait world. This patch removes the restriction on built-in traits and allows such traits to be derived.
bors [Sat, 3 May 2014 03:56:52 +0000 (20:56 -0700)]
auto merge of #13880 : TeXitoi/rust/biguint-always-use-u64, r=pcwalton
This change allow a speedup of ~1.5 on shootout-pidigits on a i32
system. `MachineUint` is used to abstract the internal machine
unsigned integer to simplity future architecture specialization.
Alex Crichton [Fri, 2 May 2014 22:40:07 +0000 (15:40 -0700)]
rustc: Crawl static initializers for reachability
This ensures that private functions exported through static initializers will
actually end up being public in the object file (so other objects can continue
to reference the function).
Alex Crichton [Fri, 2 May 2014 22:26:45 +0000 (15:26 -0700)]
rustc: Remove the session building_library flag
This has long since not been too relevant since the introduction of many crate
type outputs. This commit removes the flag entirely, adjusting all logic to do
the most reasonable thing when building both a library and an executable.
bors [Fri, 2 May 2014 14:06:50 +0000 (07:06 -0700)]
auto merge of #13879 : huonw/rust/more-re, r=alexcrichton
Commits for details.
This shouldn't change the generated code at all (except for switching to `LitBinary` from an explicit ExprVec of individual ExprLit bytes for `prefix_bytes`).
Huon Wilson [Thu, 1 May 2014 13:35:06 +0000 (23:35 +1000)]
syntax: store char literals/tokens as `char`s rather than u32s.
Clearly storing them as `char` is semantically nicer, but this also
fixes a bug whereby `quote_expr!(cx, 'a')` wasn't working, because the
code created by quotation was not matching the actual AST definitions.
bors [Fri, 2 May 2014 06:41:46 +0000 (23:41 -0700)]
auto merge of #13789 : sfackler/rust/debug-assert, r=pcwalton
I switched the `assert!` calls in `RefCell` over to `debug_assert!`.
There are probably other instances that should be converted as well, but
I couldn't think of any off the top of my head.
Guillaume Pinot [Thu, 1 May 2014 14:02:44 +0000 (16:02 +0200)]
BigUint always use u64 as the internal machine unsigned integer
This change allow a speedup of ~1.5 on shootout-pidigits on a i32
system. `DoubleBigDigit` is used to abstract the internal
unsigned integer used in computation to simplity future
architecture specialization.
`BigDigit::from_uint` and `BigDigit::to_uint` become
`BigDigit::from_doublebigdigit` and `BigDigit::to_doublebigdigit`.
bors [Thu, 1 May 2014 11:36:50 +0000 (04:36 -0700)]
auto merge of #13724 : nikomatsakis/rust/expr-use-visitor, r=pnkfelix
Pre-step towards issue #12624 and others: Introduce ExprUseVisitor, remove the
moves computation. ExprUseVisitor is a visitor that walks the AST for a
function and calls a delegate to inform it where borrows, copies, and moves
occur.
In this patch, I rewrite the gather_loans visitor to use ExprUseVisitor, but in
future patches, I think we could rewrite regionck, check_loans, and possibly
other passes to use it as well. This would refactor the repeated code between
those places that tries to determine where copies/moves/etc occur.
auto merge of #13648 : gereeter/rust/removed-rev, r=alexcrichton
In the process, `Splits` got changed to be more like `CharSplits` in `str` to present the DEI interface.
Note that `treemap` still has a `rev_iter` function because it seems like it would be a significant interface change to expose a DEI - the iterator would have to gain an extra pointer, the completion checks would be more complicated, and it isn't easy to check that such an implementation is correct due to the use of unsafety to subvert the aliasing properties of `&mut`.
auto merge of #13864 : adrientetar/rust/fix-it-some-more, r=alexcrichton
Two selector fixes for rustdoc:
- links colored in blue (#13807) was also affecting headers, which are anchored to their respective ids
- the header unstyling from #13776 was being applied to all headers also
Additionally, remove a stray title in the documentation. This makes the crate title of prelude appear as header instead of an inline paragraph of text (all others work normally and do not have that header tag).
The design is unchanged from my previous template (e.g. [here](http://adrientetar.legtux.org/cached/rust-docs/struct.CChars.htm)), however it is now properly applied.
The last fix remaining is to enable webfonts service from `static.rust-lang.org`, this is #13593.
Alex Crichton [Wed, 30 Apr 2014 18:37:01 +0000 (11:37 -0700)]
native: Always open a file with Open/Write modes
Previously, windows was using the CREATE_NEW flag which fails if the file
previously existed, which differed from the unix semantics. This alters the
opening to use the OPEN_ALWAYS flag to mirror the unix semantics.
Most important: distinguish function decl sugar for omitting `-> ()`
from type inference on closures. I also tried to add a couple more
examples to further emphasize this distinction. Note that this sugar
(of omitting `-> ()`) is actually already briefly mentioned in an
earlier section, so it is a little tricky deciding whether to put more
material here, or to move it up to the previous section.
Other drive-by fixes:
* Fix the line length of the code blocks to fit in the width provided
in the rendered HTML
* Some minor revisions to wording (e.g. try to clarify in some cases
where a type mismatch is arising).
auto merge of #12740 : nical/rust/json-streaming, r=erickt
Hi rust enthusiasts,
With this patch I propose to add a "streaming" API to the existing json parser in libserialize.
By "streaming" I mean a parser that let you act on JsonEvents that are generated as while parsing happens, as opposed to parsing the entire source, generating a big data structure and working with this data structure. I think both approaches have their pros and cons so this pull request adds the streaming API, preserving the existing one.
The streaming API is simple: It consist into an Iterator<JsonEvent> that consumes an Iterator<char>. JsonEvent is an enum with values such as NumberValue(f64), BeginList, EndList, BeginObject, etc.
The user would ideally use the API as follows:
```
for evt in StreamingParser::new(src) {
match evt {
BeginList => {
// ...
}
// ...
}
}
```
The iterator provides a stack() method returning a slice of StackNodes which represent "where we currently are" in the logical structure of the json stream (for instance at "foo.bar[3].x" you get [ Key("foo"), Key("bar"), Index(3), Key("x") ].)
I wrote "ideally" above because the current way rust expands for loops, you can't call the stack() method because the iterator is already borrowed. So for know you need to manually advance the iterator in the loop. I hope this is something we can cope with, until for loops are better integrated with the compiler.
Streaming parsers are useful when you want to read from a json stream, generate a custom data structure and you know how the json is going to be structured. For example, imagine you have to parse a 3D mesh file represented in the json format. In this case you probably expect to have large arrays of vertices and using the generic parser will be very inefficient because it will create a big list of all these vertices, which you will copy into a contiguous array afterwards (so you end up doing a lot of small allocations, parsing the json once and parsing the data structure afterwards). With a streaming parser, you can add the vertices to a contiguous array as they come in without paying the cost of creating the intermediate Json data structure. You have much fewer allocations since you write directly in the final data structure and you can be smart in how you will pre-allocate it.
I added added this directly into serialize::json rather than in its own library because it turns out I can reuse most of the existing code whereas maintaining a separate library (which I did originally) forces me to duplicate this code.
I wrote this trying to minimize the size of the patch so there may be places where the code could be nicer at the expenses of more changes (let me know what you prefer).
This is my first (potential) contribution to rust, so please let me know if I am doing something wrong (maybe I should have first introduced this proposition in the mailing list, or opened a github issue, etc.?). I work a few meters away from @pknfelix so I am not too hard to find :)
auto merge of #13857 : alexcrichton/rust/add-dylib-paths, r=brson
When a syntax extension is loaded by the compiler, the dylib that is opened may
have other dylibs that it depends on. The dynamic linker must be able to find
these libraries on the system or else the library will fail to load.
Currently, unix gets by with the use of rpaths. This relies on the dylib not
moving around too drastically relative to its dependencies. For windows,
however, this is no rpath available, and in theory unix should work without
rpaths as well.
This modifies the compiler to add all -L search directories to the dynamic
linker's set of load paths. This is currently managed through environment
variables for each platform.
Alex Crichton [Tue, 29 Apr 2014 18:38:51 +0000 (11:38 -0700)]
rustc: Add search paths to dylib load paths
When a syntax extension is loaded by the compiler, the dylib that is opened may
have other dylibs that it depends on. The dynamic linker must be able to find
these libraries on the system or else the library will fail to load.
Currently, unix gets by with the use of rpaths. This relies on the dylib not
moving around too drastically relative to its dependencies. For windows,
however, this is no rpath available, and in theory unix should work without
rpaths as well.
This modifies the compiler to add all -L search directories to the dynamic
linker's set of load paths. This is currently managed through environment
variables for each platform.
auto merge of #13776 : adrientetar/rust/rustdoc-fix, r=brson
- Closes #13591. Relevant example: http://adrientetar.legtux.org/cached/rust-docs/struct.CChars.htm
(Had to use `!important` to override CSS selector precedence, namely matching over parent class.)
- Implement changes from #13780 feedback, namely:
* Changed font-size from 18px to 15px
* Reintroduced gray background for code samples
* Tightened up the margins
- Fix point 1 and point 4 of #13804.
auto merge of #13833 : alexcrichton/rust/ffunction-sections, r=thestinger
The compiler has previously been producing binaries on the order of 1.8MB for
hello world programs "fn main() {}". This is largely a result of the compilation
model used by compiling entire libraries into a single object file and because
static linking is favored by default.
When linking, linkers will pull in the entire contents of an object file if any
symbol from the object file is used. This means that if any symbol from a rust
library is used, the entire library is pulled in unconditionally, regardless of
whether the library is used or not.
Traditional C/C++ projects do not normally encounter these large executable
problems because their archives (rust's rlibs) are composed of many objects.
Because of this, linkers can eliminate entire objects from being in the final
executable. With rustc, however, the linker does not have the opportunity to
leave out entire object files.
In order to get similar benefits from dead code stripping at link time, this
commit enables the -ffunction-sections and -fdata-sections flags in LLVM, as
well as passing --gc-sections to the linker *by default*. This means that each
function and each global will be placed into its own section, allowing the
linker to GC all unused functions and data symbols.
By enabling these flags, rust is able to generate much smaller binaries default.
On linux, a hello world binary went from 1.8MB to 597K (a 67% reduction in
size). The output size of dynamic libraries remained constant, but the output
size of rlibs increased, as seen below:
This increase in size is a result of encoding many more section names into each
object file (rlib). These increases are moderate enough that this change seems
worthwhile to me, due to the drastic improvements seen in the final artifacts.
The overall increase of the stage2 target folder (not the size of an install)
went from 337MB to 348MB (3% increase).
Additionally, linking is generally slower when executed with all these new
sections plus the --gc-sections flag. The stage0 compiler takes 1.4s to link the
`rustc` binary, where the stage1 compiler takes 1.9s to link the binary. Three
megabytes are shaved off the binary. I found this increase in link time to be
acceptable relative to the benefits of code size gained.
This commit only enables --gc-sections for *executables*, not dynamic libraries.
LLVM does all the heavy lifting when producing an object file for a dynamic
library, so there is little else for the linker to do (remember that we only
have one object file).
I conducted similar experiments by putting a *module's* functions and data
symbols into its own section (granularity moved to a module level instead of a
function/static level). The size benefits of a hello world were seen to be on
the order of 400K rather than 1.2MB. It seemed that enough benefit was gained
using ffunction-sections that this route was less desirable, despite the lesser
increases in binary rlib size.
auto merge of #13845 : alexcrichton/rust/regex-deps, r=brson
There is currently not much precedent for target crates requiring syntax
extensions to compile their test versions. This dependency is possible, but
can't be encoded through the normal means of DEPS_regex because it is a
test-only dependency and it must be a *host* dependency (it's a syntax
extension).
Alex Crichton [Tue, 29 Apr 2014 00:17:18 +0000 (17:17 -0700)]
rustc: Enable -f{function,data}-sections
The compiler has previously been producing binaries on the order of 1.8MB for
hello world programs "fn main() {}". This is largely a result of the compilation
model used by compiling entire libraries into a single object file and because
static linking is favored by default.
When linking, linkers will pull in the entire contents of an object file if any
symbol from the object file is used. This means that if any symbol from a rust
library is used, the entire library is pulled in unconditionally, regardless of
whether the library is used or not.
Traditional C/C++ projects do not normally encounter these large executable
problems because their archives (rust's rlibs) are composed of many objects.
Because of this, linkers can eliminate entire objects from being in the final
executable. With rustc, however, the linker does not have the opportunity to
leave out entire object files.
In order to get similar benefits from dead code stripping at link time, this
commit enables the -ffunction-sections and -fdata-sections flags in LLVM, as
well as passing --gc-sections to the linker *by default*. This means that each
function and each global will be placed into its own section, allowing the
linker to GC all unused functions and data symbols.
By enabling these flags, rust is able to generate much smaller binaries default.
On linux, a hello world binary went from 1.8MB to 597K (a 67% reduction in
size). The output size of dynamic libraries remained constant, but the output
size of rlibs increased, as seen below:
This increase in size is a result of encoding many more section names into each
object file (rlib). These increases are moderate enough that this change seems
worthwhile to me, due to the drastic improvements seen in the final artifacts.
The overall increase of the stage2 target folder (not the size of an install)
went from 337MB to 348MB (3% increase).
Additionally, linking is generally slower when executed with all these new
sections plus the --gc-sections flag. The stage0 compiler takes 1.4s to link the
`rustc` binary, where the stage1 compiler takes 1.9s to link the binary. Three
megabytes are shaved off the binary. I found this increase in link time to be
acceptable relative to the benefits of code size gained.
This commit only enables --gc-sections for *executables*, not dynamic libraries.
LLVM does all the heavy lifting when producing an object file for a dynamic
library, so there is little else for the linker to do (remember that we only
have one object file).
I conducted similar experiments by putting a *module's* functions and data
symbols into its own section (granularity moved to a module level instead of a
function/static level). The size benefits of a hello world were seen to be on
the order of 400K rather than 1.2MB. It seemed that enough benefit was gained
using ffunction-sections that this route was less desirable, despite the lesser
increases in binary rlib size.
projects / rust.git / log