This patch replaces all `crate` usage with `krate` before introducing the
new keyword. This ensures that after introducing the keyword, there
won't be any compilation errors.
krate might not be the most expressive substitution for crate but it's a
very close abbreviation for it. `module` was already used in several
places already.
NodeIds are sequential integers starting at zero, so we can achieve some
memory savings by just storing the items all in a line in a vector.
The occupancy for typical crates seems to be 75-80%, so we're already
more efficient than a HashMap (maximum occupancy 75%), not even counting
the extra book-keeping that HashMap does.
The resulting symbol names aren't very pretty at all:
trait Trait { fn method(&self); }
impl<'a> Trait for ~[(&'a int, fn())] { fn method(&self) {} }
gives
Trait$$UP$$VEC$$TUP_2$$BP$int$$FN$$::method::...hash...::v0.0
However, at least it contain some reference to the Self type, unlike
`Trait$__extensions__::method:...`, which is what the symbol name used
to be for anything other than `impl Trait for foo::bar::Baz` (which
became, and still becomes, `Trait$Baz::method`).
There's currently a fair amount of code which is being ignored on unnamed blocks
(which are the default now), and I opted to leave it commented out for now. I
intend on very soon revisiting on how we perform linking with extern crates in
an effort to support static linking.
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.
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!
Remove __extensions__ from method symbols as well as the meth_XXX. The XXX is
now used to append a few characters at the end of the name of the symbol.
Closes#6602
There are 6 new compiler recognised attributes: deprecated, experimental,
unstable, stable, frozen, locked (these levels are taken directly from
Node's "stability index"[1]). These indicate the stability of the
item to which they are attached; e.g. `#[deprecated] fn foo() { .. }`
says that `foo` is deprecated.
This comes with 3 lints for the first 3 levels (with matching names) that
will detect the use of items marked with them (the `unstable` lint
includes items with no stability attribute). The attributes can be given
a short text note that will be displayed by the lint. An example:
#[warn(unstable)]; // `allow` by default
#[deprecated="use `bar`"]
fn foo() { }
#[stable]
fn bar() { }
fn baz() { }
fn main() {
foo(); // "warning: use of deprecated item: use `bar`"
bar(); // all fine
baz(); // "warning: use of unmarked item"
}
The lints currently only check the "edges" of the AST: i.e. functions,
methods[2], structs and enum variants. Any stability attributes on modules,
enums, traits and impls are not checked.
[1]: http://nodejs.org/api/documentation.html
[2]: the method check is currently incorrect and doesn't work.
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.
Before, the path name for all items defined in methods of traits and impls never
took into account the name of the method. This meant that if you had two statics
of the same name in two different methods the statics would end up having the
same symbol named (even after mangling) because the path components leading to
the symbol were exactly the same (just __extensions__ and the static name).
It turns out that if you add the symbol "A" twice to LLVM, it automatically
makes the second one "A1" instead of "A". What this meant is that in local crate
compilations we never found this bug. Even across crates, this was never a
problem. The problem arises when you have generic methods that don't get
generated at compile-time of a library. If the statics were re-added to LLVM by
a client crate of a library in a different order, you would reference different
constants (the integer suffixes wouldn't be guaranteed to be the same).
This fixes the problem by adding the method name to symbol path when building
the ast_map. In doing so, two symbols in two different methods are disambiguated
against.
Alpha-renamed top-level visit_* functions to walk_*.
(Motivation: Distinguish visit action and recursive traversal.)
Abstract over `&mut self` rather than over `@mut self`.
This required some acrobatics, notably the
`impl<E> Visitor<E> for @mut Visitor<E>`
and corresponding introduction of `@mut Visitor` and some local `let
mut` bindings.
Remove oldvisit reference.
Added default implementations for all of the Visitor trait methods.
Note that both `visit_expr_post` and `visit_ty` are no-op's by
default, just like they are in `oldvisit::default_visitor`.
Refactoring: extract logic to ease swapping visit for oldvisit (hopefully).
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`.
