auto merge of #9064 : SiegeLord/rust/external_struct_variants, r=luqmana
Fixes issues #5557 and #8746.
This patch adds an additional family for struct-like variants, and encodes some struct-like aspects of such variants that can then be properly decoded by resolve.
Note that I am not 100% sure how this fix works, but it fixes the issue without breaking any of the tests on my machine.
auto merge of #9039 : singingboyo/rust/update-for-expr-docs, r=thestinger
The old documentation for for loops/expressions has been quite wrong since the change to iterators. This updates the docs to make them relevant to how for loops work now, if not very in-depth. There may be a need for updates giving more depth on how they work, such as detailing what method calls they make, but I don't know enough about the implementation to include that.
auto merge of #9097 : michaelwoerister/rust/namespaces, r=jdm
Who would have thought that namespaces are such a can of worms `:P` This is mostly because of some GDB idiosyncrasies (does not use namespace information but linkage-name attributes for displaying items contained in namespaces, also cannot handle functions lexically nested within functions), monomorphization, and information about external items only available from metadata.
This pull request tries to tackle the problem anyway:
* The `DW_AT_linkage_name` for functions is generated just to make GDB display a proper namespace-enabled function name. To this end, a pseudo-mangled name is generated, not corresponding to the real linkage name. This approach shows some success and could be extended to make GDB also show proper parameter types.
* As GDB won't accept subprogram DIEs nested within other subprogram DIEs, the `debuginfo` module now generates a *companion namespace* for each functions (iff needed). A function `fn abc()` will get a companion namespace with name `abc()`, which contains all items (modules, types, functions) declared within the functions scope. The real, proper solution, in my opinion, would be to faithfully reflect the program's lexical structure within DWARF (which allows arbitrary nesting of DIEs, afaik), but I am not sure LLVM's source level debugging implementation would like that and I am pretty sure GDB won't support this in the foreseeable future.
* Monomorphization leads to functions and companion namespaces like `somelib::some_func<int, float>()::some_other_function<bool, bool, bool>()`, which I think is the desired behaviour. There is some design space here, however. Maybe you people prefer `somelib::some_func()::some_other_function<bool, bool, bool>()` or `somelib::some_func()::some_other_function::<int, float, bool, bool, bool>()`.
The solution will work for now but there are a few things on my 'far future wish list':
* A real specification somewhere, what language constructs are mapped to what DWARF structures.
* Proper tests that directly compare the generated DWARF information to the expected results (possibly using something like [pyelftools](https://github.com/eliben/pyelftools) or llvm-dwarfdump)
* A unified implementation for crate-local and crate-external items (which would possibly involve beefing up `ast_map::path` and metadata a bit)
Any comments are welcome!
Closes #1541
Closes #1542 (there might be other issues with function name prettiness, but this specific issue should be fixed)
Closes #7715 (source locations for structs and enums are now read correctly from the AST)
auto merge of #9013 : alexcrichton/rust/generated-unsafe-blocks, r=sanxiyn
This way syntax extensions can generate unsafe blocks without worrying about them generating unnecessary unsafe warnings. Perhaps a special keyword could be added to be used in macros, but I don't think that's the best solution.
Currently if you use `format!` and friends in an `unsafe` block you're guaranteed to get some unused-unsafe warnings which is unfortunate. We normally do want these warnings, but I'm ok ignoring them in the case of compiler-generated unsafe blocks. I tried to do this in the least intrusive way possible, but others may have better ideas about how to do this.
Alex Crichton [Thu, 29 Aug 2013 06:47:26 +0000 (23:47 -0700)]
Implement the notion of a "generated unsafe block"
This way syntax extensions can generate unsafe blocks without worrying about
them generating unnecessary unsafe warnings. Perhaps a special keyword could be
added to be used in macros, but I don't think that's the best solution.
auto merge of #9091 : sfackler/rust/buffered, r=alexcrichton
The default buffer size is the same as the one in Java's BufferedWriter.
We may want BufferedWriter to have a Drop impl that flushes, but that
isn't possible right now due to #4252/#4430. This would be a bit
awkward due to the possibility of the inner flush failing. For what it's
worth, Java's BufferedReader doesn't have a flushing finalizer, but that
may just be because Java's finalizer support is awful.
The current implementation of BufferedStream is weird in my opinion, but
it's what the discussion in #8953 settled on.
I wrote a custom copy function since vec::copy_from doesn't optimize as
well as I would like.
Steven Fackler [Tue, 10 Sep 2013 05:38:43 +0000 (22:38 -0700)]
Buffered I/O wrappers
The default buffer size is the same as the one in Java's BufferedWriter.
We may want BufferedWriter to have a Drop impl that flushes, but that
isn't possible right now due to #4252/#4430. This would be a bit
awkward due to the possibility of the inner flush failing. For what it's
worth, Java's BufferedReader doesn't have a flushing finalizer, but that
may just be because Java's finalizer support is awful.
auto merge of #9103 : jbclements/rust/let-var-hygiene, r=erickt
update AST so that ExprBreak and ExprCont expressions contain names, not idents. Fixes #9047 and makes progress on #6993. Simplifies the compiler very slightly, should make it (infinitesimally) faster.
Niko Matsakis [Sat, 7 Sep 2013 02:11:55 +0000 (22:11 -0400)]
Delay assignment of node ids until after expansion. Ensures that each AST node
has a unique id. Fixes numerous bugs in macro expansion and deriving. Add two
representative tests.
auto merge of #9062 : blake2-ppc/rust/vec-iterator, r=alexcrichton
Visit the free functions of std::vec and reimplement or remove some. Most prominently, remove `each_permutation` and replace with two iterators, ElementSwaps and Permutations.
Replace unzip, unzip_slice with an updated `unzip` that works with an iterator argument.
Replace each_permutation with a Permutation iterator. The new permutation iterator is more efficient since it uses an algorithm that produces permutations in an order where each is only one element swap apart, including swapping back to the original state with one swap at the end.
Unify the seldomly used functions `build`, `build_sized`, `build_sized_opt` into just one function `build`.
John Clements [Tue, 10 Sep 2013 03:50:41 +0000 (20:50 -0700)]
undo cowardly hiding of eq-check
I've reversed my thinking on this restrictive definition of eq after
two separate bugs were hidden by commenting it out; it's better to
get ICEs than SIGSEGV's, any day.
std::at_vec and vec: Unify build_sized, build_sized_opt into build
These functions have very few users since they are mostly replaced by
iterator-based constructions.
Convert a few remaining users in-tree, and reduce the number of
functions by basically renaming build_sized_opt to build, and removing
the other two. This for both the vec and the at_vec versions.
Update for a lot of changes (not many free functions left), add examples
of the important methods `slice` and `push`, and write a short bit about
iteration.
std::vec: Replace each_permutation with a new Permutations iterator
Introduce ElementSwaps and Permutations. ElementSwaps is an iterator
that for a given sequence length yields the element swaps needed
to visit each possible permutation of the sequence in turn.
We use an algorithm that generates a sequence such that each permutation
is only one swap apart.
let mut v = [1, 2, 3];
for perm in v.permutations_iter() {
// yields 1 2 3 | 1 3 2 | 3 1 2 | 3 2 1 | 2 3 1 | 2 1 3
}
The `.permutations_iter()` yields clones of the input vector for each
permutation.
If a copyless traversal is needed, it can be constructed with
`ElementSwaps`:
for (a, b) in ElementSwaps::new(3) {
// yields (2, 1), (1, 0), (2, 1) ...
v.swap(a, b);
// ..
}
auto merge of #9089 : anasazi/rust/fix-acceptor-iterator, r=cmr
The iterator over incoming connections has no natural end, so it should always return Some(_).
Currently, if an incoming connection fails, the iterator returns None.
Trying to accept another connection afterwards enters the realm of undefined behavior (due to the iterator protocol being silent on the issue).
This PR changes wraps the underlying accept call in Some, so the iterator never finishes.
auto merge of #9005 : alexcrichton/rust/rusty-log, r=brson
Also redefine all of the standard logging macros to use more rust code instead
of custom LLVM translation code. This makes them a bit easier to understand, but
also more flexibile for future types of logging.
Additionally, this commit removes the LogType language item in preparation for
changing how logging is performed.
David Creswick [Mon, 9 Sep 2013 16:15:03 +0000 (11:15 -0500)]
Convert between BigInts, BigUints, ints, and uints
Previously, conversion to ints, uints, and BigUints clamped the value
within the range of that datatype. With this commit, conversion
overflows fail the task. To handle overflows gracefully, use the new
to_*_opt() methods.
auto merge of #9065 : thestinger/rust/iter, r=alexcrichton
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
Daniel Micay [Sun, 8 Sep 2013 15:01:16 +0000 (11:01 -0400)]
rename `std::iterator` to `std::iter`
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
auto merge of #9035 : alexcrichton/rust/fewer-clownshoes, r=huonw
This removes another large chunk of this odd 'clownshoes' identifier showing up
in symbol names. These all originated from external crates because the encoded
items were encoded independently of the paths calculated in ast_map. The
encoding of these paths now uses the helper function in ast_map to calculate the
"pretty name" for an impl block.
Unfortunately there is still no information about generics in the symbol name,
but it's certainly vastly better than before
hash::__extensions__::write::_version::v0.8
becomes
hash::Writer$SipState::write::hversion::v0.8
This also fixes bugs in which lots of methods would show up as `meth_XXX`, they
now only show up as `meth` and throw some extra characters onto the version
string.
auto merge of #9015 : MicahChalmer/rust/emacs-fixes-round-2, r=nikomatsakis
Here are fixes for more problems mentioned in #8787. I think I've addressed everything mentioned there except for @nikomatsakis's comment about match/patterns now. (This also fixes the bug in struct alignment that @pnkfelix mentioned from my earlier pull request #8872.)
The biggest change here is to make fill-paragraph (M-q) and auto-fill-mode work inside different variations of multi-line and doc comments. Because of the way emacs paragraph fills work (callbacks interacting with global regexp variables that are used in odd ways) there were quite a few edge cases that I had to work around.
The only way I was able to keep it all straight was to create some regression tests. They use the emacs lisp regression testing tool ERT, and are included as the last commit here. I added a few tests for indentation as well. I have not attempted to integrate the tests into the overall rust compiler build process, since I can't imagine anyone would want the compiler build to have a dependency on emacs. Maybe at some point tools like this get their own repositories? Just a thought.
One other thought related to the tests: should there be a place to put these types of style samples that isn't specific to one text editor? Maybe as part of an official rust style guide, but in a form that would allow tools like this to pull out the samples and use them for tests?
auto merge of #8906 : novalis/rust/master, r=alexcrichton
This is a patch to fix #6031. I didn't see any tests for the C++ library code, so I didn't write a test for my changes. Did I miss something, or are there really no tests?
auto merge of #9032 : alexcrichton/rust/inline-repr, r=thestinger
This allows cross-crate inlining which is *very* good because this is called a
lot throughout libstd (even when libstd is inlined across crates).
In one of my projects, I have a test case with the following performance characteristics
commit | optimization level | runtime (seconds)
----|------|----
before | O2 | 22s
before | O3 | 107s
after | O2 | 13s
after | O3 | 12s
I'm a bit disturbed by the 107s runtime from O3 before this commit. The performance characteristics of this test involve doing an absurd amount of small operations. A huge portion of this is creating hashmaps which involves allocating vectors.
The worst portions of the profile are:
Which as you can see looks like some *serious* problems with inlining. I would expect the hash map methods to be high up in the profile, but the top 9 callers of `cast::transmute_copy` were `Repr::repr`'s various monomorphized instances.
I wish there we a better way to detect things like this in the future, and it's unfortunate that this is required for performance in the first place. I suppose I'm not entirely sure why this is needed because all of the methods should have been generated in-crate (monomorphized versions of library functions), so they should have gotten inlined? It also could just be that by modifying LLVM's idea of the inline cost of this function it was able to inline it in many more locations.
projects / rust.git / log