Commit Graph

14 Commits

Author SHA1 Message Date
Esteban Küber
850faea030 Do not use question as label
We don't want to have questions in the diagnostic output. Instead, we use wording that communicates uncertainty, like "might":

```
error[E0432]: unresolved import `spam`
  --> $DIR/import-from-missing-star-3.rs:2:9
   |
LL |     use spam::*;
   |         ^^^^ you might be missing crate `spam`
   |
   = help: consider adding `extern crate spam` to use the `spam` crate
```
2024-07-24 21:03:27 +00:00
Xiretza
c88bb6c011 Allow nesting subdiagnostics 2024-04-21 07:45:03 +00:00
Nicholas Nethercote
60ea6e2831 Rename SubdiagnosticMessage as SubdiagMessage. 2024-03-05 12:14:49 +11:00
Nicholas Nethercote
18715c98c6 Rename DiagnosticMessage as DiagMessage. 2024-03-05 12:14:49 +11:00
许杰友 Jieyou Xu (Joe)
6e48b96692
[AUTO_GENERATED] Migrate compiletest to use ui_test-style //@ directives 2024-02-22 16:04:04 +00:00
Nicholas Nethercote
57cd5e6551 Use rustc_fluent_macro::fluent_messages! directly.
Currently we always do this:
```
use rustc_fluent_macro::fluent_messages;
...
fluent_messages! { "./example.ftl" }
```
But there is no need, we can just do this everywhere:
```
rustc_fluent_macro::fluent_messages! { "./example.ftl" }
```
which is shorter.
2023-11-26 08:38:40 +11:00
Oli Scherer
ad8303739f Bump syn dependency 2023-07-26 08:42:40 +00:00
Deadbeef
4f83717cf7 Use translatable diagnostics in rustc_const_eval 2023-06-01 14:45:18 +00:00
Nilstrieb
b5d3d970fa Add rustc_fluent_macro to decouple fluent from rustc_macros
Fluent, with all the icu4x it brings in, takes quite some time to
compile. `fluent_messages!` is only needed in further downstream rustc
crates, but is blocking more upstream crates like `rustc_index`. By
splitting it out, we allow `rustc_macros` to be compiled earlier, which
speeds up `x check compiler` by about 5 seconds (and even more after the
needless dependency on `serde_json` is removed from
`rustc_data_structures`).
2023-04-18 18:56:22 +00:00
jyn
d6af60266e Support x test --stage 1 ui-fulldeps
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.

I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.

- Move `plugin` tests into a subdirectory.

  Plugins are loaded at runtime with `dlopen` and so require the ABI of
  the running compile to match the ABI of the compiler linked with
  `rustc_driver`. As a result they can't be supported in stage 1 and have
  to use `// ignore-stage1`.

- Remove `ignore-stage1` from most non-plugin tests

- Ignore diagnostic tests in stage 1. Even though this requires a stage
  2 build to load rustc_driver, it's primarily testing the error message
  that the *running* compiler emits when the diagnostic struct is malformed.

- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
  allows running `hash-stable-is-unstable` in stage1, since it now
  suggests adding `rustc_private` to enable loading the crates.

- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
  that act as custom drivers to load it at runtime.

- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
  correct version of std.
2023-04-17 22:40:31 -05:00
Deadbeef
25fdea009e fix errors 2023-04-06 04:55:58 +00:00
David Wood
d1fcf61117 errors: generate typed identifiers in each crate
Instead of loading the Fluent resources for every crate in
`rustc_error_messages`, each crate generates typed identifiers for its
own diagnostics and creates a static which are pulled together in the
`rustc_driver` crate and provided to the diagnostic emitter.

Signed-off-by: David Wood <david.wood@huawei.com>
2023-02-22 09:15:53 +00:00
Xiretza
f2acbb9d1e Forbid #[suggestion_*(...)] on Vecs
It is ambiguous whether this should produce several `.span_suggestions()`
calls or one `.multipart_suggestions()` call.
2023-02-01 21:49:45 +01:00
Albert Larsan
cf2dff2b1e
Move /src/test to /tests 2023-01-11 09:32:08 +00:00