This can be a frustrating error message, ideally we should print the signature mismatch, but hinting that it's a trait incompatibility helps tracking root cause. Also beefed up the testcases for this.
Ideally we would print the signature mismatch in the error helper?
rustc: move the check_loop pass earlier.
This pass is purely AST based, and by running it earlier we emit more
useful error messages, e.g. type inference fails in the case of
`let r = break;` with few constraints on `r`, but it's more useful to be told that
the `break` is outside the loop (rather than a type error) when it is.
Closes#13292.
This pass is purely AST based, and by running it earlier we emit more
useful error messages, e.g. type inference fails in the case of `let r =
break;` with few constraints on `r`, but its more useful to be told that
the `break` is outside a loop (rather than a type error) when it is.
Closes#13292.
`RefCell::get` can be a bit surprising, because it actually clones the wrapped value. This removes `RefCell::get` and replaces all the users with `RefCell::borrow()` when it can, and `RefCell::borrow().clone()` when it can't. It removes `RefCell::set` for consistency. This closes#13182.
It also fixes an infinite loop in a test when debugging is on.
This was missed when dropping the null-termination from our string
types. An explicit null byte can still be placed anywhere in a string if
desired, but there's no reason to stick one at the end of every string
constant.
It's surprising that `RefCell::get()` is implicitly doing a clone
on a value. This patch removes it and replaces all users with
either `.borrow()` when we can autoderef, or `.borrow().clone()`
when we cannot.
This was missed when dropping the null-termination from our string
types. An explicit null byte can still be placed anywhere in a string if
desired, but there's no reason to stick one at the end of every string
constant.
This change removes the AbiSet from the AST, converting all usage to have just
one Abi value. The current scheme selects a relevant ABI given a list of ABIs
based on the target architecture and how relevant each ABI is to that
architecture.
Instead of this mildly complicated scheme, only one ABI will be allowed in abi
strings, and pseudo-abis will be created for special cases as necessary. For
example the "system" abi exists for stdcall on win32 and C on win64.
Closes#10049
This commit tightens up the restriction on types used to index slices to require
exactly `uint` indices. Previously any integral type was accepted, but this
leads to a few subtle problems:
* 64-bit indices don't make much sense on 32-bit systems
* Signed indices for slices used as negative indexing isn't implemented
This was discussed at the recent work week, and also has some discussion on
issue #10453.
Closes#10453
This commit deals with the fallout of the previous change by making tuples
structs have public fields where necessary (now that the fields are private by
default).
This is a continuation of the work done in #13184 to make struct fields private
by default. This commit finishes RFC 4 by making all tuple structs have private
fields by default. Note that enum variants are not affected.
A tuple struct having a private field means that it cannot be matched on in a
pattern match (both refutable and irrefutable), and it also cannot have a value
specified to be constructed. Similarly to private fields, switching the type of
a private field in a tuple struct should be able to be done in a backwards
compatible way.
The one snag that I ran into which wasn't mentioned in the RFC is that this
commit also forbids taking the value of a tuple struct constructor. For example,
this code now fails to compile:
mod a {
pub struct A(int);
}
let a: fn(int) -> a::A = a::A; //~ ERROR: first field is private
Although no fields are bound in this example, it exposes implementation details
through the type itself. For this reason, taking the value of a struct
constructor with private fields is forbidden (outside the containing module).
RFC: 0004-private-fields
This commit switches privacy's checking of fields to have *all* fields be
private by default. This does not yet change tuple structs, this only affects
structs with named fields. The fallout of this change will follow shortly.
RFC: 0004-private-fields
cc #8122Closes#11809
`collections::list::List` was decided in a [team meeting](https://github.com/mozilla/rust/wiki/Meeting-weekly-2014-03-25) that it was unnecessary, so this PR removes it. Additionally, it removes an old and redundant purity test and fixes some warnings.
Only supports crate level statics. No debug info is generated for function level statics. Closes#9227.
As discussed at the end of the comments for #9227, I took an initial stab at adding support for function level statics and decided it would be enough work to warrant being split into a separate issue.
See #13144 for the new issue describing the need to add support for function level static variables.
r? @nikomatsakis
Fix#13140
Includes two fixes, and a semi-thorough regression test.
(There is another set of tests that I linked from #5121, but those are sort of all over the place, while the ones I've included here are more directly focused on the issues at hand.)
Summary:
So far, we've used the term POD "Plain Old Data" to refer to types that
can be safely copied. However, this term is not consistent with the
other built-in bounds that use verbs instead. This patch renames the Pod
kind into Copy.
RFC: 0003-opt-in-builtin-traits
Test Plan: make check
Reviewers: cmr
Differential Revision: http://phabricator.octayn.net/D3
This commit removes implicitly adding the Send bound to ~Trait objects and
procedure types. It will now be manually required to specify that a procedure
or trait must be send-able.
Closes#10296
The `_match.rs` takes advantage of passes prior to `trans` and
aggressively prunes the sub-match tree based on exact equality. When it
comes to literal or range, the strategy may lead to wrong result if
there's guard function or multiple patterns inside tuple.
Closes#12582.
Closes#13027.
This change prepares `rustc` to accept private fields by default. These changes will have to go through a snapshot before the rest of the changes can happen.
This change is in preparation for #8122. Nothing is currently done with these
visibility qualifiers, they are just parsed and accepted by the compiler.
RFC: 0004-private-fields
The problem was that we need to apply the substitution, so that the
formal lifetime parameters get replaced with (unifiable)
free-lifetimes that can actually be fed into the constraint solver.
Also, refactor code os that substitution for `check_item` and
`check_method`, moving both down the control flow into `check_bare_fn`.
----
Finally, there was another (similar) spot where we needed to
substitute early-bound lifetimes when invoking an object method of a
trait.
It was possible to borrow unsafe static items in static initializers.
This patch implements a small `Visitor` that walks static initializer's
expressions and checks borrows aliasability.
Fixes#13005
cc @nikomatsakis r?
Summary:
It was possible to borrow unsafe static items in static initializers.
This patch implements a small `Visitor` that walks static initializer's
expressions and checks borrows aliasability.
Fixes#13005
Test Plan: make check
Differential Revision: http://phabricator.octayn.net/D2
This needs to be removed as part of removing `~[T]`. Partial type hints
are now allowed, and will remove the need to add a version of this
method for `Vec<T>`. For now, this involves a few workarounds for
partial type hints not completely working.
Replace syntax::opt_vec with syntax::owned_slice
The `owned_slice::OwnedSlice` is `(*T, uint)` (i.e. a direct equivalent to DSTs `~[T]`).
This shaves two words off the old OptVec type; and also makes substituting in other implementations easy, by removing all the mutation methods. (And also everything that's very rarely/never used.)
The compiler will no longer inject libgreen as the default runtime for rust
programs, this commit switches it over to libnative by default. Now that
libnative has baked for some time, it is ready enough to start getting more
serious usage as the default runtime for rustc generated binaries.
We've found that there isn't really a correct decision in choosing a 1:1 or M:N
runtime as a default for all applications, but it seems that a larger number of
programs today would work more reasonable with a native default rather than a
green default.
With this commit come a number of bugfixes:
* The main native task is now named "<main>"
* The main native task has the stack bounds set up properly
* #[no_uv] was renamed to #[no_start]
* The core-run-destroy test was rewritten for both libnative and libgreen and
one of the tests was modified to be more robust.
* The process-detach test was locked to libgreen because it uses signal handling
This is the first step to replacing OptVec with a new representation:
remove all mutability. Any mutations have to go via `Vec` and then make
to `OptVec`.
Many of the uses of OptVec are unnecessary now that Vec has no-alloc
emptiness (and have been converted to Vec): the only ones that really
need it are the AST and sty's (and so on) where there are a *lot* of
instances of them, and they're (mostly) immutable.
In Rust, the strongest guarantee that `&mut` provides is that the memory
pointed to is *not aliased*, whereas `&`'s guarantees are much weaker:
that the value can be aliased, and may be mutated under proper precautions
(interior mutability).
Our atomics though use `&mut` for mutation even while creating multiple
aliases, so this changes them to use 'interior mutability', mutating
through immutable references.
Most of the standard distribution is still using ~[] instead of Vec, so this
lint is essentially useless currently. When the standard distribution has been
ported to not use ~[], then we can turn the lint back on.
`Share` implies that all *reachable* content is *threadsafe*.
Threadsafe is defined as "exposing no operation that permits a data race if multiple threads have access to a &T pointer simultaneously". (NB: the type system should guarantee that if you have access to memory via a &T pointer, the only other way to gain access to that memory is through another &T pointer)...
Fixes#11781
cc #12577
What this PR will do
================
- [x] Add Share kind and
- [x] Replace usages of Freeze with Share in bounds.
- [x] Add Unsafe<T> #12577
- [x] Forbid taking the address of a immutable static item with `Unsafe<T>` interior
What's left to do in a separate PR (after the snapshot)?
===========================================
- Remove `Freeze` completely
These variants occur rarely but inflate the whole enum for the other variants, leaving a lot of wasted space. In total this reduces `ty::sty` from 160 bytes to 96 (on a 64-bit platform).
After this, `ty_struct` and `ty_enum` are the largest variants, with the 80-byte `substs` being the major contributor.
This fixes struct passing abi on x86 ffi: Structs are now passed
indirectly with byval attribute (as clang does).
Empty structs are also explicitly ignored rather than directly passed.
Fixes#5744Fixes#11198Fixes#11343
This reduces the size of sty from 112 to 96; like with the ty_trait
variant, this variant of sty occurs rarely (~1%) so the benefits are
large and the costs small.
This reduces ty::sty from 160 bytes to just 112, and some measurements
eddyb made suggest that the ty_trait variant occurs very
rarely (e.g. ~1% of all sty instances) hence this will result in a large
memory saving, and the cost of the indirection is unlikely to be an
issue.
Remove the linker_private and linker_private_weak linkage attributes,
they have been superseded by private and private_weak and have been
removed in upstream LLVM in commit r203866.
The pretty printer constitues an enormous amount of code, there's no reason for
it to be generic. This just least to a huge amount of metadata which isn't
necessary. Instead, this change migrates the pretty printer to using a trait
object instead.
Closes#12985
This PR enables the use of mutable slices in *mutable* static items. The work was started by @xales and I added a follow-up commit that moves the *immutable* restriction to the recently added `check_static`
Closes#11411
its a common (yet easily fixable) error to just forget parens at the end of getter-like methods without any arguments.
The current error message for that case asks for an anonymous function, this patch adds a note asking for either an anonymous function, or for trailing parens.
This is my first contribution! do i need to do anything else?
This will enable rustdoc to treat them specially.
I also got rid of `std::cmp::cmp2`, which is isomorphic to the `TotalOrd` impl for 2-tuples and never used.
This commit removes all internal support for the previously used __log_level()
expression. The logging subsystem was previously modified to not rely on this
magical expression. This also removes the only other function to use the
module_data map in trans, decl_gc_metadata. It appears that this is an ancient
function from a GC only used long ago.
This does not remove the crate map entirely, as libgreen still uses it to hook
in to the event loop provided by libgreen.
This commit moves all logging out of the standard library into an external
crate. This crate is the new crate which is responsible for all logging macros
and logging implementation. A few reasons for this change are:
* The crate map has always been a bit of a code smell among rust programs. It
has difficulty being loaded on almost all platforms, and it's used almost
exclusively for logging and only logging. Removing the crate map is one of the
end goals of this movement.
* The compiler has a fair bit of special support for logging. It has the
__log_level() expression as well as generating a global word per module
specifying the log level. This is unfairly favoring the built-in logging
system, and is much better done purely in libraries instead of the compiler
itself.
* Initialization of logging is much easier to do if there is no reliance on a
magical crate map being available to set module log levels.
* If the logging library can be written outside of the standard library, there's
no reason that it shouldn't be. It's likely that we're not going to build the
highest quality logging library of all time, so third-party libraries should
be able to provide just as high-quality logging systems as the default one
provided in the rust distribution.
With a migration such as this, the change does not come for free. There are some
subtle changes in the behavior of liblog vs the previous logging macros:
* The core change of this migration is that there is no longer a physical
log-level per module. This concept is still emulated (it is quite useful), but
there is now only a global log level, not a local one. This global log level
is a reflection of the maximum of all log levels specified. The previously
generated logging code looked like:
if specified_level <= __module_log_level() {
println!(...)
}
The newly generated code looks like:
if specified_level <= ::log::LOG_LEVEL {
if ::log::module_enabled(module_path!()) {
println!(...)
}
}
Notably, the first layer of checking is still intended to be "super fast" in
that it's just a load of a global word and a compare. The second layer of
checking is executed to determine if the current module does indeed have
logging turned on.
This means that if any module has a debug log level turned on, all modules
with debug log levels get a little bit slower (they all do more expensive
dynamic checks to determine if they're turned on or not).
Semantically, this migration brings no change in this respect, but
runtime-wise, this will have a perf impact on some code.
* A `RUST_LOG=::help` directive will no longer print out a list of all modules
that can be logged. This is because the crate map will no longer specify the
log levels of all modules, so the list of modules is not known. Additionally,
warnings can no longer be provided if a malformed logging directive was
supplied.
The new "hello world" for logging looks like:
#[phase(syntax, link)]
extern crate log;
fn main() {
debug!("Hello, world!");
}
# Summary
This patch introduces the `_` token into the type grammar, with the meaning "infer this type".
With this change, the following two lines become equivalent:
```
let x = foo();
let x: _ = foo();
```
But due to its composability, it enables partial type hints like this:
```
let x: Bar<_> = baz();
```
Using it on the item level is explicitly forbidden, as the Rust language does not enable global type inference by design.
This implements the feature requested in https://github.com/mozilla/rust/issues/9508.
# Things requiring clarification
- The change to enable it is very small, but I have only limited understanding of the related code, so the approach here might be wrong.
- In particular, while this patch works, it does so in a way not originally intended according to the code comments.
- This probably needs more tests, or rather feedback for which tests are still missing.
- I'm unsure how this interacts with lifetime parameters, and whether it is correct in regard to them.
- Partial type hints on the right side of `as` like `&foo as *_` work in both a normal function contexts and in constexprs like `static foo: *int = &'static 123 as *_`. The question is whether this should be allowed in general.
# Todo for this PR
- The manual and tutorial still needs updating.
# Bugs I'm unsure how to fix
- Requesting inference for the top level of the right hand side of a `as` fails to infer correctly, even if all possible hints are given:
```
.../type_hole_1.rs:35:18: 35:22 error: the type of this value must be known in this context
.../type_hole_1.rs:35 let a: int = 1u32 as _;
^~~~
```
Add some more infrastructure support for demangling `$`-sequences, as well as fixing demangling of closure symbol names if there's more than one closure in a function.
lint: add lint for use of a `~[T]`.
This is useless at the moment (since pretty much every crate uses
`~[]`), but should help avoid regressions once completely removed from a
crate.
## read+write modifier '+'
This small sugar was left out in the original implementation (#5359).
When an output operand with the '+' modifier is encountered, we store the index of that operand alongside the expression to create and append an input operand later. The following lines are equivalent:
```
asm!("" : "+m"(expr));
asm!("" : "=m"(expr) : "0"(expr));
```
## misplaced options and clobbers give a warning
It's really annoying when a small typo might change behavior without any warning.
```
asm!("mov $1, $0" : "=r"(x) : "r"(8u) : "cc" , "volatile");
//~^ WARNING expected a clobber, but found an option
```
## liveness
Fixed incorrect order of propagation.
Sometimes it caused spurious warnings in code: `warning: value assigned to `i` is never read, #[warn(dead_assignment)] on by default`
~~Note: Rebased on top of another PR. (uses other changes)~~
* [x] Implement read+write
* [x] Warn about misplaced options
* [x] Fix liveness (`dead_assignment` lint)
* [x] Add all tests
This commit goes back to using `gensym` to generate unique tokens to put into
the names of closures, allowing closures to be able to get demangled in
backtraces.
Closes#12400
For the following code snippet:
```rust
struct Foo { bar: int }
fn foo1(x: &Foo) -> &int {
&x.bar
}
```
This PR generates the following error message:
```rust
test.rs:2:1: 4:2 note: consider using an explicit lifetime parameter as shown: fn foo1<'a>(x: &'a Foo) -> &'a int
test.rs:2 fn foo1(x: &Foo) -> &int {
test.rs:3 &x.bar
test.rs:4 }
test.rs:3:5: 3:11 error: cannot infer an appropriate lifetime for borrow expression due to conflicting requirements
test.rs:3 &x.bar
^~~~~~
```
Currently it does not support methods.
Some types of error are caused by missing lifetime parameter on function
or method declaration. In such cases, this commit generates some
suggestion about what the function declaration could be. This does not
support method declaration yet.
There is a broader revision (that does this across the board) pending
in #12675, but that is awaiting the arrival of more data (to decide
whether to keep OptVec alive by using a non-Vec internally).
For this code, the representation of lifetime lists needs to be the
same in both ScopeChain and in the ast and ty structures. So it
seemed cleanest to just use `vec_ng::Vec`, now that it has a cheaper
empty representation than the current `vec` code.
It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.
As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type `*T`.
Codegen-wise, we get translations like:
```rust
// rust code
extern {
#[linkage = "extern_weak"]
static foo: *i32;
}
// generated IR
@foo = extern_weak global i32
@_some_internal_symbol = internal global *i32 @foo
```
All references to the rust value of `foo` then reference `_some_internal_symbol`
instead of the symbol `_foo` itself. This allows us to guarantee that the
address of `foo` will never be null while the value may sometimes be null.
An example was implemented in `std::rt::thread` to determine if
`__pthread_get_minstack()` is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.
Thanks to @bnoordhuis for the original patch, most of this work is still his!
It is often convenient to have forms of weak linkage or other various types of
linkage. Sadly, just using these flavors of linkage are not compatible with
Rust's typesystem and how it considers some pointers to be non-null.
As a compromise, this commit adds support for weak linkage to external symbols,
but it requires that this is only placed on extern statics of type `*T`.
Codegen-wise, we get translations like:
// rust code
extern {
#[linkage = "extern_weak"]
static foo: *i32;
}
// generated IR
@foo = extern_weak global i32
@_some_internal_symbol = internal global *i32 @foo
All references to the rust value of `foo` then reference `_some_internal_symbol`
instead of the symbol `_foo` itself. This allows us to guarantee that the
address of `foo` will never be null while the value may sometimes be null.
An example was implemented in `std::rt::thread` to determine if
`__pthread_get_minstack()` is available at runtime, and a test is checked in to
use it for a static value as well. Function pointers a little odd because you
still need to transmute the pointer value to a function pointer, but it's
thankfully better than not having this capability at all.
- Repurposes `MoveData.assignee_ids` to mean only `=` but not `+=`, so
that borrowck effectively classifies all expressions into assignees,
uses or both.
- Removes two `span_err` in liveness analysis, which are now borrowck's
responsibilities.
Closes#12527.
* `Ord` inherits from `Eq`
* `TotalOrd` inherits from `TotalEq`
* `TotalOrd` inherits from `Ord`
* `TotalEq` inherits from `Eq`
This is a partial implementation of #12517.
If #[feature(default_type_parameters)] is enabled for a crate, then
deriving(Hash) will expand with Hash<W: Writer> instead of Hash<SipState> so
more hash algorithms can be used.
This leverages the new hashing framework and hashmap implementation to provide a
much speedier hashing algorithm for node ids and def ids. The hash algorithm
used is currentl FNV hashing, but it's quite easy to swap out.
I originally implemented hashing as the identity function, but this actually
ended up in slowing down rustc compiling libstd from 8s to 13s. I would suspect
that this is a result of a large number of collisions.
With FNV hashing, we get these timings (compiling with --no-trans, in seconds):
| | before | after |
|-----------|---------:|--------:|
| libstd | 8.324 | 6.703 |
| stdtest | 47.674 | 46.857 |
| libsyntax | 9.918 | 8.400 |
Cosmetic changes at best, but there are so many such typos that I couldn't ignore them. :) Some occurrences of typos are linked to the generated documentations but no changes should break the builds.
The llvm.copysign and llvm.round intrinsics weren't added until LLVM 3.4, so if
we're on LLVM 3.3 we lower these to calls in libm instead of LLVM intrinsics.
This should fix our travis failures.
This PR brings back limited debuginfo which allows for nice backtraces and breakpoints, but omits any info about variables and types.
The `-g` and `--debuginfo` command line options have been extended to take an optional argument:
`-g0` means no debug info.
`-g1` means line-tables only.
`-g2` means full debug info.
Specifying `-g` without argument is equivalent to `-g2`.
Fixes#12280
Closes#8506.
The `trans::adt` code for statics uses fields with `C_undef` values to
insert alignment padding (because LLVM's own alignment padding isn't
always sufficient for aggregate constants), and assumes that all fields
in the actual Rust value are represented by non-undef LLVM values, to
distinguish them from that padding.
But for nullable pointer enums, if non-null variant has fields other
than the pointer used as the discriminant, they would be set to undef in
the null case, to reflect that they're never accessed.
To avoid the obvious conflict between these two items, the latter undefs
were wrapped in unary LLVM structs to distinguish them from the former
undefs. Except this doesn't actually work -- LLVM, not unreasonably,
treats the "wrapped undef" as a regular undef.
So this commit just sets all fields to null in the null pointer case of
a nullable pointer enum static, because the other fields don't really
need to be undef in the first place.
The llvm.copysign and llvm.round intrinsics weren't added until LLVM 3.4, so if
we're on LLVM 3.3 we lower these to calls in libm instead of LLVM intrinsics.
This should fix our travis failures.
Fixes#10877
There was another PR which attempted to fix this in the parser (#11804) and which was closed due to inactivity.
This PR modifies typeck instead (as suggested in #11804), which indeed seems to be simpler than modifying the parser and allows for a better error message.
While we are not yet ready for compiler i18n, this also keeps the error handling code clean. The set of altered error messages was obtained by grepping for `"s"` and `(s)`, so there might be some missing messages.
Previously `ast::Arm` was always storing a single `ast::Expr` wrapped in an
`ast::Block` (for historical reasons, AIUI), so we might as just store
that expr directly.
Closes#3085.
We weren't passing the node id for the enum and hence it couldn't retrieve the field types for the struct variant we were trying to destructure.
Fixes#11577.
From my comment on #11450:
The reason for the ICE is because for operators `rustc` does a little bit of magic. Notice that while you implement the `Mul` trait for some type `&T` (i.e a reference to some T), you can simply do `Vec2 {..} * 2.0f32`. That is, `2.0f32` is `f32` and not `&f32`. This works because `rustc` will automatically take a reference. So what's happening is that with `foo * T`, the compiler is expecting the `mul` method to take some `&U` and then it can compare to make sure `T == U` (or more specifically that `T` coerces to `U`). But in this case, the argument of the `mul` method is not a reference and hence the "no ref" error.
I don't think we should ICE in this case since we do catch the mismatched trait/impl method and hence provide a better error message that way.
Fixes#11450
Formatting via reflection has been a little questionable for some time now, and
it's a little unfortunate that one of the standard macros will silently use
reflection when you weren't expecting it. This adds small bits of code bloat to
libraries, as well as not always being necessary. In light of this information,
this commit switches assert_eq!() to using {} in the error message instead of
{:?}.
In updating existing code, there were a few error cases that I encountered:
* It's impossible to define Show for [T, ..N]. I think DST will alleviate this
because we can define Show for [T].
* A few types here and there just needed a #[deriving(Show)]
* Type parameters needed a Show bound, I often moved this to `assert!(a == b)`
* `Path` doesn't implement `Show`, so assert_eq!() cannot be used on two paths.
I don't think this is much of a regression though because {:?} on paths looks
awful (it's a byte array).
Concretely speaking, this shaved 10K off a 656K binary. Not a lot, but sometime
significant for smaller binaries.
This new SVH is used to uniquely identify all crates as a snapshot in time of
their ABI/API/publicly reachable state. This current calculation is just a hash
of the entire crate's AST. This is obviously incorrect, but it is currently the
reality for today.
This change threads through the new Svh structure which originates from crate
dependencies. The concept of crate id hash is preserved to provide efficient
matching on filenames for crate loading. The inspected hash once crate metadata
is opened has been changed to use the new Svh.
The goal of this hash is to identify when upstream crates have changed but
downstream crates have not been recompiled. This will prevent the def-id drift
problem where upstream crates were recompiled, thereby changing their metadata,
but downstream crates were not recompiled.
In the future this hash can be expanded to exclude contents of the AST like doc
comments, but limitations in the compiler prevent this change from being made at
this time.
Closes#10207
The previous code passed around a {name,version} pair everywhere, but this is
better expressed as a CrateId. This patch changes these paths to store and pass
around crate ids instead of these pairs of name/version. This also prepares the
code to change the type of hash that is stored in crates.
These are types that are in exported type signatures, but are not
exported themselves, e.g.
struct Foo { ... }
pub fn bar() -> Foo { ... }
will warn about the Foo.
Such types are not listed in documentation, and cannot be named outside
the crate in which they are declared, which is very user-unfriendly.
cc #10573
This PR allows `HashMap`s to work with custom hashers. Also with this patch are:
* a couple generic implementations of `Hash` for a variety of types.
* added `Default`, `Clone` impls to the hashers.
* added a `HashMap::with_hasher()` constructor.
Closes#12546 (Add new target 'make dist-osx' to create a .pkg installer for OS X) r=brson
Closes#12575 (rustc: Move local native libs back in link-args) r=brson
Closes#12587 (Provide a more helpful error for tests that fail due to noexec) r=brson
Closes#12589 (rustc: Remove codemap and reachable from metadata encoder) r=alexcrichton
Closes#12591 (Fix syntax::ext::deriving{,::*} docs formatting.) r=huonw
Closes#12592 (Miscellaneous Vim improvements) r=alexcrichton
Closes#12596 (path: Implement windows::make_non_verbatim()) r=alexcrichton
Closes#12598 (Improve the ctags function regular expression) r=alexcrichton
Closes#12599 (Tutorial improvement (new variant of PR #12472).) r=pnkfelix
Closes#12603 (std: Export the select! macro) r=pcwalton
Closes#12605 (Fix typo in doc of Binary trait in std::fmt) r=alexcrichton
Closes#12613 (Fix bytepos_to_file_charpos) r=brson
This PR includes:
- Create an iterator for ```List<T>``` called ```Items<T>```;
- Move all list operations inside ```List<T>``` impl;
- Removed functions that are already provided by ```Iterator``` trait;
- Refactor on ```len()``` and ```is_empty``` using ```Container``` trait;
- Bunch of minor fixes;
A replacement for using @ is intended, but still in discussion.
Closes#12344.
- For each *mutable* static item, check that the **type**:
- cannot own any value whose type has a dtor
- cannot own any values whose type is an owned pointer
- For each *immutable* static item, check that the **value**:
- does not contain any ~ or box expressions
(including ~[1, 2, 3] sort of things)
- does not contain a struct literal or call to an enum
variant / struct constructor where
- the type of the struct/enum has a dtor
This patch series does a couple things:
* replaces manual `Hash` implementations with `#[deriving(Hash)]`
* adds `Hash` back to `std::prelude`
* minor cleanup of whitespace and variable names.
In its first pass, namely gather_loans, the borrow checker tracks the
initialization sites among other things it does. It does so for let
bindings with initializers but not for bindings in match arms, which are
effectively also assignments. This patch does that for borrow checker.
Closes#12452.
The by-value argument is a copy that is only valid for the duration of
the function call, therefore keeping any pointer to it that outlives the
call is illegal.
Commits for details. Highlights:
- `flate` returns `CVec<u8>` to save reallocating a whole new `&[u8]`
- a lot of `transmute`s removed outright or replaced with `as` (etc.)
