Ref issue [30825](https://github.com/rust-lang/rust/issues/30825)
This commit should suffice to add a concise introduction to the concept of crates.
My only worry, is that it is maybe too concise; but, the book seems to be written with the understanding that the new Rust user is coming from another language, and so will understand what a Library or Code Package is.
There is now more structure to the report, so that you can specify e.g. an RFC/PR/issue number and other explanatory details.
Example message:
```
type-parameter-invalid-lint.rs:14:8: 14:9 error: defaults for type parameters are only allowed on type definitions, like `struct` or `enum`
type-parameter-invalid-lint.rs:14 fn avg<T=i32>(_: T) {}
^
type-parameter-invalid-lint.rs:14:8: 14:9 warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
type-parameter-invalid-lint.rs:14:8: 14:9 note: for more information, see PR 30742 <https://github.com/rust-lang/rust/pull/30724>
type-parameter-invalid-lint.rs:11:9: 11:28 note: lint level defined here
type-parameter-invalid-lint.rs:11 #![deny(future_incompatible)]
^~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
```
r? @brson
I would really like feedback also on the specific messages!
Fixes#30746
The first line (paragraph?) of a doc-comment is what rustdoc shows when listing items of a module.
What makes `Instant` and `SystemTime` different is important enough to be there. (Though feel free to bikeshed the wording.)
This is a bit weird since unsized types can't be used in trait objects,
but Any is *also* used as pure marker trait since Reflect isn't stable.
There are many cases (e.g. TypeMap) where all you need is a TypeId.
This is achieved by adding the scan_back method. This method looks back
through the source_text of the StringReader until it finds the target
char, returning it's offset in the source. We use this method to find
the offset of the opening single quote, and use that offset as the start
of the error.
Given this code:
```rust
fn main() {
let _ = 'abcd';
}
```
The compiler would give a message like:
```
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
```
With this change, the message now displays:
```
error: character literal may only contain one codepoint: 'abcd';
let _ = 'abcd';
^~~~~~~
```
Fixes#30033
The compiler can emit errors and warning in JSON format. This is a more easily machine readable form then the usual error output.
Closes#10492, closes#14863.
[breaking-change]
`OptLevel` variants are no longer `pub use`ed by rust::session::config. If you are using these variants, you must change your code to prefix the variant name with `OptLevel`.
[breaking-change]
syntax::errors::Handler::new has been renamed to with_tty_emitter
Many functions which used to take a syntax::errors::ColorConfig, now take a rustc::session::config::ErrorOutputType. If you previously used ColorConfig::Auto as a default, you should now use ErrorOutputType::default().
This feature is partially stabilized, so describe each part in the appropriate place.
r? @alexcrichton @brson
It would be nice to backport this to beta, since this is the first release where this is true. I try really hard to not do doc backports, but this isn't very large, and might be worth making an exception, I dunno.
stalled rather than keeping this annoying mark; I checked that the
original compile-time regression that the mark was intended to
fix (https://github.com/rust-lang/rust/issues/18208) was still
reasonable, but I've not done exhaustive measurements to see how
important this "optimization" really is anymore
Given this code:
fn main() {
let _ = 'abcd';
}
The compiler would give a message like:
error: character literal may only contain one codepoint: ';
let _ = 'abcd';
^~
With this change, the message now displays:
error: character literal may only contain one codepoint: 'abcd'
let _ = 'abcd'
^~~~~~
Fixes#30033
