with the corresponding trait parameter bounds.
This is a version of the patch in PR #12611 by Florian Hahn, modified to
address Niko's feedback.
It does not address the issue of duplicate type parameter bounds, nor
does it address the issue of implementation-defined methods that contain
*fewer* bounds than the trait, because Niko's review indicates that this
should not be necessary (and indeed I believe it is not). A test has
been added to ensure that this works.
This will break code like:
trait Foo {
fn bar<T:Baz>();
}
impl Foo for Boo {
fn bar<T:Baz + Quux>() { ... }
// ^~~~ ERROR
}
This will be rejected because the implementation requires *more* bounds
than the trait. It can be fixed by either adding the missing bound to
the trait:
trait Foo {
fn bar<T:Baz + Quux>();
// ^~~~
}
impl Foo for Boo {
fn bar<T:Baz + Quux>() { ... } // OK
}
Or by removing the bound from the impl:
trait Foo {
fn bar<T:Baz>();
}
impl Foo for Boo {
fn bar<T:Baz>() { ... } // OK
// ^ remove Quux
}
This patch imports the relevant tests from #2687, as well as the test
case in #5886, which is fixed as well by this patch.
Closes#2687.
Closes#5886.
[breaking-change]
r? @pnkfelix
parameters.
This can break code that mistakenly used type parameters in place of
`Self`. For example, this will break:
trait Foo {
fn bar<X>(u: X) -> Self {
u
}
}
Change this code to not contain a type error. For example:
trait Foo {
fn bar<X>(_: X) -> Self {
self
}
}
Closes#15172.
[breaking-change]
Slice patterns are different from the rest in that a single slice pattern
does not have a distinct constructor if it contains a variable-length subslice
pattern. For example, the pattern [a, b, ..tail] can match a slice of length 2, 3, 4
and so on.
As a result, the decision tree for exhaustiveness and redundancy analysis should
explore each of those constructors separately to determine if the pattern could be useful
when specialized for any of them.
So far, type names generated for debuginfo where a bit sketchy. It was not clearly defined when a name should be fully qualified and when not, if region parameters should be shown or not, and other things like that.
This commit makes the debuginfo module responsible for creating type names instead of using ppaux::ty_to_str() and brings type names, as they show up in the DWARF information, in line with GCC and Clang:
* The name of the type being described is unqualified. It's path is defined by its position in the namespace hierarchy.
* Type arguments are always fully qualified, no matter if they would actually be in scope at the type definition location.
Care is also taken to reliably make type names consistent across crate boundaries. That is, the code now tries make the type name the same, regardless if the type is in the local crate or reconstructed from metadata. Otherwise LLVM will complain about violating the one-definition-rule when using link-time-optimization.
This commit also removes all source location information from type descriptions because these cannot be reconstructed for types instantiated from metadata. Again, with LTO enabled, this can lead to two versions of the debuginfo type description, one with and one without source location information, which then triggers the LLVM ODR assertion.
Fortunately, source location information about types is rarely used, so this has little impact. Once source location information is preserved in metadata (#1972) it can also be reenabled for type descriptions.
Being able to index into the bytes of a string encourages
poor UTF-8 hygiene. To get a view of `&[u8]` from either
a `String` or `&str` slice, use the `as_bytes()` method.
Closes#12710.
[breaking-change]
If the diffstat is any indication this shouldn't have a huge impact but it will have some. Most changes in the `str` and `path` module. A lot of the existing usages were in tests where ascii is expected. There are a number of other legit uses where the characters are known to be ascii.
with the corresponding trait parameter bounds.
This is a version of the patch in PR #12611 by Florian Hahn, modified to
address Niko's feedback.
It does not address the issue of duplicate type parameter bounds, nor
does it address the issue of implementation-defined methods that contain
*fewer* bounds than the trait, because Niko's review indicates that this
should not be necessary (and indeed I believe it is not). A test has
been added to ensure that this works.
This will break code like:
trait Foo {
fn bar<T:Baz>();
}
impl Foo for Boo {
fn bar<T:Baz + Quux>() { ... }
// ^~~~ ERROR
}
This will be rejected because the implementation requires *more* bounds
than the trait. It can be fixed by either adding the missing bound to
the trait:
trait Foo {
fn bar<T:Baz + Quux>();
// ^~~~
}
impl Foo for Boo {
fn bar<T:Baz + Quux>() { ... } // OK
}
Or by removing the bound from the impl:
trait Foo {
fn bar<T:Baz>();
}
impl Foo for Boo {
fn bar<T:Baz>() { ... } // OK
// ^ remove Quux
}
This patch imports the relevant tests from #2687, as well as the test
case in #5886, which is fixed as well by this patch.
Closes#2687.
Closes#5886.
[breaking-change]
Being able to index into the bytes of a string encourages
poor UTF-8 hygiene. To get a view of `&[u8]` from either
a `String` or `&str` slice, use the `as_bytes()` method.
Closes#12710.
[breaking-change]
This commit hooks rustdoc into the stability index infrastructure in two
ways:
1. It looks up stability levels via the index, rather than by manual
attributes.
2. It adds stability level information throughout rustdoc output, rather
than just at the top header. In particular, a stability color (with
mouseover text) appears next to essentially every item that appears
in rustdoc's HTML output.
Along the way, the stability index code has been lightly refactored.
floating point numbers for real.
This will break code that looks like:
let mut x = 0;
while ... {
x += 1;
}
println!("{}", x);
Change that code to:
let mut x = 0i;
while ... {
x += 1;
}
println!("{}", x);
Closes#15201.
[breaking-change]
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
This can break code that looked like:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any + Send> = ...;
x.f();
Change such code to:
impl Foo for Box<Any> {
fn f(&self) { ... }
}
let x: Box<Any> = ...;
x.f();
That is, upcast before calling methods.
This is a conservative solution to #5781. A more proper treatment (see
the xfail'd `trait-contravariant-self.rs`) would take variance into
account. This change fixes the soundness hole.
Some library changes had to be made to make this work. In particular,
`Box<Any>` is no longer showable, and only `Box<Any+Send>` is showable.
Eventually, this restriction can be lifted; for now, it does not prove
too onerous, because `Any` is only used for propagating the result of
task failure.
This patch also adds a test for the variance inference work in #12828,
which accidentally landed as part of DST.
Closes#5781.
[breaking-change]
Since procs do not have lifetime bounds, we must do this to maintain
safety.
This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.
A better solution would be to add higher-rank lifetime support to procs.
However, this would be a lot of work for a feature we want to remove in
favor of unboxed closures. The corresponding "real fix" is #15067.
Closes#14036.
[breaking-change]
This will break code like:
fn f(x: &mut int) {}
let mut a = box 1i;
f(a);
Change it to:
fn f(x: &mut int) {}
let mut a = box 1i;
f(&mut *a);
RFC 33; issue #10504.
[breaking-change]
r? @brson
vector-reference-to-unsafe-pointer-to-element cast if the type to be
casted to is not fully specified.
This is a conservative change to fix the user-visible symptoms of the
issue. A more flexible treatment would delay cast checks to after
function typechecking.
This can break code that did:
let x: *u8 = &([0, 0]) as *_;
Change this code to:
let x: *u8 = &([0, 0]) as *u8;
Closes#14893.
[breaking-change]
This will break code like:
fn f(x: &mut int) {}
let mut a = box 1i;
f(a);
Change it to:
fn f(x: &mut int) {}
let mut a = box 1i;
f(&mut *a);
RFC 33; issue #10504.
[breaking-change]
The f128 type has very little support in the compiler and the feature is
basically unusable today. Supporting half-baked features in the compiler can be
detrimental to the long-term development of the compiler, and hence this feature
is being removed.
bindings.
This will break code that incorrectly did things like:
fn f(a @ box b: Box<String>) {}
Fix such code to not rely on undefined behavior.
Closes#12534.
[breaking-change]
This breaks a fair amount of code. The typical patterns are:
* `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`;
* `println!("{}", 3)`: change to `println!("{}", 3i)`;
* `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`.
RFC #30. Closes#6023.
[breaking-change]
The f128 type has very little support in the compiler and the feature is
basically unusable today. Supporting half-baked features in the compiler can be
detrimental to the long-term development of the compiler, and hence this feature
is being removed.
Also change some code formatting.
lint::builtin becomes a sibling of lint::context in order to ensure that lints
implemented there use the same public API as lint plugins.
We're going to have more modules under lint, and the paths get unwieldy. We
also plan to have lints run at multiple points in the compilation pipeline.
The aim of these changes is not working out a generic bi-endianness architectures support but to allow people develop for little endian MIPS machines (issue #7190).
This is just a cleanup of the code. Doesn't really change anything deep about the way we operate. This is a prelude to implementing a good solution for one-way matching for #5527.
r? @pnkfelix (we were just crawling about this code, after all)
In other words, Late-bound regions that occur non-free should be
skipped.
Fix#10846 (specifically the ICE, not the weakness in the current type inference).
We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.
Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.
First, we have to fix some bugs concerning the handling of
attributes in foreign function declarations and calls. These
are required because the i1 type needs the ZExt attribute when
used as a function parameter or return type.
Then we have to update LLVM to get a bugfix without which LLVM
sometimes generates broken code when using i1.
And then, finally, we can switch bools over to i1.
We currently compiled bools to i8 values, because there was a bug in
LLVM that sometimes caused miscompilations when using i1 in, for
example, structs.
Using i8 means a lot of unnecessary zero-extend and truncate operations
though, since we have to convert the value from and to i1 when using for
example icmp or br instructions. Besides the unnecessary overhead caused
by this, it also sometimes made LLVM miss some optimizations.
Fixes#8106.
To fix#8106, we need an LLVM version that contains r211082 aka 0dee6756
which fixes a bug that blocks that issue.
There have been some tiny API changes in LLVM, and cmpxchg changed its
return type. The i1 part of the new return type is only interesting when
using the new weak cmpxchg, which we don't do.
When calling a foreign function, some arguments and/or return value
attributes are required to conform to the foreign ABI. Currently those
attributes are only added to the declaration of foreign functions. With
direct calls, this is no problem, because LLVM can see that those
attributes apply to the call. But with an indirect call, LLVM cannot do
that and the attribute is missing.
To fix that, we have to add those attribute to the calls to foreign
functions as well.
This also allows to remove the special handling of the SRet attribute,
which is ABI-dependent and will be set via the `attr` field of the
return type's `ArgType`.
The ArgType type gives us a generic way to specify an attribute for a
type to ensure ABI conformance for foreign functions. But the code that
actually sets the argument attributes in the function declaration
only sets the attribute for the return type when the type is indirect.
Since LLVMAddAttribute() doesn't allow to set attributes on the return
type, we have to use LLVMAddFunctionAttribute() instead.
This didn't cause problems yet, because currently only some indirect
types require attributes to be set.
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
Closes#13540.
This commit makes several changes to the stability index infrastructure:
* Stability levels are now inherited lexically, i.e., each item's
stability level becomes the default for any nested items.
* The computed stability level for an item is stored as part of the
metadata. When using an item from an external crate, this data is
looked up and cached.
* The stability lint works from the computed stability level, rather
than manual stability attribute annotations. However, the lint still
checks only a limited set of item uses (e.g., it does not check every
component of a path on import). This will be addressed in a later PR,
as part of issue #8962.
* The stability lint only applies to items originating from external
crates, since the stability index is intended as a promise to
downstream crates.
* The "experimental" lint is now _allow_ by default. This is because
almost all existing crates have been marked "experimental", pending
library stabilization. With inheritance in place, this would generate
a massive explosion of warnings for every Rust program.
The lint should be changed back to deny-by-default after library
stabilization is complete.
* The "deprecated" lint still warns by default.
The net result: we can begin tracking stability index for the standard
libraries as we stabilize, without impacting most clients.
Closes#13540.
Closes#14480 (vim: Add :RustRun and associated commands)
Closes#14917 (Deprecate free-standing endian conversions in favor of methods on Int. Merge Bitwise into Int and add more bit operations.)
Closes#14981 (librustc: Use expr_ty_adjusted in trans_overloaded_call.)
Closes#14989 (std::task - Revamp TaskBuilder API)
Closes#14997 (Reject double moves out of array elements)
Closes#14998 (Vim: highlight escapes for byte literals.)
Closes#15002 (Fix FIXME #5275)
Closes#15004 (Fix#14865)
Closes#15007 (debuginfo: Add test case for issue #14411.)
Closes#15012 ((doc) Change search placeholder text.)
Closes#15013 (Update compiler-rt.)
Closes#15017 (Deprecate the bytes!() macro.)
Replace its usage with byte string literals, except in `bytes!()` tests.
Also add a new snapshot, to be able to use the new b"foo" syntax.
The src/etc/2014-06-rewrite-bytes-macros.py script automatically
rewrites `bytes!()` invocations into byte string literals.
Pass it filenames as arguments to generate a diff that you can inspect,
or `--apply` followed by filenames to apply the changes in place.
Diffs can be piped into `tip` or `pygmentize -l diff` for coloring.
Fixes a codegen bug which generates illegal non-terminated LLVM block
when there are wildcard pattern with guard and enum patterns in a match
expression. Also refactors the code a little.
Closes#14865
Details: in a program like:
```
type T = proc(int) -> int; /* 4 */
pub fn outer(captured /* pat 16 */: T) -> T {
(proc(x /* pat 23 */) {
((captured /* 29 */).foo((x /* 30 */)) /* 28 */)
} /* block 27 */ /* 20 */)
} /* block 19 */ /* 12 */
```
the `captured` arg is moved from the outer fn into the inner proc (id=20).
The old dataflow analysis for flowed_move_data_moves, when looking at
the inner proc, would attempt to add a kill bit for `captured` at the
end of its scope; the problem is that it thought the end of the
`captured` arg's scope was the outer fn (id=12), even though at that
point in the analysis, the `captured` arg's scope should now be
restricted to the proc itself (id=20).
This patch fixes handling of upvars so that dataflow of a fn/proc
should never attempts to add a gen or kill bit to any NodeId outside
of the current fn/proc. It accomplishes this by adding an `LpUpvar`
variant to `borrowck::LoanPath`, so for cases like `captured` above
will carry both their original `var_id`, as before, as well as the
`NodeId` for the closure that is capturing them.
As a drive-by fix to another occurrence of a similar bug that
nikomatsakis pointed out to me earlier, this also fixes
`gather_loans::compute_kill_scope` so that it computes the kill scope
of the `captured` arg to be block 27; that is, the block for the proc
itself (id=20).
(This is an updated version that generalizes the new loan path variant
to cover all upvars, and thus renamed the variant from `LpCopiedUpvar`
to just `LpUpvar`.)
Fix#6298.
This is instead of the prior approach of emulating cfg traversal
privately by traversing AST in same way).
Of special note, this removes a special case handling of `ExprParen`
that was actually injecting a bug (since it was acting like an
expression like `(*func)()` was consuming `*func` *twice*: once from
`(*func)` and again from `*func`). nikomatsakis was the first one to
point out that it might suffice to simply have the outer `ExprParen`
do the consumption of the contents (alone).
(This version has been updated to incorporate feedback from Niko's
review of PR 14873.)
1. After recursively processing an ExprWhile, need to pop loop_scopes
the same way we do for ExprLoop.
2. Proposed fix for flowgraph handling of ExprInlineAsm: we need to
represent the flow into the subexpressions of an `asm!` block.
See #14646 (tracking issue) and rust-lang/rfcs#69.
This does not close the tracking issue, as the `bytes!()` macro still needs to be removed. It will be later, after a snapshot is made with the changes in this PR, so that the new syntax can be used when bootstrapping the compiler.
Use ty_rptr/ty_uniq(ty_trait) rather than TraitStore to represent trait types.
Also addresses (but doesn't close) #12470.
Part of the work towards DST (#12938).
Use ty_rptr/ty_uniq(ty_trait) rather than TraitStore to represent trait types.
Also addresses (but doesn't close) #12470.
Part of the work towards DST (#12938).
[breaking-change] lifetime parameters in `&mut trait` are now invariant. They used to be contravariant.
`#[inline(never)]` is used.
Closes#8958.
This can break some code that relied on the addresses of statics
being distinct; add `#[inline(never)]` to the affected statics.
[breaking-change]
r? @brson
`#[inline(never)]` is used.
Closes#8958.
This can break some code that relied on the addresses of statics
being distinct; add `#[inline(never)]` to the affected statics.
[breaking-change]
Closes#14888 (Allow disabling jemalloc as the memory allocator)
Closes#14905 (rustc: Improve span for error about using a method as a field.)
Closes#14920 (Fix#14915)
Closes#14924 (Add a Syntastic plugin for Rust.)
Closes#14935 (debuginfo: Correctly handle indirectly recursive types)
Closes#14938 (Reexport `num_cpus` in `std::os`. Closes#14707)
Closes#14941 (std: Don't fail the task when a Future is dropped)
Closes#14942 (rustc: Don't mark type parameters as exported)
Closes#14943 (doc: Fix a link in the FAQ)
Closes#14944 (Update "use" to "uses" on ln186)
Closes#14949 (Update repo location)
Closes#14950 (fix typo in the libc crate)
Closes#14951 (Update Sublime Rust github link)
Closes#14953 (Fix --disable-rpath and tests)
So far handling some indirectly recursive types, such as pointer types, has relied on LLVM metadata uniquing in a very implicit way. This could cause some inconsistencies in the debuginfo, and sometimes to hard to trace LLVM assertions.
With this commit unique type IDs and the TypeMap are used to explicitly make sure that no inconsistencies exist, and, if in the future some regression re-introduces one, give a better error message instead of the hard-to-interpret LLVM error.
The last remaining use of each_in_scope_restriction in
check_for_assignment_to_restricted_or_frozen_location is using the
pattern captured by each_in_scope_loan_affecting_path, so it can be
removed.
Currently, check_for_assignment_to_restricted_or_frozen_location bails
out early when looking for loaned base paths when it hits an McDeclared
or McImmutable extension. With the current type system, this is actually
irrelevant, since mutation can only occur given a unique mutable access
path, forcing the same requirement on each base path.
The only caller of check_for_assignment_to_restricted_or_frozen_location
isn't checking its return value, so we can remove it and simplify the
internal logic of the function.
Now that RestrictionSet is no longer being used for anything meaningful,
it can be removed, along with any other associated functions and
RestrictionSet fields of other types.
Switch to checking BorrowKind values of loans instead of their
RestrictionSet values. This was the last code that made a decision
based on a RestrictionSet.
This removes all remnants of `@` pointers from rustc. Additionally, this removes
the `GC` structure from the prelude as it seems odd exporting an experimental
type in the prelude by default.
Closes#14193
[breaking-change]
Move analyze_restrictions_on_use and check_if_path_is_moved so that all
of the code related to assignments is in a contiguous block at the end
of the file.
Implement the stronger guarantees for mutable borrows from #12624. This
removes the ability to read from a mutably borrowed path for the
duration of the borrow, and enforces a unique access path for any
mutable borrow, for both reads and writes.
This makes mutable borrows work better with concurrent accesses from
multiple threads, and it opens the door for allowing moves out of
mutably borrowed values, as long as a new value is written before the
mutable borrow ends. This also aligns Rust more closely with academic
languages based on substructural types and separation logic.
The most common situation triggering an error after this change is a
call to a function mutably borrowing self with self.field as one of the
arguments. The workaround is to bind self.field to a temporary, but the
need for these temporaries will hopefully go away after #6268 is fixed.
Another situation that triggers an error is using the head expression of
a match in an arm that binds a variable with a mutable reference. The
use of the head expression needs to be replaced with an expression that
reconstructs it from match-bound variables.
This fixes#12624.
[breaking-change]
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.
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]
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]
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 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.
Fixes#13681.
* 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.
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.
[breaking-change]
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.
[breaking-change]
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>
[breaking-change]
If this breaks your code, take a deep breath, go for a walk, and
consider why you're relying on the sign extension semantics of
enum-to-float casts.
[breaking-change]
Closes#8230.
This uncovered some dead code, most notably in middle/liveness.rs, which I think suggests there must be something fishy with that part of the code.
The #[allow(dead_code)] annotations on some of the fields I am not super happy about but as I understand, marker type may disappear at some point.
Previously, constants used unsigned extension, while non-constants used
signed extension. This unifies both paths to use signed extension.
If this breaks your code, take a deep breath, go for a walk, and
consider why you're relying on the sign extension semantics of
enum-to-float casts.
Closes#8230.
[breaking-change]
All rust functions are internal implementation details with respect to the ABI
exposed by crates, but extern fns are public components of the ABI and shouldn't
be stripped. This commit serializes reachable extern fns to metadata, so when
LTO is performed all of their symbols are not stripped.
Closes#14500
This commit carries out the request from issue #14678:
> The method `Iterator::len()` is surprising, as all the other uses of
> `len()` do not consume the value. `len()` would make more sense to be
> called `count()`, but that would collide with the current
> `Iterator::count(|T| -> bool) -> unit` method. That method, however, is
> a bit redundant, and can be easily replaced with
> `iter.filter(|x| x < 5).count()`.
> After this change, we could then define the `len()` method
> on `iter::ExactSize`.
Closes#14678.
[breaking-change]
Division and remainder by 0 are undefined behavior, and are detected at runtime.
This commit adds support for ensuring that MIN / -1 is also checked for at
runtime, as this would cause signed overflow, or undefined behvaior.
Closes#8460
Currently it is not possible to distinguish moves caused by captures
in the ExprUseVisitor interface. Since check_Loans needs to make that
distinction for generating good diagnostics, this is necessary for
check_loans to switch to ExprUseVisitor.
This isn't necessary right now, but check_loans needs to be able to
distinguish between initialization and writes in the ExprUseVisitor
mutate callback.
Currently mem_categorization categorizes an AutoObject adjustment the
same as the original expression. This can cause two moves to be
generated for the same underlying expression. Currently this isn't a
problem in practice, since check_loans doesn't rely on ExprUseVisitor.
Refactor a number of functions in check_loans to take node IDs and spans
rather than taking expressions directly. Also rename some variables to
make them less ambiguous.
This is the first step towards using ExprUseVisitor in check_loans, as
now some of the interfaces more closely match those used in
ExprUseVisitor.
