Commit Graph

234 Commits

Author SHA1 Message Date
xd009642
a6e2b636e6 Implement the instruction_set attribute 2020-10-08 23:32:20 +01:00
bors
4437b4b150 Auto merge of #77464 - ecstatic-morse:const-fn-impl-trait, r=oli-obk
Give `impl Trait` in a `const fn` its own feature gate

...previously it was gated under `#![feature(const_fn)]`.

I think we actually want to do this in all const-contexts? If so, this should be `#![feature(const_impl_trait)]` instead. I don't think there's any way to make use of `impl Trait` within a `const` initializer.

cc #77463

r? `@oli-obk`
2020-10-07 19:59:52 +00:00
Dylan MacKenzie
b5693a39d9 Update error code page 2020-10-06 11:22:24 -07:00
Matthew Jasper
e29765250b Don't immediately error for recursive projections 2020-10-06 11:19:32 +01:00
Matthew Jasper
0dda4154bd Fix tools 2020-10-06 11:19:30 +01:00
Guillaume Gomez
de21c3df0e Create E0777 error code for "invalid literal in derive" 2020-10-01 20:41:57 +02:00
bors
fc42fb8e70 Auto merge of #77354 - ecstatic-morse:const-checking-moar-errors, r=oli-obk
Overhaul const-checking diagnostics

The primary purpose of this PR was to remove `NonConstOp::STOPS_CONST_CHECKING`, which causes any additional errors found by the const-checker to be silenced. I used this flag to preserve diagnostic parity with `qualify_min_const_fn.rs`, which has since been removed.

However, simply removing the flag caused a deluge of errors in some cases, since an error would be emitted any time a local or temporary had a wrong type. To remedy this, I added an alternative system (`DiagnosticImportance`) to silence additional error messages that were likely to distract the user from the underlying issue. When an error of the highest importance occurs, all less important errors are silenced. When no error of the highest importance occurs, all less important errors are emitted after checking is complete. Following the suggestions from the important error is usually enough to fix the less important errors, so this should lead to better UX most of the time.

There's also some unrelated diagnostics improvements in this PR isolated in their own commits. Splitting them out would be possible, but a bit of a pain. This isn't as tidy as some of my other PRs, but it should *only* affect diagnostics, never whether or not something passes const-checking. Note that there are a few trivial exceptions to this, like banning `Yield` in all const-contexts, not just `const fn`.

As always, meant to be reviewed commit-by-commit.

r? `@oli-obk`
2020-10-01 07:38:47 +00:00
Dylan MacKenzie
1301f43119 Remove E0019, use E0015 for inline assembly in a const 2020-09-30 11:29:25 -07:00
Hugues de Valon
2588287def Add more tests and check for ABI
Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2020-09-30 18:10:17 +01:00
Hugues de Valon
1aaafac6ff Add support for cmse_nonsecure_entry attribute
This patch adds support for the LLVM cmse_nonsecure_entry attribute.
This is a target-dependent attribute that only has sense for the
thumbv8m Rust targets.
You can find more information about this attribute here:
https://developer.arm.com/documentation/ecm0359818/latest/

Signed-off-by: Hugues de Valon <hugues.devalon@arm.com>
2020-09-30 15:48:59 +01:00
Dylan MacKenzie
7c6d685551 Rewrite E0019 example
Inline assembly is now the only user of E0019. What is it doing that
E0015 is not?
2020-09-29 21:17:48 -07:00
Jonas Schievink
1b8c939a8d
Rollup merge of #76973 - lzutao:unstably-const-assume, r=oli-obk
Unstably allow assume intrinsic in const contexts

