Updated e0493 to new format (+ bonus).
Part of #35233.
Fixes#35999.
r? @jonathandturner
I'm not satisfied with the bonus part, there has to be an easier way to reach into the `Drop`'s span implementation. I'm all ears. :)
rustc: Implement custom derive (macros 1.1)
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
Fixed E0529's label and unit test
Fixes#36195 part of #35233.
This is ready for review, but will likely fail Travis due to #36138. I changed the wording of the label, so feedback on that would be appreciated.
r? @jonathandturner
Update lifetime errors to specifically note temporaries
This PR updates the error message we give in the case of a temporary value not living long enough.
Before:
<img width="497" alt="screen shot 2016-08-31 at 10 02 47 am" src="https://cloud.githubusercontent.com/assets/547158/18138551/27a06794-6f62-11e6-9ee2-bdf8bed75ca7.png">
Now:
<img width="488" alt="screen shot 2016-08-31 at 10 03 01 am" src="https://cloud.githubusercontent.com/assets/547158/18138557/2e5cf322-6f62-11e6-9047-4a78abf3d78c.png">
Specifically, it makes the following changes:
* Detects if a temporary is being used. If so, it changes the labels to mention that a temporary value specifically is in question
* Simplifies wording of the existing labels to focus on lifetimes rather than values being valid
* Changes the help to a note, since the help+span wasn't as helpful (and sometimes more confusing) than just a note.
r? @nikomatsakis
This commit is an implementation of [RFC 1681] which adds support to the
compiler for first-class user-define custom `#[derive]` modes with a far more
stable API than plugins have today.
[RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md
The main features added by this commit are:
* A new `rustc-macro` crate-type. This crate type represents one which will
provide custom `derive` implementations and perhaps eventually flower into the
implementation of macros 2.0 as well.
* A new `rustc_macro` crate in the standard distribution. This crate will
provide the runtime interface between macro crates and the compiler. The API
here is particularly conservative right now but has quite a bit of room to
expand into any manner of APIs required by macro authors.
* The ability to load new derive modes through the `#[macro_use]` annotations on
other crates.
All support added here is gated behind the `rustc_macro` feature gate, both for
the library support (the `rustc_macro` crate) as well as the language features.
There are a few minor differences from the implementation outlined in the RFC,
such as the `rustc_macro` crate being available as a dylib and all symbols are
`dlsym`'d directly instead of having a shim compiled. These should only affect
the implementation, however, not the public interface.
This commit also ended up touching a lot of code related to `#[derive]`, making
a few notable changes:
* Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't
sure how to keep this behavior and *not* expose it to custom derive.
* Derive attributes no longer have access to unstable features by default, they
have to opt in on a granular level.
* The `derive(Copy,Clone)` optimization is now done through another "obscure
attribute" which is just intended to ferry along in the compiler that such an
optimization is possible. The `derive(PartialEq,Eq)` optimization was also
updated to do something similar.
---
One part of this PR which needs to be improved before stabilizing are the errors
and exact interfaces here. The error messages are relatively poor quality and
there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]`
not working by default. The custom attributes added by the compiler end up
becoming unstable again when going through a custom impl.
Hopefully though this is enough to start allowing experimentation on crates.io!
syntax-[breaking-change]
implementing RFC 1623. This fixes#35897.
This is a work in progress. In particular, I want to add more tests,
especially the compile-fail test is very bare-bones.
Allow specification of the system V AMD64 ABI constraint.
This can be specified using `extern "sysV64" fn` on all platforms.
This ABI is used as the C ABI on unix platforms, but can only be specified there using extern "C". It was impossible to specify on other platforms. Meanwhile the win64 ABI, which was the extern "C" ABI on the windows platform could be specified on other platforms using extern "win64".
This pull request adds the the "sysV64" ABI constraint which exposes this calling convention on platforms where it is not the C ABI.
Turn the RFC1592 warnings into hard errors
The warnings have already reached stable, and I want to improve the trait error reporting code.
Turning warnings into errors, this is obviously a [breaking-change].
r? @nikomatsakis
cc @rust-lang/compiler
Update E0393 to new error format
Fixes#35632.
Part of #35233.
r? @jonathandturner
and a wired thing is that if i add another label
```rust
.span_label(span, &format!("missing reference to `{}`", def.name))
.span_label(span, &format!("because of the default `Self` reference, type parameters must be specified on object types"))
```
and add a new note in the test case like
```rust
trait A<T=Self> {}
fn together_we_will_rule_the_galaxy(son: &A) {}
//~^ ERROR E0393
//~| NOTE missing reference to `T`
//~| NOTE because of the default `Self` reference, type parameters must be specified on object types
```
it will complain that
```
running 1 test
test [compile-fail] compile-fail/E0393.rs ... FAILED
failures:
---- [compile-fail] compile-fail/E0393.rs stdout ----
error: /Users/zjh/Documents/rustspace/rust/src/test/compile-fail/E0393.rs:13: unexpected "error": '13:43: 13:44: the type parameter `T` must be explicitly specified [E0393]'
unexpected errors (from JSON output): [
Error {
line_num: 13,
kind: Some(
Error
),
msg: "13:43: 13:44: the type parameter `T` must be explicitly specified [E0393]"
}
]
```
it is a little bit confusing and through the blog post we can use `//~^` and `//~|` to support multiple notes, @jonathandturner am i missing something here?
Change E0259 to the new error format
Fixes#35514 as part of #35233.
Sorry about creating a new PR I was having a lot of troubles squashing the commit because I didn't properly branch the new feature.
r? @GuillaumeGomez
Bonus format for E0194
Bonus fix for #35280. Part of #35233. Fixes#36057. Adding expanded notes/context for what trait a parameter shadows as part of E0194 error messages.
Errors for E0194 now look like this:
```
$> ./build/x86_64-apple-darwin/stage1/bin/rustc src/test/compile-fail/E0194.rs
error[E0194]: type parameter `T` shadows another type parameter of the same name
--> src/test/compile-fail/E0194.rs:13:26
|
11 | trait Foo<T> { //~ NOTE first `T` declared here
| - first `T` declared here
12 | fn do_something(&self) -> T;
13 | fn do_something_else<T: Clone>(&self, bar: T);
| ^ shadows another type parameter
error: aborting due to previous error
```
r? @jonathandturner
