This provides limited support for using associated consts on type parameters. It generally works on things that can be figured out at trans time. This doesn't work for array lengths or match arms. I have another patch to make it work in const expressions.
CC @eddyb @nikomatsakis
This PR changes translation of tuple-like ADTs from being calls to being proper aggregates. This change is done in hope to make code generation better. Namely, now we can avoid:
1. Call overhead;
2. Generating landingpads in presence of cleanups (we know for sure constructing ADTs can’t panic);
3. And probably much more, gaining better MIR introspectablilty.
Along with that a few serious deficiencies with translation of ADTs and switches have been fixed as well (commits 2 and 3).
r? @nikomatsakis
cc @tsion
In my PR for #21659 I accidentally used `// | help` as test annotation. This PR updates it to `//~| help`. I also found and updated 2 other tests with the same issue.
The only way to get a value for a zero-sized type is `undef`, so
there's really no point in actually having a return type other than
void for such types. Also, while the comment in return_type_is_void
mentioned something about aiding C ABI support, @eddyb correctly
pointed out on IRC that there is no such thing as a zero-sized type in
C. And even with clang, which allows empty structs, those get
translated as void return types as well.
Fixes#28766
Previously we would generate regular calls for these, which is likely to result in worse LLVM code,
especially in presence of cleanups – we needn’t unecessarilly generate landing pads to construct an
ADT!
this makes sure the checks run before typeck (which might use the constant or const
function to calculate an array length) and gives prettier error messages in case of for
loops and such (since they aren't expanded yet).
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.