Not sure much about this usage because there are concerns
about [blocking  optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic
in inline functions.
But since Oli suggested in https://github.com/rust-lang/rust/issues/76960#issuecomment-695772221,
here we are.

[1]: https://github.com/rust-lang/rust/pull/54995#issuecomment-429302709
[2]: https://github.com/rust-lang/rust/issues/49572#issuecomment-589615423
2020-09-25 19:42:29 +02:00
Guillaume Gomez
63195ecb45 Add explanation for E0756 2020-09-21 21:04:56 +02:00
Ralf Jung
670e204ace
Rollup merge of #76439 - GuillaumeGomez:add-error-explanation-e0755, r=pickfire,jyn514
Add error explanation for E0755

r? @pickfire
2020-09-21 15:30:34 +02:00
Lzu Tao
3e08354fb0 Correct file path after some restructures in compiler 2020-09-20 13:48:16 +00:00
Niclas Schwarzlose
81161bed41
Adjust spelling
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
2020-09-15 18:10:41 +02:00
Amjad Alsharafi
afb9eeb1b9 Disabled error E0007 from rustc_error_codes 2020-09-15 14:23:20 +08:00
aticu
1c1bb1309f Improve E0118 description 2020-09-11 19:48:43 +02:00
Tyler Mandry
5ea55518bc
Rollup merge of #75984 - kornelski:typeormodule, r=matthewjasper
Improve unresolved use error message

"use of undeclared type or module `foo`" doesn't mention that it could be a crate.

This error can happen when users forget to add a dependency to `Cargo.toml`, so I think it's important to mention that it could be a missing crate.

I've used a heuristic based on Rust's naming conventions. It complains about an unknown type if the ident starts with an upper-case letter, and crate or module otherwise. It seems to work very well. The expanded error help covers both an unknown type and a missing crate case.
2020-09-09 15:05:45 -07:00
bors
3f5e617e36 Auto merge of #76406 - GuillaumeGomez:create-e0774, r=pickfire,jyn514
Create E0774
2020-09-09 08:23:33 +00:00
bors
0855263dcd Auto merge of #76463 - camelid:improve-E0607-explanation, r=jyn514
Improve wording of E0607 explanation

`@rustbot` modify labels: A-diagnostics C-enhancement
2020-09-09 06:33:03 +00:00
Guillaume Gomez
e0df2f87b6 Create new E0774 code error 2020-09-08 21:32:03 +02:00
Guillaume Gomez
69ffed763d Add error explanation for E0755 2020-09-08 21:07:52 +02:00
Camelid
98a5506647 Add "For example," 2020-09-07 18:48:22 -07:00
Camelid
1f78509afe Improve wording of E0607 explanation 2020-09-07 18:41:55 -07:00
bors
71569e4201 Auto merge of #75138 - jumbatm:session-diagnostic-derive, r=oli-obk
Add derive macro for specifying diagnostics using attributes.

Introduces `#[derive(SessionDiagnostic)]`, a derive macro for specifying structs that can be converted to Diagnostics using directions given by attributes on the struct and its fields. Currently, the following attributes have been implemented:
- `#[code = "..."]` -- this sets the Diagnostic's error code, and must be provided on the struct iself (ie, not on a field). Equivalent to calling `code`.
- `#[message = "..."]` -- this sets the Diagnostic's primary error message.
- `#[label = "..."]` -- this must be applied to fields of type `Span`, and is equivalent to `span_label`
- `#[suggestion(..)]` -- this allows a suggestion message to be supplied. This attribute must be applied to a field of type `Span` or `(Span, Applicability)`, and is equivalent to calling `span_suggestion`. Valid arguments are:
    - `message = "..."` -- this sets the suggestion message.
    - (Optional) `code = "..."` -- this suggests code for the suggestion. Defaults to empty.

`suggestion`also  comes with other variants: `#[suggestion_short(..)]`, `#[suggestion_hidden(..)]` and `#[suggestion_verbose(..)]` which all take the same keys.

Within the strings passed to each attribute, fields can be referenced without needing to be passed explicitly into the format string -- eg, `#[error = "{ident} already declared"] ` will set the error message to `format!("{} already declared", &self.ident)`. Any fields on the struct can be referenced in this way.

Additionally, for any of these attributes, Option fields can be used to only optionally apply the decoration -- for example:

```rust
#[derive(SessionDiagnostic)]
#[code = "E0123"]
struct SomeKindOfError {
    ...
    #[suggestion(message = "informative error message")]
    opt_sugg: Option<(Span, Applicability)>
    ...
}
```
will not emit a suggestion if `opt_sugg` is `None`.

We plan on iterating on this macro further; this PR is a start.

Closes #61132.

r? `@oli-obk`
2020-09-08 00:58:43 +00:00
Tyler Mandry
b01d0b1414
Rollup merge of #76143 - jyn514:duplicate-builtin-macros, r=petrochenkov
Give a better error message for duplicate built-in macros

Minor follow-up to https://github.com/rust-lang/rust/pull/75176 giving a better error message for duplicate builtin macros. This would have made it a little easier to debug.

r? @petrochenkov
2020-09-01 18:24:35 -07:00
Kornel
7ec1de062a Clarify message about unresolved use 2020-09-01 18:38:14 +01:00
jumbatm
5956254172 Fix typos in E0224 2020-09-01 23:05:56 +10:00
Joshua Nelson
be2947d0b7 Give a better error message for duplicate built-in macros
Previously, this would say no such macro existed, but this was
misleading, since the macro _did_ exist, it was just already seen.

- Say where the macro was previously defined
- Add long-form error message
2020-09-01 08:34:17 -04:00
Tyler Mandry
4f276202f5
Rollup merge of #76103 - GuillaumeGomez:cleanup-e0769, r=Dylan-DPC
Clean up E0769

r? @pickfire

cc @Dylan-DPC
2020-08-31 19:18:19 -07:00
Guillaume Gomez
153f966d00 Clean up E0764 explanation 2020-08-31 20:14:37 +02:00
Guillaume Gomez
f3ae96ecd5 Clean up E0769 explanation 2020-08-31 20:10:57 +02:00
mark
9e5f7d5631 mv compiler to compiler/ 2020-08-30 18:45:07 +03:00