Since 3b6314c3 the pretty printer seems to only print trait bounds for
`ast::ty_path(...)`s that have a generics arguments list. That seems
wrong, so let's always print them.
Closes#9253, un-xfails test for #7673.
This constrains the span to the appropriate argument, so you know which
one caused the problem. Instead of
foo.rs:2:4: 2:21 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~~~~~~~~~~~~~~~
it will say
foo.rs:2:14 2:17 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~
This doesn't close any bugs as the goal is to convert the parameter to by-value, but this is a step towards being able to make guarantees about `&T` pointers (where T is Freeze) to LLVM.
This constrains the span to the appropriate argument, so you know which
one caused the problem. Instead of
foo.rs:2:4: 2:21 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~~~~~~~~~~~~~~~
it will say
foo.rs:2:14 2:17 error: Too large integer literal in bytes!
foo.rs:2 bytes!(1, 256, 2)
^~~
Remove these in favor of the two traits themselves and the wrapper
function std::from_str::from_str.
Add the function std::num::from_str_radix in the corresponding role for
the FromStrRadix trait.
The same fix as before is still relevant, I just forgot to update the
expand_stmt macro expansion site. The tests for format!() suffice as tests for
this change.
This renames the syntax-extension file to format from ifmt, and it also reduces
the amount of complexity inside by defining all other macros in terms of
format_args!
Work a bit towards #9157 "Remove Either". These instances don't need to use Either and are better expressed in other ways (removing allocations and simplifying types).
This is a series of patches to modernize option and result. The highlights are:
* rename `.unwrap_or_default(value)` and etc to `.unwrap_or(value)`
* add `.unwrap_or_default()` that uses the `Default` trait
* add `Default` implementations for vecs, HashMap, Option
* add `Option.and(T) -> Option<T>`, `Option.and_then(&fn() -> Option<T>) -> Option<T>`, `Option.or(T) -> Option<T>`, and `Option.or_else(&fn() -> Option<T>) -> Option<T>`
* add `option::ToOption`, `option::IntoOption`, `option::AsOption`, `result::ToResult`, `result::IntoResult`, `result::AsResult`, `either::ToEither`, and `either::IntoEither`, `either::AsEither`
* renamed `Option::chain*` and `Result::chain*` to `and_then` and `or_else` to avoid the eventual collision with `Iterator.chain`.
* Added a bunch of impls of `Default`
* Added a `#[deriving(Default)]` syntax extension
* Removed impls of `Zero` for `Option<T>` and vecs.
The purpose of this macro is to further reduce the number of allocations which
occur when dealing with formatting strings. This macro will perform all of the
static analysis necessary to validate that a format string is safe, and then it
will wrap up the "format string" into an opaque struct which can then be passed
around.
Two safe functions are added (write/format) which take this opaque argument
structure, unwrap it, and then call the unsafe version of write/format (in an
unsafe block). Other than these two functions, it is not intended for anyone to
ever look inside this opaque struct.
The macro looks a bit odd, but mostly because of rvalue lifetimes this is the
only way for it to be safe that I know of.
Example use-cases of this are:
* third-party libraries can use the default formatting syntax without any
forced allocations
* the fail!() macro can avoid allocating the format string
* the logging macros can avoid allocation any strings
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.
Ensures that each AST node has a unique id. Fixes numerous bugs in macro expansion and deriving. Add two
representative tests.
Fixes#7971Fixes#6304Fixes#8367Fixes#8754Fixes#8852Fixes#2543Fixes#7654
has a unique id. Fixes numerous bugs in macro expansion and deriving. Add two
representative tests.
Fixes#7971Fixes#6304Fixes#8367Fixes#8754Fixes#8852Fixes#2543Fixes#7654
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`.
Remove `equal_sizes`
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.
RE-ENABLING ICE MACHINE!
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.
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.
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.
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.
This is actually almost a problem, because those were my poster-child
macros for "here's how to implement a capturing macro." Following this
change, there will be no macros that use capturing; this will probably
make life unpleasant for the first person that wants to implement a
capturing macro. I should probably create a dummy_capturing macro,
just to show how it works.
this is necessary so that the new idents are connected to the original strings.
this is important both for error messages, and so that top-level refs get connected
to the right things.
Rationale: having a function which fails means that the location of
failure which is output is that of the unreachable() function, rather
than the caller.
This is part of #8991 but is not all of it; current usage of
``std::util::unreachable()`` must remain so for the moment, until a new
snapshot is made; then I will remove that function entirely in favour of
using this macro.
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.
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!
Rationale: having a function which fails means that the location of
failure which is output is that of the unreachable() function, rather
than the caller.
This is part of #8991 but is not all of it; current usage of
``std::util::unreachable()`` must remain so for the moment, until a new
snapshot is made; then I will remove that function entirely in favour of
using this macro.
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
Significant progress on #6875, enough that I'll open new bugs and turn that into a metabug when this lands.
Description & example in the commit message.
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.
Fix#8468. (Though the right answer in the end, as noted on the dialogue on the ticket, might be to just require trait methods to name their parameters, regardless of whether they have a default method implementation or not.)
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.
This removes the stacking of type parameters that occurs when invoking
trait methods, and fixes all places in the standard library that were
relying on it. It is somewhat awkward in places; I think we'll probably
want something like the `Foo::<for T>::new()` syntax.
Fixes for #8625 to prevent assigning to `&mut` in borrowed or aliasable locations. The old code was insufficient in that it failed to catch bizarre cases like `& &mut &mut`.
r? @pnkfelix
These new macros are all based on format! instead of fmt! and purely exist for
bootstrapping purposes. After the next snapshot, all uses of logging will be
migrated to these macros, and then after the next snapshot after that we can
drop the `2` suffix on everything
