Alex Crichton [Fri, 13 Jun 2014 04:34:32 +0000 (21:34 -0700)]
Rolling up PRs in the queue
Closes #14797 (librustc: Fix the issue with labels shadowing variable names by making)
Closes #14823 (Improve error messages for io::fs)
Closes #14827 (libsyntax: Allow `+` to separate trait bounds from objects.)
Closes #14834 (configure: Don't sync unused submodules)
Closes #14838 (Remove typo on collections::treemap::UnionItems)
Closes #14839 (Fix the unused struct field lint for struct variants)
Closes #14840 (Clarify `Any` docs)
Closes #14846 (rustc: [T, ..N] and [T, ..N+1] are not the same)
Closes #14847 (Audit usage of NativeMutex)
Closes #14850 (remove unnecessary PaX detection)
Closes #14856 (librustc: Take in account mutability when casting array to raw ptr.)
Closes #14859 (librustc: Forbid `transmute` from being called on types whose size is)
Closes #14860 (Fix `quote_pat!` & parse outer attributes in `quote_item!`)
Patrick Walton [Thu, 12 Jun 2014 21:08:44 +0000 (14:08 -0700)]
librustc: Forbid `transmute` from being called on types whose size is
only known post-monomorphization, and report `transmute` errors before
the code is generated for that `transmute`.
This can break code that looked like:
unsafe fn f<T>(x: T) {
let y: int = transmute(x);
}
Change such code to take a type parameter that has the same size as the
type being transmuted to.
Daniel Micay [Thu, 12 Jun 2014 20:11:21 +0000 (16:11 -0400)]
remove unnecessary PaX detection
Rust no longer has support for JIT compilation, so it doesn't currently
require a PaX MPROTECT exception. The extended attributes are preferred
over modifying the binaries so it's not actually going to work on most
systems like this anyway.
If JIT compilation ends up being supported again, it should handle this
by *always* applying the exception via an extended attribute without
performing auto-detection of PaX on the host. The `paxctl` tool is only
necessary with the older method involving modifying the ELF binary.
Alex Crichton [Thu, 12 Jun 2014 18:40:13 +0000 (11:40 -0700)]
Audit usage of NativeMutex
Once a native mutex has been used once, it is never allowed to be moved again.
This is because some pthreads implementations take pointers inside the mutex
itself.
This commit adds stern wording around the methods on native mutexes, and fixes
one use case in the codebase. The Mutex type in libsync was susceptible to
movement, so the inner static mutex is now boxed to ensure that the address of
the native mutex is constant.
Alex Crichton [Thu, 12 Jun 2014 17:27:44 +0000 (10:27 -0700)]
rustc: [T, ..N] and [T, ..N+1] are not the same
This commit fixes a bug in the calculation of the hash of a type which didn't
factor in the length of a constant-sized vector. As a result of this, a type
placed into an Any of a fixed length could be peeled out with any other fixed
length in a safe manner.
bors [Fri, 13 Jun 2014 19:02:11 +0000 (19:02 +0000)]
auto merge of #14604 : nikomatsakis/rust/issue-5527-namespace-substs, r=pcwalton
The current setup is to have a single vector of type parameters in
scope at any one time. We then have to concatenate the parameters from
the impl/trait with those of the method. This makes a lot of things
awkward, most notably associated fns ("static fns"). This branch
restructures the substitutions into three distinct namespaces (type,
self, fn). This makes most of the "type parameter management"
trivial. This also sets us up to support UFCS (though I haven't made
any particular changes in that direction in this patch).
Along the way, this patch fixes a few miscellaneous bits of code cleanup:
1. Patch resolve to detect references to out-of-scope type parameters,
rather than checking for "out of bound" indices during substitution
(fixes #14603).
2. Move def out of libsyntax into librustc where it belongs. I should have
moved DefId too, but didn't.
3. Permit homogeneous tuples like `(T, T, T)` to be used as fixed-length
vectors like `[T, ..3]`. This is awfully handy, though public facing.
I suppose it requires an RFC.
Niko Matsakis [Sat, 31 May 2014 22:53:13 +0000 (18:53 -0400)]
Introduce VecPerParamSpace and use it to represent sets of types and
parameters
This involves numerous substeps:
1. Treat Self same as any other parameter.
2. No longer compute offsets for method parameters.
3. Store all generic types (both trait/impl and method) with a method,
eliminating odd discrepancies.
4. Stop doing unspeakable things to static methods and instead just use
the natural types, now that we can easily add the type parameters from
trait into the method's polytype.
5. No doubt some more. It was hard to separate these into distinct commits.
bors [Fri, 13 Jun 2014 14:42:03 +0000 (14:42 +0000)]
auto merge of #14831 : alexcrichton/rust/format-intl, r=brson
* The select/plural methods from format strings are removed
* The # character no longer needs to be escaped
* The \-based escapes have been removed
* '{{' is now an escape for '{'
* '}}' is now an escape for '}'
bors [Fri, 13 Jun 2014 09:57:06 +0000 (09:57 +0000)]
auto merge of #13222 : nick29581/rust/dxr4, r=brson
Adds a -Z flag `save-analysis` which runs after the analysis phase of the compiler and saves a bunch of info into a CSV file for the crate. This is designed to work with the DXR code browser, but is frontend-independent, that is this info should be useful for all kinds of code browsers, IDEs, or other tools.
I need to squash commits before landing (there will probably be a fair few to come), please ignore them for now and just comment on the changes.
Nick Cameron [Wed, 5 Feb 2014 04:31:33 +0000 (17:31 +1300)]
Dump results of analysis phase as CSV
Adds the option -Zsave-analysis which will dump the results of syntax and type checking into CSV files. These can be interpreted by tools such as DXR to provide semantic information about Rust programs for code search, cross-reference, etc.
Authored by Nick Cameron and Peter Elmers (@pelmers; including enums, type parameters/generics).
bors [Fri, 13 Jun 2014 01:52:02 +0000 (01:52 +0000)]
auto merge of #14819 : michaelwoerister/rust/unique_type_id, r=alexcrichton
With this change, rustc creates a unique type identifier for types in debuginfo. These type identifiers are used by LLVM to correctly handle link-time-optimization scenarios but also help rustc with dealing with inlining from other crates. For more information, see the documentation block at the top of librustc/middle/trans/debuginfo.rs and also [my blog post about the topic](http://michaelwoerister.github.io/2014/06/05/rust-debuginfo-and-unique-type-identifiers.html). This should fix the LTO issues that have been popping up lately.
The changes to the debuginfo module's inner workings are also improved by this. Metadata uniquing of pointer types is not handled explicitly instead of relying on LLVM doing the right thing behind the scenes, and region parameters on types should not lead to metadata duplication anymore.
There are two things that I'd like to get some feedback on:
1. IDs for named items consist of two parts: The [Strict Version Hash](https://github.com/mozilla/rust/blob/0.10/src/librustc/back/svh.rs#L11) of their defining crate and the AST node id of their definition within that crate. My question is: Is the SVH a good choice for identifying the crate? Is it even going to stay? The [crate-id RFC](https://github.com/rust-lang/rfcs/pull/109) got me confused.
2. Unique Type Identifiers can be arbitrary strings and right now the format is rather verbose. For debugging this is nice, because one can infer a lot about a type from the type id alone (it's more or less a signature). For deeply nested generics, id strings could get rather long though. One option to limit the id size would be to use some hashcode instead of the full id (anything that avoids collision as much as possible). Another option would be to use a more compact representation, like ty_encode. This reduces size but also readability.
Since these ID's only show up in LLVM IR, I'm inclined to just leave in the verbose format for now, and only act if sizes of rlibs become a problem.
bors [Fri, 13 Jun 2014 00:07:05 +0000 (00:07 +0000)]
auto merge of #14816 : theptrk/rust/unclear-comment, r=huonw
The old comment left it unclear if this is creating a random value or doing a check as to whether or not the generator is available or some other operation.
debuginfo: Generate cross-crate unique type identifiers for debuginfo types.
With this change, rustc creates a unique type identifier for types in debuginfo. These type identifiers are used by LLVM to correctly handle link-time-optimization scenarios but also help rustc with dealing with inlining from other crates. For more information, see the documentation block at the top of librustc/middle/trans/debuginfo.rs.
bors [Thu, 12 Jun 2014 16:02:05 +0000 (16:02 +0000)]
auto merge of #14809 : zzmp/rust/patch-2, r=alexcrichton
Previously, the type system's restrictions on borrowing were summarized as
> The previous example showed that the type system forbids any borrowing of owned boxes found in aliasable, mutable memory.
This did not jive with the example, which allowed mutations so long as the borrowed reference had been returned. Also, the language has changed to no longer allow aliasable mutable locations. This changes the summary to read
> The previous example showed that the type system forbids mutations of owned boxed values while they are being borrowed. In general, the type system also forbids borrowing a value as mutable if it is already being borrowed - either as a mutable reference or an immutable one.
This adds more general information for the experienced reader as well, to offer a more complete understanding.
bors [Thu, 12 Jun 2014 09:02:08 +0000 (02:02 -0700)]
auto merge of #14792 : alexcrichton/rust/local-jemalloc, r=brson
This configures the makefiles to copy a local jemalloc/libuv library into place instead of building the local copy of one. Additionally, this switches our travis builds to using the system-provided jemalloc instead of a custom-built jemalloc to exercise this functionality.
Alex Crichton [Sat, 7 Jun 2014 06:52:56 +0000 (23:52 -0700)]
mk: Allow usage of a local jemalloc install
This adds a new configure option, --jemalloc-root, which will specify a location
at which libjemalloc_pic.a must live. This library is then used for the build
triple as the jemalloc library to link.
Alex Crichton [Wed, 28 May 2014 16:24:28 +0000 (09:24 -0700)]
std: Remove i18n/l10n from format!
* The select/plural methods from format strings are removed
* The # character no longer needs to be escaped
* The \-based escapes have been removed
* '{{' is now an escape for '{'
* '}}' is now an escape for '}'
bors [Wed, 11 Jun 2014 18:47:04 +0000 (11:47 -0700)]
auto merge of #14746 : alexcrichton/rust/libsync, r=brson
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.
There were a few notable changes and a few breaking changes as part of this
movement:
* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
It is now a private module with types/functions being reexported under
`sync::comm`. This is a breaking change for any existing users of duplex
streams.
* All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
live under `std::sync`. They will forever live at this location, but they may
move to libsync if the `std::task` module moves as well.
bors [Wed, 11 Jun 2014 17:02:04 +0000 (10:02 -0700)]
auto merge of #14250 : alexcrichton/rust/gc, r=brson
This commit removes `@T` from the compiler by moving the AST to using `Gc<T>`. This also starts treating `Gc<T>` as `@T` in the same way that `Box<T>` is the same as `~T` in the compiler.
After this hits a snapshot, the `@T` syntax should be able to be removed completely.
Alex Crichton [Sat, 7 Jun 2014 18:13:26 +0000 (11:13 -0700)]
sync: Move underneath libstd
This commit is the final step in the libstd facade, #13851. The purpose of this
commit is to move libsync underneath the standard library, behind the facade.
This will allow core primitives like channels, queues, and atomics to all live
in the same location.
There were a few notable changes and a few breaking changes as part of this
movement:
* The `Vec` and `String` types are reexported at the top level of libcollections
* The `unreachable!()` macro was copied to libcore
* The `std::rt::thread` module was moved to librustrt, but it is still
reexported at the same location.
* The `std::comm` module was moved to libsync
* The `sync::comm` module was moved under `sync::comm`, and renamed to `duplex`.
It is now a private module with types/functions being reexported under
`sync::comm`. This is a breaking change for any existing users of duplex
streams.
* All concurrent queues/deques were moved directly under libsync. They are also
all marked with #![experimental] for now if they are public.
* The `task_pool` and `future` modules no longer live in libsync, but rather
live under `std::sync`. They will forever live at this location, but they may
move to libsync if the `std::task` module moves as well.
Alex Crichton [Fri, 16 May 2014 01:18:00 +0000 (18:18 -0700)]
rustc: Update how Gc<T> is recognized
This commit uses the same trick as ~/Box to map Gc<T> to @T internally inside
the compiler. This moves a number of implementations of traits to the `gc`
module in the standard library.
This removes functions such as `Gc::new`, `Gc::borrow`, and `Gc::ptr_eq` in
favor of the more modern equivalents, `box(GC)`, `Deref`, and pointer equality.
The Gc pointer itself should be much more useful now, and subsequent commits
will move the compiler away from @T towards Gc<T>
bors [Wed, 11 Jun 2014 02:52:05 +0000 (19:52 -0700)]
auto merge of #14777 : alexcrichton/rust/issue-14747, r=huonw
When generating documentation, rustdoc has the ability to generate relative
links within the current distribution of crates to one another. To do this, it
must recognize when a crate's documentation is in the same output directory. The
current threshold for "local documentation for crate X being available" is
whether the directory "doc/X" exists.
This change modifies the build system to have new dependencies for each
directory of upstream crates for a rustdoc invocation. This will ensure that
when building documentation that all the crates in the standard distribution are
guaranteed to have relative links to one another.
This change is prompted by guaranteeing that offline docs always work with one
another. Before this change, races could mean that some docs were built before
others, and hence may have http links when relative links would suffice.
bors [Wed, 11 Jun 2014 01:07:07 +0000 (18:07 -0700)]
auto merge of #14768 : riccieri/rust/detransmute-arena, r=alexcrichton
**Update**
I've reimplemented this using `Cell` and `RefCell`, as suggested by @alexcrichton. By taking care with the duration of the borrows, I was able to maintain the recursive allocation feature (now covered by a test) without the use of `Unsafe`, and without breaking the non-aliasing `&mut` invariant.
**Original**
Changes both `Arena` and `TypedArena` to contain an inner struct wrapped in a `Unsafe`, and change field access to go through those instead of transmuting `&self` to `&mut self`.
Zach Pomerantz [Wed, 11 Jun 2014 00:36:02 +0000 (17:36 -0700)]
Update description to reflect language changes
Previously, the type system's restrictions on borrowing were summarized as
> The previous example showed that the type system forbids any borrowing of owned boxes found in aliasable, mutable memory
This did not jive with the example, which allowed mutations so long as the borrowed reference had been returned. Also, the language has changed to no longer allow aliasable mutable locations. This changes the summary to read
> The previous example showed that the type system forbids mutations of owned boxed values while they are being borrowed. In general, the type system also forbids borrowing a value as mutable if it is already being borrowed - either as a mutable reference or an immutable one.
This adds more general information for the experienced reader as well, to offer a more complete understanding.
Alex Crichton [Mon, 9 Jun 2014 19:56:37 +0000 (12:56 -0700)]
rustdoc: Correctly classify enums/typedefs
Both of these items are surfaced as a DefTy, so some extra logic was needed in
the decoder module to figure out whether one is actually an enum or whether it's
a typedef.
Huon Wilson [Mon, 9 Jun 2014 14:31:31 +0000 (00:31 +1000)]
native: add more info to the native unimplemented error.
This refers to green, which (AFAICT) has everything implemented. In
particular, this will help guide people to get working signal handling
via libgreen.
Alex Crichton [Mon, 2 Jun 2014 21:51:58 +0000 (14:51 -0700)]
std: Remove the as_utf16_p functions
These functions are all much better expressed via RAII using the to_utf16()
method on strings. This refactoring also takes this opportunity to properly
handle when filenames aren't valid unicode when passed through to the windows
I/O layer by properly returning I/O errors.
All previous users of the `as_utf16_p` or `as_utf16_mut_p` functions will need
to convert their code to using `foo.to_utf16().append_one(0)` to get a
null-terminated utf16 string.
bors [Mon, 9 Jun 2014 22:52:07 +0000 (15:52 -0700)]
auto merge of #14554 : kmcallister/rust/plugin_registrar, r=cmr
This implements the design in rust-lang/rfcs#86. It shouldn't be merged until that RFC is accepted, but it would be great if somebody has time to review the code before then.