Currently, rustc requires that a linkage be a product of 100% rlibs or 100%
dylibs. This is to satisfy the requirement that each object appear at most once
in the final output products. This is a bit limiting, and the upcoming libcore
library cannot exist as a dylib, so these rules must change.
The goal of this commit is to enable *some* use cases for mixing rlibs and
dylibs, primarily libcore's use case. It is not targeted at allowing an
exhaustive number of linkage flavors.
There is a new dependency_format module in rustc which calculates what format
each upstream library should be linked as in each output type of the current
unit of compilation. The module itself contains many gory details about what's
going on here.
cc #10729
Namely:
* Added conversion traits both to and from the various vector types,
analogous to how `str::MaybeOwned` works with `str::IntoMaybeOwned`
and `str::Str`. This led me to add the `FixedLen` variant of
`MaybeOwnedVector` for interoperability with `std::slice`.
* Revised client example code to make use of `into_maybe_owned`
* Added implementations of `Show` and `CloneableVector` for
`MaybeOwnedVector`.
* As suggested by kballard, added `into_vec` method that is analogous
to `CloneableVector::into_owned` except it produces a `Vec` rather
than a `~[T]`.
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`).
char literals now work in a quotation.
There were several instances of duplicated functionality in regex_macros
compared to AstBuilder so refactor those out.
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.
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.
RFC: 0015-assert
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`.
[breaking-change]
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.
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`.
This fixes#9391.
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.
r? @alexcrichton, @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.
Closes#13861
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).
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 :)
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.
Closes#13848
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.
Closes#13848
