| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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)
|
|
r=alexcrichton
closes #23620
This PR patches the issue mentioned in #23620, but there is also an ICE for invalid escape sequences in byte literals. This is due to the fact that the `scan_byte` function returns ` token::intern(\"??\") ` for invalid bytes, resulting in an ICE later on. Is there a reason for this behavior? Shouldn't `scan_byte` fail when it encounters an invalid byte?
And I noticed a small inconsistency in the documentation. According to the formal byte literal definition in http://doc.rust-lang.org/reference.html#byte-and-byte-string-literals , a byte string literal contains `string_body *`, but according to the text (and the behavior of the lexer) it should not accept unicode escape sequences. Hence it should be replaced by `byte_body *`. If this is valid, I can add this fix to this PR.
|
|
Closes #22608
|
|
|
|
|
|
RFC pending, but this is the patch that does it.
Totally untested. Likely needs some removed imports. std::collections docs should also be updated to provide better examples.
Closes #23508
|
|
|
|
|
|
|
|
|
|
Closes #22608
|
|
|
|
|
|
|
|
semantics that tests the *interface* of trait objects, rather
than what they close over.
|
|
This PR allows the quote macros to unquote trait items, impl items, where clauses, and paths.
|
|
|
|
before:
test bench_read_slice ... bench: 68 ns/iter (+/- 56)
test bench_read_vec ... bench: 78 ns/iter (+/- 21)
test bench_write_slice ... bench: 133 ns/iter (+/- 46)
test bench_write_vec ... bench: 308 ns/iter (+/- 69)
after:
test bench_read_slice ... bench: 32 ns/iter (+/- 10)
test bench_read_vec ... bench: 32 ns/iter (+/- 8)
test bench_write_slice ... bench: 53 ns/iter (+/- 12)
test bench_write_vec ... bench: 247 ns/iter (+/- 172)
|
|
This PR adds support for associated types to the `#[derive(...)]` syntax extension. In order to do this, it switches over to using where predicates to apply the type constraints. So now this:
```rust
type Trait {
type Type;
}
#[derive(Clone)]
struct Foo<A> where A: Trait {
a: A,
b: <A as Trait>::Type,
}
```
Gets expended into this impl:
```rust
impl<A: Clone> Clone for Foo<A> where
A: Trait,
<A as Trait>::Type: Clone,
{
fn clone(&self) -> Foo<T> {
Foo {
a: self.a.clone(),
b: self.b.clone(),
}
}
}
```
|
|
This commits adds back an `IpAddr` enum matching the `SocketAddr` enum, but
without a port. The enumeration is `#[unstable]`. The `lookup_host` function and
iterator are also destabilized behind a new feature gate due to questions around
the semantics of returning `SocketAddr` values.
|
|
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
|
|
|
|
|
|
This doesn't actually solve the issue that prompted this, at:
https://github.com/rust-lang/rust/blob/master/src/librustc/session/mod.rs#L262-271
But skimming the cfg it appears that all type information has been
discarded long before that point.
|
|
It's considered an error to access stdout while a process is being shut down, so
tweak this test a bit to actually wait for the child thread to exit.
This was discovered with a recent [snap-mac3 failure](http://buildbot.rust-lang.org/builders/snap3-mac/builds/164/steps/test/logs/stdio)
|
|
This commits adds back an `IpAddr` enum matching the `SocketAddr` enum, but
without a port. The enumeration is `#[unstable]`. The `lookup_host` function and
iterator are also destabilized behind a new feature gate due to questions around
the semantics of returning `SocketAddr` values.
|
|
It's considered an error to access stdout while a process is being shut down, so
tweak this test a bit to actually wait for the child thread to exit.
|
|
1. when mac-android cross compile and make-check , make it use gdb instead of lldb so as to it passes debuginfo tests.
2. ignore some tests on aarch64
|
|
Now that we check the stability of fields, the fields of this struct should also
be stable.
|
|
When built with `rustc -O`:
before:
test bench_read_slice ... bench: 68 ns/iter (+/- 56)
test bench_read_vec ... bench: 78 ns/iter (+/- 21)
test bench_write_slice ... bench: 133 ns/iter (+/- 46)
test bench_write_vec ... bench: 308 ns/iter (+/- 69)
after:
test bench_read_slice ... bench: 32 ns/iter (+/- 10)
test bench_read_vec ... bench: 32 ns/iter (+/- 8)
test bench_write_slice ... bench: 53 ns/iter (+/- 12)
test bench_write_vec ... bench: 247 ns/iter (+/- 172)
|
|
The reassignment checker effectively only checks whether the last
assignment in a body affects the discriminant, but it should of course
check all the assignments.
Fixes #23698
|
|
`PathBuf::new` have been changed. Use `PathBuf::from` instead.
Apply the same change for freebsd too, while here.
|
|
Disable overflow checking on SIMD operations, fix #23037
|
|
r? @aturon cc @alexcrichton
|
|
The reassignment checker effectively only checks whether the last
assignment in a body affects the discriminant, but it should of course
check all the assignments.
Fixes #23698
|
|
Main motivation was to update docs for the removal or "demotion" of certain extension traits. The update to the slice docs was larger, since the text was largely outdated.
|
|
Fixes #23564
|
|
|
|
Makes Vec::push considerably smaller: 25 instructions, rather than 42, on
x86_64.
|
|
`PathBuf::new` have been changed. Use `PathBuf::from` instead.
Apply the same change for freebsd too, while here.
|
|
Disable overflow checking on SIMD operations, fix #23037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 #8142
Fix #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
|
