| Age | Commit message (Collapse) | Author | Lines |
|
Unwinding across an FFI boundary is undefined behaviour, so we can mark
all external function as nounwind. The obvious exception are those
functions that actually perform the unwinding.
|
|
|
|
These commits move libcore into a state so that it's ready for stabilization, performing some minor cleanup:
* The primitive modules for integers in the standard library were all removed from the source tree as they were just straight reexports of the libcore variants.
* The `core::atomic` module now lives in `core::sync::atomic`. The `core::sync` module is otherwise empty, but ripe for expansion!
* The `core::prelude::v1` module was stabilized after auditing that it is a subset of the standard library's prelude plus some primitive extension traits (char, str, and slice)
* Some unstable-hacks for float parsing errors were shifted around to not use the same unstable hacks (e.g. the `flt2dec` module is now used for "privacy").
After this commit, the remaining large unstable functionality specific to libcore is:
* `raw`, `intrinsics`, `nonzero`, `array`, `panicking`, `simd` -- these modules are all unstable or not reexported in the standard library, so they're just remaining in the same status quo as before
* `num::Float` - this extension trait for floats needs to be audited for functionality (much of that is happening in #27823) and may also want to be renamed to `FloatExt` or `F32Ext`/`F64Ext`.
* Should the extension traits for primitives be stabilized in libcore?
I believe other unstable pieces are not isolated to just libcore but also affect the standard library.
cc #27701
|
|
Implemented #27759
Example:

|
|
Overload the operators using the traits so that things mostly keep
working during the deprecation period.
|
|
|
|
This functionality will be available out of tree in the `simd` crate on
crates.io.
[breaking-change]
|
|
This mirrors the same hierarchy in the standard library.
|
|
|
|
|
|
* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed
|
|
* Lots of core prelude imports removed
* Makefile support for MSVC env vars and Rust crates removed
* Makefile support for morestack removed
|
|
Also fixes a few outdated links.
|
|
This commit is an implementation of [RFC 1184][rfc] which tweaks the behavior of
the `#![no_std]` attribute and adds a new `#![no_core]` attribute. The
`#![no_std]` attribute now injects `extern crate core` at the top of the crate
as well as the libcore prelude into all modules (in the same manner as the
standard library's prelude). The `#![no_core]` attribute disables both std and
core injection.
[rfc]: https://github.com/rust-lang/rfcs/pull/1184
|
|
There are still problems in both the design and implementation of this, so we don't want it landing in 1.2.
cc @arielb1 @nikomatsakis
cc #27364
r? @alexcrichton
|
|
There are multiple issues with them as designed and implemented.
cc #27364
|
|
This isn't actually necessary any more with the advent of `$crate` and changes
in the compiler to expand macros to `::core::$foo` in the context of a
`#![no_std]` crate.
The libcore inner module was also trimmed down a bit to the bare bones.
|
|
Having the primitive and module docs derived from the same source
causes problems, primarily that they can't contain hyperlinks
cross-referencing each other.
This crates dedicated private modules in `std` to document the
primitive types, then for all primitives that have a corresponding
module, puts hyperlinks in moth the primitive docs and the module docs
cross-linking each other.
This should help clear up confusion when readers find themselves on
the wrong page.
|
|
This commit shards the broad `core` feature of the libcore library into finer
grained features. This split groups together similar APIs and enables tracking
each API separately, giving a better sense of where each feature is within the
stabilization process.
A few minor APIs were deprecated along the way:
* Iterator::reverse_in_place
* marker::NoCopy
|
|
|
|
Helps prevent mixed content warnings if accessing docs over HTTPS.
Closes #25459
|
|
|
|
This API was exercised in a few tests and mirrors the `from_str_radix`
functionality of the integer types.
|
|
|
|
Fix #15523.
|
|
sidesteps a coherence difficulty where `liballoc` had to prove that
`&str: !Error`, which didn't involve any local types.
|
|
`Fn` traits are considered fundamental, along with `Box` (though that is
mostly for show; the real type is `~T` in the compiler).
|
|
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
|
|
Conflicts:
src/librustc/middle/ty.rs
src/librustc_trans/trans/adt.rs
src/librustc_typeck/check/mod.rs
src/libserialize/json.rs
src/test/run-pass/spawn-fn.rs
|
|
semantics that tests the *interface* of trait objects, rather
than what they close over.
|
|
Now that support has been removed, all lingering use cases are renamed.
|
|
Conflicts:
src/compiletest/compiletest.rs
src/libcollections/lib.rs
src/librustc_back/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
src/libtest/lib.rs
src/test/run-make/rustdoc-default-impl/foo.rs
src/test/run-pass/env-home-dir.rs
|
|
This commit:
* Introduces `std::convert`, providing an implementation of
RFC 529.
* Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all
in favor of the corresponding generic conversion traits.
Consequently, various IO APIs now take `AsRef<Path>` rather than
`AsPath`, and so on. Since the types provided by `std` implement both
traits, this should cause relatively little breakage.
* Deprecates many `from_foo` constructors in favor of `from`.
* Changes `PathBuf::new` to take no argument (creating an empty buffer,
as per convention). The previous behavior is now available as
`PathBuf::from`.
* De-stabilizes `IntoCow`. It's not clear whether we need this separate trait.
Closes #22751
Closes #14433
[breaking-change]
|
|
|
|
|
|
Fixes #23059
|
|
|
|
Fixes #23059
|
|
|
|
These return the result of the operation *plus* an overflow/underflow bit.
This can make it easier to write operations where you want to chain
some arithmetic together, but also want to return a flag signalling if
overflow every occurred.
|
|
|
|
This is one more step towards completing #13231
This series of commits add support for default trait implementations. The changes in this PR don't break existing code and they are expected to preserve the existing behavior in the compiler as far as built-in bounds checks go.
The PR adds negative implementations of `Send`/`Sync` for some types and it removes the special cases for `Send`/`Sync` during the trait obligations checks. That is, it now fully relies on the traits check rather than lang items.
Once this patch lands and a new snapshot is created, it'll be possible to add default impls for `Send` and `Sync` and remove entirely the use of `BuiltinBound::{BoundSend,BoundSync}` for positive implementations as well.
This PR also removes the restriction on negative implementations. That is, it is now possible to add negative implementations for traits other than `Send`/`Sync`
|
|
|
|
|
|
This commit stabilizes `std::borrow`, making the following modifications
to catch up the API with language changes:
* It renames `BorrowFrom` to `Borrow`, as was originally intended (but
blocked for technical reasons), and reorders the parameters
accordingly.
* It moves the type parameter of `ToOwned` to an associated type. This
is somewhat less flexible, in that each borrowed type must have a
unique owned type, but leads to a significant simplification for
`Cow`. Flexibility can be regained by using newtyped slices, which is
advisable for other reasons anyway.
* It removes the owned type parameter from `Cow`, making the type much
less verbose.
* Deprecates the `is_owned` and `is_borrowed` predicates in favor of
direct matching.
The above API changes are relatively minor; the basic functionality
remains the same, and essentially the whole module is now marked
`#[stable]`.
[breaking-change]
|
|
|
|
|
|
|
|
Fixes #22085
|
|
Fixes #21833.
[breaking-change]
|