the plan is to treat all binary operators as if they were overloaded,
relying on the fact that we have impls for all the builtin scalar
operations (and no more). But then during writeback we clear the
overload if the types correspond to a builtin op.
This strategy allows us to avoid having to know the types of the
operands ahead of time. It also avoids us overspecializing as we did in
the past.
`std::dynamic_library` is currently using `std::old_io::Path` specifically. This change brings the API in alignment with `std::fs::File` by having it take `std::path::AsPath`. The Windows code should work, but I admittedly haven't tried it (I don't have a Windows machine readily available right now).
r? @alexcrichton
When testing whether a default method predicates are satisfiable,
combine normalization with this check so that we also skip the
default method if normalization fails. Fixes#23485.
r? @nrc (I tried to address your nit from before as well)
This commit removes parser support for `extern crate "foo" as bar` as the
renamed crate is now required to be an identifier. Additionally this commit
enables hard errors on crate names that contain hyphens in them, they must now
solely contain alphanumeric characters or underscores.
If the crate name is inferred from the file name, however, the file name
`foo-bar.rs` will have the crate name inferred as `foo_bar`. If a binary is
being emitted it will have the name `foo-bar` and a library will have the name
`libfoo_bar.rlib`.
This commit is a breaking change for a number of reasons:
* Old syntax is being removed. This was previously only issuing warnings.
* The output for the compiler when input is received on stdin is now `rust_out`
instead of `rust-out`.
* The crate name for a crate in the file `foo-bar.rs` is now `foo_bar` which can
affect infrastructure such as logging.
[breaking-change]
Found a few 404s that seemed like simple fixes:
In footer.inc, certain 404 pages were 404ing on the request to jquery.js and playpen.js. This is easily demonstrated by visiting http://doc.rust-lang.org/foo then http://doc.rust-lang.org/foo/bar. The latter 404s, looking for foo/jquery.js.
The Result docs use old_io Writer as an example. Fix the link to old_io Writer. There's probably an effort to update the example away from a deprecated api but this was a simple fix.
rustc/plugin was pointing at the old guide and it was a broken link anyways (plugin vs plugins). Point at the book instead.
The main page of the API docs referenced c_{str,vec}. Looks like these were deleted in 25d5a3a194. Point at ffi docs instead.
This PR introduces a `Reflect` marker trait which is a supertrait of `Any`. The idea is that `Reflect` is defined for all concrete types, but is not defined for type parameters unless there is a `T:Reflect` bound. This is intended to preserve the parametricity property. This allows the `Any` interface to be stabilized without committing us to unbounded reflection that is not easily detectable by the caller.
The implementation of `Reflect` relies on an experimental variant of OIBIT. This variant behaves differently for objects, since it requires that all types exposed as part of the object's *interface* are `Reflect`, but isn't concerned about other types that may be closed over. In other words, you don't have to write `Foo+Reflect` in order for `Foo: Reflect` to hold (where `Foo` is a trait).
Given that `Any` is slated to stabilization and hence that we are committed to some form of reflection, the goal of this PR is to leave our options open with respect to parametricity. I see the options for full stabilization as follows (I think an RFC would be an appropriate way to confirm whichever of these three routes we take):
1. We make `Reflect` a lang-item.
2. We stabilize some version of the OIBIT variation I implemented as a general mechanism that may be appropriate for other use cases.
3. We give up on preserving parametricity here and just have `impl<T> Reflect for T` instead. In that case, `Reflect` is a harmless but not especially useful trait going forward.
cc @aturon
cc @alexcrichton
cc @glaebhoerl (this is more-or-less your proposal, as I understood it)
cc @reem (this is more-or-less what we discussed on IRC at some point)
cc @FlaPer87 (vaguely pertains to OIBIT)
Replace zeroing-on-drop with filling-on-drop.
This is meant to set the stage for removing *all* zeroing and filling (on drop) in the future.
Note that the code is meant to be entirely abstract with respect to the particular values used for the drop flags: the final commit demonstrates how to go from zeroing-on-drop to filling-on-drop by changing the value of three constants (in two files).
See further discussion on the internals thread:
http://internals.rust-lang.org/t/attention-hackers-filling-drop/1715/11
[breaking-change] especially for structs / enums using `#[unsafe_no_drop_flag]`.
Found a few 404s that seemed like simple fixes:
The Result docs use old_io Writer as an example. Fix the link to old_io Writer. There's probably an effort to update the example away from a deprecated api but this was a simple fix.
rustc/plugin was pointing at the old guide and it was a broken link anyways (plugin vs plugins). Point at the book instead.
The main page of the API docs referenced c_{str,vec}. Looks like these were deleted in 25d5a3a194. Point at ffi docs instead.
I've started on refactoring the error handling code to avoid the need to reparse generated errors in `span_*`, but would rather land this incrementally as one monolithic PR (and have un-fond memories of merge conflicts from various other monoliths)
r? @eddyb
Reject specialized Drop impls.
See Issue #8142 for discussion.
This makes it illegal for a Drop impl to be more specialized than the original item.
So for example, all of the following are now rejected (when they would have been blindly accepted before):
```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type
struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region
struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement
struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```
Due to examples like the above, this is a [breaking-change].
(The fix is to either remove the specialization from the `Drop` impl, or to transcribe the requirements into the struct/enum definition; examples of both are shown in the PR's fixed to `libstd`.)
----
This is likely to be the last thing blocking the removal of the `#[unsafe_destructor]` attribute.
Fix#8142Fix#23584
The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.
This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.
cc #23533
The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.
This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.
cc #23533
The primary motivation here is to sidestep #19032 -- for a time, I thought that we should improve coherence or otherwise extend the language, but I now think that any such changes will require more time to bake. In the meantime, inheritance amongst the fn traits is both logically correct *and* a simple solution to that obstacle. This change introduces inheritance and modifies the compiler so that it can properly generate impls for closures and fns.
Things enabled by this PR (but not included in this PR):
1. An impl of `FnMut` for `&mut F` where `F : FnMut` (https://github.com/rust-lang/rust/issues/23015).
2. A better version of `Thunk` I've been calling `FnBox`.
I did not include either of these in the PR because:
1. Adding the impls in 1 currently induces a coherence conflict with the pattern trait. This is interesting and merits some discussion.
2. `FnBox` deserves to be a PR of its own.
The main downside to this design is (a) the need to write impls by hand; (b) the possibility of implementing `FnMut` with different semantics from `Fn`, etc. Point (a) is minor -- in particular, it does not affect normal closure usage -- and could be addressed in the future in many ways (better defaults; convenient macros; specialization; etc). Point (b) is unfortunate but "just a bug" from my POV, and certainly not unique to these traits (c.f. Copy/Clone, PartialEq/Eq, etc). (Until we lift the feature-gate on implementing the Fn traits, in any case, there is room to correct both of these if we find a nice way.)
Note that I believe this change is reversible in the future if we decide on another course of action, due to the feature gate on implementing the `Fn` traits, though I do not (currently) think we should reverse it.
Fixes#18835.
r? @nrc
See Issue 8142 for discussion.
This makes it illegal for a Drop impl to be more specialized than the
original item.
So for example, all of the following are now rejected (when they would
have been blindly accepted before):
```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type
struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region
struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement
struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```
Due to examples like the above, this is a [breaking-change].
(The fix is to either remove the specialization from the `Drop` impl,
or to transcribe the requirements into the struct/enum definition;
examples of both are shown in the PR's fixed to `libstd`.)
----
This is likely to be the last thing blocking the removal of the
`#[unsafe_destructor]` attribute.
Includes two new error codes for the new dropck check.
Update run-pass tests to accommodate new dropck pass.
Update tests and docs to reflect new destructor restriction.
----
Implementation notes:
We identify Drop impl specialization by not being as parametric as the
struct/enum definition via unification.
More specifically:
1. Attempt unification of a skolemized instance of the struct/enum
with an instance of the Drop impl's type expression where all of
the impl's generics (i.e. the free variables of the type
expression) have been replaced with unification variables.
2. If unification fails, then reject Drop impl as specialized.
3. If unification succeeds, check if any of the skolemized
variables "leaked" into the constraint set for the inference
context; if so, then reject Drop impl as specialized.
4. Otherwise, unification succeeded without leaking skolemized
variables: accept the Drop impl.
We identify whether a Drop impl is injecting new predicates by simply
looking whether the predicate, after an appropriate substitution,
appears on the struct/enum definition.
This permits all coercions to be performed in casts, but adds lints to warn in those cases.
Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.
[breaking change]
* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:
```
let x = 42;
let y = &x as *const u32;
```
Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:
```
let x: u32 = 42;
let y = &x as *const u32;
```
This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.
r? @japaric
cc @aturon @Gankro
Don't allow upcasting to a supertype in the type of the match discriminant. Fixes#23116.
This is a [breaking-change] in that it closes a type hole that previously existed.
r? @pnkfelix
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#22751Closes#14433
[breaking-change]
impls.
This requires:
1. modifying trait selection a bit so that when we synthesize impls for
fn pointers and closures;
2. adding code to trans so that we can synthesize a `FnMut`/`FnOnce`
impl for a `Fn` closure and so forth.
contains ref-bindings, do not permit any upcasting from the type of
the value being matched. Similarly, do not permit coercion in a `let`.
This is a [breaking-change] in that it closes a type hole that
previously existed, and in that coercion is not performed. You should
be able to work around the latter by converting:
```rust
let ref mut x: T = expr;
```
into
```rust
let x: T = expr;
let ref mut x = x;
```
Restricting coercion not to apply in the case of `let ref` or `let ref mut` is sort
of unexciting to me, but seems the best solution:
1. Mixing coercion and `let ref` or `let ref mut` is a bit odd, because you are taking
the address of a (coerced) temporary, but only sometimes. It's not syntactically evident,
in other words, what's going on. When you're doing a coercion, you're kind of
2. Put another way, I would like to preserve the relationship that
`equality <= subtyping <= coercion <= as-coercion`, where this is
an indication of the number of `(T1,T2)` pairs that are accepted by
the various relations. Trying to mix `let ref mut` and coercion
would create another kind of relation that is like coercion, but
acts differently in the case where a precise match is needed.
3. In any case, this is strictly more conservative than what we had
before and we can undo it in the future if we find a way to make
coercion mix with type equality.
The change to match I feel ok about but similarly unthrilled. There is
some subtle text already concerning whether to use eqtype or subtype
for identifier bindings. The best fix I think would be to always have
match use strict equality but use subtyping on identifier bindings,
but the comment `(*)` explains why that's not working at the moment.
As above, I think we can change this as we clean up the code there.
This should solve issues #23115, #23469, and #23407.
As the title says, this is just a workaround. The underlying problem is that macro expansion can produce invalid spans. I've opened issue #23480 so we don't forget about that.
This commit clarifies some of the unstable features in the `str` module by
moving them out of the blanket `core` and `collections` features.
The following methods were moved to the `str_char` feature which generally
encompasses decoding specific characters from a `str` and dealing with the
result. It is unclear if any of these methods need to be stabilized for 1.0 and
the most conservative route for now is to continue providing them but to leave
them as unstable under a more specific name.
* `is_char_boundary`
* `char_at`
* `char_range_at`
* `char_at_reverse`
* `char_range_at_reverse`
* `slice_shift_char`
The following methods were moved into the generic `unicode` feature as they are
specifically enabled by the `unicode` crate itself.
* `nfd_chars`
* `nfkd_chars`
* `nfc_chars`
* `graphemes`
* `grapheme_indices`
* `width`
Safe fns are no longer subtypes of unsafe fns, but you can coerce from one to the other.
This is a [breaking-change] in that impl fns must now be declared `unsafe` if the trait is declared `unsafe`. In some rare cases, the subtyping change may also direct affect you, but no such cases were encountered in practice.
Fixes#23449.
r? @nrc
This commit clarifies some of the unstable features in the `str` module by
moving them out of the blanket `core` and `collections` features.
The following methods were moved to the `str_char` feature which generally
encompasses decoding specific characters from a `str` and dealing with the
result. It is unclear if any of these methods need to be stabilized for 1.0 and
the most conservative route for now is to continue providing them but to leave
them as unstable under a more specific name.
* `is_char_boundary`
* `char_at`
* `char_range_at`
* `char_at_reverse`
* `char_range_at_reverse`
* `slice_shift_char`
The following methods were moved into the generic `unicode` feature as they are
specifically enabled by the `unicode` crate itself.
* `nfd_chars`
* `nfkd_chars`
* `nfc_chars`
* `graphemes`
* `grapheme_indices`
* `width`
This upcast coercion currently never requires vtable changes. It should be generalized.
This is a [breaking-change] -- if you have an impl on an object type like `impl SomeTrait`, then this will no longer be applicable to object types like `SomeTrait+Send`. In the standard library, this primarily affected `Any`, and this PR adds impls for `Any+Send` as to keep the API the same in practice. An alternate workaround is to use UFCS form or standalone fns. For more details, see <https://github.com/rust-lang/rust/issues/18737#issuecomment-78450798>.
r? @nrc
This upcast coercion currently preserves the vtable for the object, but
eventually it can be used to create a derived vtable. The upcast
coercion is not introduced into method dispatch; see comment on #18737
for information about why. Fixes#18737.
This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.
Also introduces an extensible `Error` type instead of returning an `Option`.
The type implements a destructor so you can't destructure it.
This removes the error case of the compression functions, the only errors that
can occur are incorrect parameters or an out-of-memory condition, both of which
are handled with panics in Rust.
Also introduces an extensible `Error` type instead of returning an `Option`.
This commit deprecates the `count`, `range` and `range_step` functions
in `iter`, in favor of range notation. To recover all existing
functionality, a new `step_by` adapter is provided directly on `ops::Range`
and `ops::RangeFrom`.
[breaking-change]
r? @alexcrichton
It wasn't clear to me that early_error was correct here, but it seems to
work. This code is reachable from `rustdoc`, which is problematic, because
early_error panics. rustc handles the panics gracefully (without ICEing or
crashing), but rustdoc does not. It's not the first such rustdoc problem,
though:
$ rustdoc hello.rs --extern std=bad-std
error: extern location for std does not exist: bad-std
hello.rs:1:1: 1:1 error: can't find crate for `std`
hello.rs:1
^
error: aborting due to 2 previous errors
thread '<unnamed>' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:151
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "rustc failed"', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:744
thread '<main>' panicked at 'child thread None panicked', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/thread.rs:661
This commit deprecates the `count`, `range` and `range_step` functions
in `iter`, in favor of range notation. To recover all existing
functionality, a new `step_by` adapter is provided directly on `ops::Range`
and `ops::RangeFrom`.
[breaking-change]
The new `std::io` module has had some time to bake now, and this commit
stabilizes its functionality. There are still portions of the module which
remain unstable, and below contains a summart of the actions taken.
This commit also deprecates the entire contents of the `old_io` module in a
blanket fashion. All APIs should now have a reasonable replacement in the
new I/O modules.
Stable APIs:
* `std::io` (the name)
* `std::io::prelude` (the name)
* `Read`
* `Read::read`
* `Read::{read_to_end, read_to_string}` after being modified to return a `usize`
for the number of bytes read.
* `ReadExt`
* `Write`
* `Write::write`
* `Write::{write_all, write_fmt}`
* `WriteExt`
* `BufRead`
* `BufRead::{fill_buf, consume}`
* `BufRead::{read_line, read_until}` after being modified to return a `usize`
for the number of bytes read.
* `BufReadExt`
* `BufReader`
* `BufReader::{new, with_capacity}`
* `BufReader::{get_ref, get_mut, into_inner}`
* `{Read,BufRead} for BufReader`
* `BufWriter`
* `BufWriter::{new, with_capacity}`
* `BufWriter::{get_ref, get_mut, into_inner}`
* `Write for BufWriter`
* `IntoInnerError`
* `IntoInnerError::{error, into_inner}`
* `{Error,Display} for IntoInnerError`
* `LineWriter`
* `LineWriter::{new, with_capacity}` - `with_capacity` was added
* `LineWriter::{get_ref, get_mut, into_inner}` - `get_mut` was added)
* `Write for LineWriter`
* `BufStream`
* `BufStream::{new, with_capacities}`
* `BufStream::{get_ref, get_mut, into_inner}`
* `{BufRead,Read,Write} for BufStream`
* `stdin`
* `Stdin`
* `Stdin::lock`
* `Stdin::read_line` - added method
* `StdinLock`
* `Read for Stdin`
* `{Read,BufRead} for StdinLock`
* `stdout`
* `Stdout`
* `Stdout::lock`
* `StdoutLock`
* `Write for Stdout`
* `Write for StdoutLock`
* `stderr`
* `Stderr`
* `Stderr::lock`
* `StderrLock`
* `Write for Stderr`
* `Write for StderrLock`
* `io::Result`
* `io::Error`
* `io::Error::last_os_error`
* `{Display, Error} for Error`
Unstable APIs:
(reasons can be found in the commit itself)
* `Write::flush`
* `Seek`
* `ErrorKind`
* `Error::new`
* `Error::from_os_error`
* `Error::kind`
Deprecated APIs
* `Error::description` - available via the `Error` trait
* `Error::detail` - available via the `Display` implementation
* `thread::Builder::{stdout, stderr}`
Changes in functionality:
* `old_io::stdio::set_stderr` is now a noop as the infrastructure for printing
backtraces has migrated to `std::io`.
[breaking-change]
This implements a wish suggested in #17410, detecting enum variants that are never constructed, even in the presence of `#[derive(Clone)]`. The implementation is general and not specific to `#[derive(Clone)]`.
r? @jakub-
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` method is now `without_file` and succeeds if, and only
if, `file_name` is `Some(_)`. That means, in particular, that it fails
for a path like `foo/../`. This change affects `pop` as well.
In addition, the `old_path` module is now deprecated.
[breaking-change]
r? @alexcrichton
This commit stabilizes essentially all of the new `std::path` API. The
API itself is changed in a couple of ways (which brings it in closer
alignment with the RFC):
* `.` components are now normalized away, unless they appear at the
start of a path. This in turn effects the semantics of e.g. asking for
the file name of `foo/` or `foo/.`, both of which yield `Some("foo")`
now. This semantics is what the original RFC specified, and is also
desirable given early experience rolling out the new API.
* The `parent` function now succeeds if, and only if, the path has at
least one non-root/prefix component. This change affects `pop` as
well.
* The `Prefix` component now involves a separate `PrefixComponent`
struct, to better allow for keeping both parsed and unparsed prefix data.
In addition, the `old_path` module is now deprecated.
Closes#23264
[breaking-change]
The end result is that common fields (id, name, attributes, etc.) are stored in now-structures `ImplItem` and `TraitItem`.
The signature of a method is no longer duplicated between methods with a body (default/impl) and those without, they now share `MethodSig`.
This is also a [breaking-change] because of minor bugfixes and changes to syntax extensions:
* `pub fn` methods in a trait no longer parse - remove the `pub`, it has no meaning anymore
* `MacResult::make_methods` is now `make_impl_items` and the return type has changed accordingly
* `quote_method` is gone, because `P<ast::Method>` doesn't exist and it couldn't represent a full method anyways - could be replaced by `quote_impl_item`/`quote_trait_item` in the future, but I do hope we realize how silly that combinatorial macro expansion is and settle on a single `quote` macro + some type hints - or just no types at all (only token-trees)
r? @nikomatsakis This is necessary (hopefully also sufficient) for associated constants.
now have a simple set of trait def-ids. During coherence, we use a
separate table to track the default impls for any given trait so that we
can report a nice error. This fixes various bugs in the metadata
encoding that led to `ty::trait_has_default_impl` yielding the wrong
values in the cross-crate case. (In particular, default impl def-ids
were not included in the list of all impl def-ids; I debated fixing just
that, but this approach seemed cleaner overall, since we usually treat
the "defaulted" bit on traits as being a property of the trait, and now
iterating over a list of impls doesn't intermingle default impls with
normal impls.)
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!("{}", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
---
This updates `thread_local!` macro to use the attribute, since it uses
unstable features internally (initialising a struct with unstable
fields).
This commit performs a stabilization pass over the `std::fs` module now that
it's had some time to bake. The change was largely just adding `#[stable]` tags,
but there are a few APIs that remain `#[unstable]`.
The following apis are now marked `#[stable]`:
* `std::fs` (the name)
* `File`
* `Metadata`
* `ReadDir`
* `DirEntry`
* `OpenOptions`
* `Permissions`
* `File::{open, create}`
* `File::{sync_all, sync_data}`
* `File::set_len`
* `File::metadata`
* Trait implementations for `File` and `&File`
* `OpenOptions::new`
* `OpenOptions::{read, write, append, truncate, create}`
* `OpenOptions::open` - this function was modified, however, to not attempt to
reject cross-platform openings of directories. This means that some platforms
will succeed in opening a directory and others will fail.
* `Metadata::{is_dir, is_file, len, permissions}`
* `Permissions::{readonly, set_readonly}`
* `Iterator for ReadDir`
* `DirEntry::path`
* `remove_file` - like with `OpenOptions::open`, the extra windows code to
remove a readonly file has been removed. This means that removing a readonly
file will succeed on some platforms but fail on others.
* `metadata`
* `rename`
* `copy`
* `hard_link`
* `soft_link`
* `read_link`
* `create_dir`
* `create_dir_all`
* `remove_dir`
* `remove_dir_all`
* `read_dir`
The following apis remain `#[unstable]`.
* `WalkDir` and `walk` - there are many methods by which a directory walk can be
constructed, and it's unclear whether the current semantics are the right
ones. For example symlinks are not handled super well currently. This is now
behind a new `fs_walk` feature.
* `File::path` - this is an extra abstraction which the standard library
provides on top of what the system offers and it's unclear whether we should
be doing so. This is now behind a new `file_path` feature.
* `Metadata::{accessed, modified}` - we do not currently have a good
abstraction for a moment in time which is what these APIs should likely be
returning, so these remain `#[unstable]` for now. These are now behind a new
`fs_time` feature
* `set_file_times` - like with `Metadata::accessed`, we do not currently have
the appropriate abstraction for the arguments here so this API remains
unstable behind the `fs_time` feature gate.
* `PathExt` - the precise set of methods on this trait may change over time and
some methods may be removed. This API remains unstable behind the `path_ext`
feature gate.
* `set_permissions` - we may wish to expose a more granular ability to set the
permissions on a file instead of just a blanket \"set all permissions\" method.
This function remains behind the `fs` feature.
The following apis are now `#[deprecated]`
* The `TempDir` type is now entirely deprecated and is [located on
crates.io][tempdir] as the `tempdir` crate with [its source][github] at
rust-lang/tempdir.
[tempdir]: https://crates.io/crates/tempdir
[github]: https://github.com/rust-lang/tempdir
The stability of some of these APIs has been questioned over the past few weeks
in using these APIs, and it is intentional that the majority of APIs here are
marked `#[stable]`. The `std::fs` module has a lot of room to grow and the
material is [being tracked in a RFC issue][rfc-issue].
[rfc-issue]: rust-lang/rfcs#939
Closes#22879
[breaking-change]
This commit is an implementation of [RFC 563][rfc] which adds a new
`cfg(debug_assertions)` directive which is specially recognized and calculated
by the compiler. The flag is turned off at any optimization level greater than 1
and may also be explicitly controlled through the `-C debug-assertions`
flag.
[rfc]: https://github.com/rust-lang/rfcs/pull/563
The `debug_assert!` and `debug_assert_eq!` macros now respect this instead of
the `ndebug` variable and `ndebug` no longer holds any meaning to the standard
library.
Code which was previously relying on `not(ndebug)` to gate expensive code should
be updated to rely on `debug_assertions` instead.
Closes#22492
[breaking-change]
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!(\"{}\", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
---
This updates `thread_local!` macro to use the attribute, since it uses
unstable features internally (initialising a struct with unstable
fields).
This commit performs a stabilization pass over the `std::fs` module now that
it's had some time to bake. The change was largely just adding `#[stable]` tags,
but there are a few APIs that remain `#[unstable]`.
The following apis are now marked `#[stable]`:
* `std::fs` (the name)
* `File`
* `Metadata`
* `ReadDir`
* `DirEntry`
* `OpenOptions`
* `Permissions`
* `File::{open, create}`
* `File::{sync_all, sync_data}`
* `File::set_len`
* `File::metadata`
* Trait implementations for `File` and `&File`
* `OpenOptions::new`
* `OpenOptions::{read, write, append, truncate, create}`
* `OpenOptions::open` - this function was modified, however, to not attempt to
reject cross-platform openings of directories. This means that some platforms
will succeed in opening a directory and others will fail.
* `Metadata::{is_dir, is_file, len, permissions}`
* `Permissions::{readonly, set_readonly}`
* `Iterator for ReadDir`
* `DirEntry::path`
* `remove_file` - like with `OpenOptions::open`, the extra windows code to
remove a readonly file has been removed. This means that removing a readonly
file will succeed on some platforms but fail on others.
* `metadata`
* `rename`
* `copy`
* `hard_link`
* `soft_link`
* `read_link`
* `create_dir`
* `create_dir_all`
* `remove_dir`
* `remove_dir_all`
* `read_dir`
The following apis remain `#[unstable]`.
* `WalkDir` and `walk` - there are many methods by which a directory walk can be
constructed, and it's unclear whether the current semantics are the right
ones. For example symlinks are not handled super well currently. This is now
behind a new `fs_walk` feature.
* `File::path` - this is an extra abstraction which the standard library
provides on top of what the system offers and it's unclear whether we should
be doing so. This is now behind a new `file_path` feature.
* `Metadata::{accessed, modified}` - we do not currently have a good
abstraction for a moment in time which is what these APIs should likely be
returning, so these remain `#[unstable]` for now. These are now behind a new
`fs_time` feature
* `set_file_times` - like with `Metadata::accessed`, we do not currently have
the appropriate abstraction for the arguments here so this API remains
unstable behind the `fs_time` feature gate.
* `PathExt` - the precise set of methods on this trait may change over time and
some methods may be removed. This API remains unstable behind the `path_ext`
feature gate.
* `set_permissions` - we may wish to expose a more granular ability to set the
permissions on a file instead of just a blanket "set all permissions" method.
This function remains behind the `fs` feature.
The following apis are now `#[deprecated]`
* The `TempDir` type is now entirely deprecated and is [located on
crates.io][tempdir] as the `tempdir` crate with [its source][github] at
rust-lang/tempdir.
[tempdir]: https://crates.io/crates/tempdir
[github]: https://github.com/rust-lang/tempdir
The stability of some of these APIs has been questioned over the past few weeks
in using these APIs, and it is intentional that the majority of APIs here are
marked `#[stable]`. The `std::fs` module has a lot of room to grow and the
material is [being tracked in a RFC issue][rfc-issue].
[rfc-issue]: https://github.com/rust-lang/rfcs/issues/939
[breaking-change]
The two main sub-modules, `c_str` and `os_str`, have now had some time to bake
in the standard library. This commits performs a sweep over the modules adding
various stability tags.
The following APIs are now marked `#[stable]`
* `OsString`
* `OsStr`
* `OsString::from_string`
* `OsString::from_str`
* `OsString::new`
* `OsString::into_string`
* `OsString::push` (renamed from `push_os_str`, added an `AsOsStr` bound)
* various trait implementations for `OsString`
* `OsStr::from_str`
* `OsStr::to_str`
* `OsStr::to_string_lossy`
* `OsStr::to_os_string`
* various trait implementations for `OsStr`
* `CString`
* `CStr`
* `NulError`
* `CString::new` - this API's implementation may change as a result of
rust-lang/rfcs#912 but the usage of `CString::new(thing)` looks like it is
unlikely to change. Additionally, the `IntoBytes` bound is also likely to
change but the set of implementors for the trait will not change (despite the
trait perhaps being renamed).
* `CString::from_vec_unchecked`
* `CString::as_bytes`
* `CString::as_bytes_with_nul`
* `NulError::nul_position`
* `NulError::into_vec`
* `CStr::from_ptr`
* `CStr::as_ptr`
* `CStr::to_bytes`
* `CStr::to_bytes_with_nul`
* various trait implementations for `CStr`
The following APIs remain `#[unstable]`
* `OsStr*Ext` traits remain unstable as the organization of `os::platform` is
uncertain still and the traits may change location.
* `AsOsStr` remains unstable as generic conversion traits are likely to be
rethought soon.
The following APIs were deprecated
* `OsString::push_os_str` is now called `push` and takes `T: AsOsStr` instead (a
superset of the previous functionality).
This commit is an implementation of [RFC 563][rfc] which adds a new
`cfg(debug_assertions)` directive which is specially recognized and calculated
by the compiler. The flag is turned off at any optimization level greater than 1
and may also be explicitly controlled through the `-C debug-assertions`
flag.
[rfc]: https://github.com/rust-lang/rfcs/pull/563
The `debug_assert!` and `debug_assert_eq!` macros now respect this instead of
the `ndebug` variable and `ndebug` no longer holds any meaning to the standard
library.
Code which was previously relying on `not(ndebug)` to gate expensive code should
be updated to rely on `debug_assertions` instead.
Closes#22492
[breaking-change]
The main gist of this PR is commit 1077efb which removes the list of supertraits from the `TraitDef` and pulls them into a separate table, which is accessed via `lookup_super_predicates`. This is analogous to `lookup_predicates`, which gets the complete where clause. This allows us to create the `TraitDef`, which contains the list generics and so forth, without fully knowing the list of supertraits. This in turn allows the *supertrait listing* to contain references to associated types like `<Self as Foo>::Item`, which were previously impossible because conversion required having the `TraitDef` for `Foo`.
We do not yet support `Self::Item` in a supertrait listing. This doesn't work because to convert that, it attempts to expand out the full set of supertraits, which are in the process of being created. This could potentially be worked out by having the expansion of supertraits proceed in a lazy fashion, but we'd have to define shadowing rules for associated types which we don't currently have.
Along the way (in 9de9ec5) I also removed the restriction against duplicate bounds and generalized the code so that it can handle having the same supertrait multiple times with different arguments, e.g. `Foo : Bar<i32> + Bar<u32>`. This restriction was serving no particular purpose, since the same trait could be extended multiple times indirectly, and in the era of multidispatch it is actively harmful.
This is technically a [breaking-change] because it affects the definition of a super-trait. Anything in a where clause that looks like `where Self : Foo` is now considered a supertrait. Because cycles are disallowed in supertraits, that could lead to some errors. This has not been observed in any existing code.
r? @nrc
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!("{}", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
Automatic has-same-types testing methodology can be found in #22501.
Because most of them don't work with `--pretty=typed`, compile-fail tests were manually audited.
r? @aturon
This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.
The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.
us to construct trait-references and do other things without forcing a
full evaluation of the supertraits. One downside of this scheme is that
we must invoke `ensure_super_predicates` before using any construct that
might require knowing about the super-predicates.
This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics).
Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, line-beginnings, etc. but not the actual source code itself. We are thus missing the opportunity of making Rust the first "open-source-only" programming language out there. Pity.
Many of the modifications putting in `Box::new` calls also include a
pointer to Issue 22405, which tracks going back to `box <expr>` if
possible in the future.
(Still tried to use `Box<_>` where it sufficed; thus some tests still
have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.)
Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
