Currently analyze_move_out_from checks all restrictions on all base
paths of the move path, but it only needs to check restrictions from
loans of the base paths, and can disregard restrictions from loans of
extensions of those base paths.
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!`)
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.
Closes#12898.
[breaking-change]
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.
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.
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.
RFC #27.
After a snapshot, the old syntax will be removed.
This can break some code that looked like `foo as &Trait:Send`. Now you
will need to write `foo as (&Trait+Send)`.
Closes#12778.
[breaking-change]
the leading quote part of the identifier for the purposes of hygiene.
This adopts @jbclements' solution to #14539.
I'm not sure if this is a breaking change or not.
Closes#12512.
[breaking-change]
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.
4. Add some missing tests.
cc #5527
r? @pcwalton or @pnkfelix
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.
Fixes#13564
* 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 '}'
Closes#14810
[breaking-change]
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.
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).
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.
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.
Fixes#13681.
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.
The guide previously stated:
> The compiler will automatically convert a box box point to a reference like &point.
This fixes the doubled word `box`, so the statement reads
> The compiler will automatically convert a box point to a reference like &point.
The code it is referring to is `compute_distance(&on_the_stack, on_the_heap);`, so a single `box` is appropriate.
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.
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.
* 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 '}'
Closes#14810
[breaking-change]
The following features have been removed
* `box [a, b, c]`
* `~[a, b, c]`
* `box [a, ..N]`
* `~[a, ..N]`
* `~[T]` (as a type)
* deprecated_owned_vector lint
All users of ~[T] should move to using Vec<T> instead.
The following features have been removed
* box [a, b, c]
* ~[a, b, c]
* box [a, ..N]
* ~[a, ..N]
* ~[T] (as a type)
* deprecated_owned_vector lint
All users of ~[T] should move to using Vec<T> instead.
