| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
These commits fix bugs related to identically named statics in functions of implementations in various situations. The commit messages have most of the information about what bugs are being fixed and why.
As a bonus, while I was messing around with name mangling, I improved the backtraces we'll get in gdb by removing `__extensions__` for the trait/type being implemented and by adding the method name as well. Yay!
|
|
Closes #7609
|
|
|
|
As with the previous commit, this is targeted at removing the possibility of
collisions between statics. The main use case here is when there's a
type-parametric function with an inner static that's compiled as a library.
Before this commit, any impl would generate a path item of "__extensions__".
This changes this identifier to be a "pretty name", which is either the last
element of the path of the trait implemented or the last element of the type's
path that's being implemented. That doesn't quite cut it though, so the (trait,
type) pair is hashed and again used to append information to the symbol.
Essentially, __extensions__ was removed for something nicer for debugging, and
then some more information was added to symbol name by including a hash of the
trait being implemented and type it's being implemented for. This should prevent
colliding names for inner statics in regular functions with similar names.
|
|
|
|
|
|
They are still present as part of the borrow check.
|
|
r?
|
|
Follow up to #8619 (step 3 of 5).
(See #8527, which was step 1 of 5, for the full outline.)
Part of #7081.
|
|
This requires changes to method search and to codegen. We now emit a
vtable for objects that includes methods from all supertraits.
Closes #4100.
Also, actually populate the cache for vtables, and also key it by type
so that it actually works.
|
|
|
|
|
|
to favor inherent methods over extension methods.
The reason to favor inherent methods is that otherwise an impl
like
impl Foo for @Foo { fn method(&self) { self.method() } }
causes infinite recursion. The current change to favor inherent methods is
rather hacky; the method resolution code is in need of a refactoring.
|
|
|
|
|
|
- Made naming schemes consistent between Option, Result and Either
- Changed Options Add implementation to work like the maybe monad (return None if any of the inputs is None)
- Removed duplicate Option::get and renamed all related functions to use the term `unwrap` instead
|
|
|
|
|
|
this has been replaced by `for`
|
|
|
|
This is preparation for removing `@fn`.
This does *not* use default methods yet, because I don't know
whether they work. If they do, a forthcoming PR will use them.
This also changes the precedence of `as`.
|
|
|
|
blk_check_mode, ty_field, ty_method}
|
|
nikomatsakis/rust/issue-4846-multiple-lifetime-parameters-1, r=pcwalton
Small step towards #4846. r? @msullivan
|
|
Lots of changes to vtable resolution, handling of super/self method calls in default methods. Fix a lot of trait inheritance bugs.
r? @nikomatsakis
|
|
multiple lifetime parameters, and not just one. Also add an option
for erasing lifetimes, which makes trans code somewhat simpler
and cleaner.
|
|
|
|
Eliminates method_super, method_self, and vtable_self, merging all of
them into the param cases.
Cloes #4396. Closes #7301.
|
|
|
|
`crate => Crate`
`local => Local`
`blk => Block`
`crate_num => CrateNum`
`crate_cfg => CrateConfig`
Also, Crate and Local are not wrapped in spanned<T> anymore.
|
|
|
|
|
|
r?
|
|
|
|
|
|
|
|
parameters
|
|
Remove the Option wrapper around the lower bound. None is semantically
the same as Size(0), so there's no point in having a distinction.
|
|
I think it's WIP - but I wanted to ask for feedback (/cc @thestinger)
I had to move the impl of FromIter for vec into extra::iter because I don't think std can depend on extra, but that's a bit messed up. Similarly some FromIter uses are gone now, not sure if this is fixable or if I made a complete mess here..
|
|
|
|
This patch makes error handling for region inference failures more
uniform by not reporting *any* region errors until the reigon inference
step. This requires threading through more information about what
caused a region constraint, so that we can still give informative
error messages.
I have only taken partial advantage of this information: when region
inference fails, we still report the same error we always did, despite
the fact that we now know precisely what caused the various constriants
and what the region variable represents, which we did not know before.
This change is required not only to improve error messages but
because the region hierarchy is not in fact fully known until regionck,
because it is not clear where closure bodies fit in (our current
treatment is unsound). Moreover, the relationships between free variables
cannot be fully determined until type inference is otherwise complete.
cc #3238.
|
|
|
|
|
|
|
|
|
|
|
