The proper name of the library is `annotate-snippet`, not `annotate-rs`,
this commit should get rid of any confusing `AnnotateRs` names.
1. Renames `annotate_rs_emitter.rs` to
`annotate_snippet_emitter_writer.rs` so that the difference between the
`Emitter` trait and the implementers is more clear.
2. Renames `AnnotateRsEmitterWriter` to `AnnotateSnippetEmitterWriter`
3. Renames `HumanReadableErrorType::AnnotateRs` to `HumanReadableErrorType::AnnotateSnippet`
Emit error when trying to use PGO in conjunction with unwinding on Windows.
This PR makes `rustc` emit an error when trying use PGO in conjunction with `-Cpanic=unwind` on Windows, isn't supported by LLVM yet. The error messages points to https://github.com/rust-lang/rust/issues/61002, which documents this known limitation.
Update rustc book CLI docs.
This adds a little detail (and missing flags) to the rustc book. There is still a lot of information missing, but this seemed like a good step to expanding it.
In JSON output, emit a directive after metadata is generated.
To implement pipelining, Cargo needs to know when metadata generation is
finished. This is done via a new JSON "directive".
Unfortunately, metadata file writing currently occurs very late during
compilation, so pipelining won't produce a speed-up. Moving metadata
file writing earlier will be a follow-up.
r? @alexcrichton
To implement pipelining, Cargo needs to know when metadata generation is
finished. This commit adds code to do that. Unfortunately, metadata file
writing currently occurs very late during compilation, so pipelining
won't produce a speed-up. Moving metadata file writing earlier will be a
follow-up.
The change involves splitting the existing `Emitter::emit` method in
two: `Emitter::emit_diagnostic` and `Emitter::emit_directive`.
The JSON directives look like this:
```
{"directive":"metadata file written: liba.rmeta"}
```
The functionality is behind the `-Z emit-directives` option, and also
requires `--error-format=json`.
rustc: Flag metadata compatible with multiple CGUs
It looks like the `OutputType::Metadata` kind in the compiler was
misclassified in #38571 long ago by accident as incompatible with
codegen units and a single output file. This means that if you emit both
a linkable artifact and metadata it silently turns off multiple codegen
units unintentionally!
This commit corrects the situation to ensure that if `--emit metadata`
is used it doesn't implicitly disable multiple codegen units. This will
ensure we don't accidentally regress compiler performance when striving
to implement pipelined compilation!
It looks like the `OutputType::Metadata` kind in the compiler was
misclassified in #38571 long ago by accident as incompatible with
codegen units and a single output file. This means that if you emit both
a linkable artifact and metadata it silently turns off multiple codegen
units unintentionally!
This commit corrects the situation to ensure that if `--emit metadata`
is used it doesn't implicitly disable multiple codegen units. This will
ensure we don't accidentally regress compiler performance when striving
to implement pipelined compilation!
Suggest appropriate path when calling associated item on bare types
When looking at the documentation for `std::f32` or `std::str`, for
example, it is easy to get confused and assume `std::f32` and `f32`
are the same thing. Because of this, it is not uncommon to attempt
writing `f32::consts::PI` instead of the correct
`std::f32::consts::PI`. When encountering the former, which results
in an access error due to it being an inexistent path, try to access
the same path under `std`. If this succeeds, this information is
stored for later tweaking of the final E0599 to provide an
appropriate suggestion.
Fix#26760, fix#46660.
When looking at the documentation for `std::f32` or `std::str`, for
example, it is easy to get confused and assume `std::f32` and `f32`
are the same thing. Because of this, it is not uncommon to attempt
writing `f32::consts::PI` instead of the correct
`std::f32::consts::PI`. When encountering the former, which results
in an access error due to it being an inexistent path, try to access
the same path under `std`. If this succeeds, this information is
stored for later tweaking of the final E0599 to provide an
appropriate suggestion.
This suggestion applies to both E0233 and E0599 and is only checked
when the first ident of a path corresponds to a primitive type.
