When both error patterns and error annotations are present in an ui
test, only error patterns are validated against the output.
Replace the error pattern with an error annotation to avoid silently
ignoring the other error annotation.
Those annotation are silently ignored rather than begin validated
against compiler output. Update them before validation is enabled,
to avoid test failures.
Revert PR 64324: dylibs export generics again (for now)
As discussed on PR #65781, this is a targeted attempt to undo the main semantic change from PR #64324, by putting `dylib` back in the set of crate types that export generic symbols.
The main reason to do this is that PR #64324 had unanticipated side-effects that caused bugs like #64872, and in the opinion of @alexcrichton and myself, the impact of #64872 is worse than #64319.
In other words, it is better for us, in the short term, to reopen#64319 as currently unfixed for now than to introduce new bugs like #64872.
Fix#64872Reopen#64319
Fix incorrect diagnostics for expected type in E0271 with an associated type
With code like the following code:
```rust
#[derive(Debug)]
struct Data {}
fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
for item in iterator {
println!("{:?}", item)
}
}
fn main() {
let v = vec![Data {}];
do_stuff(v.into_iter());
}
```
the diagnostic (in nightly & stable) wrongly complains about the expected type:
```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
--> src/main.rs:15:5
|
5 | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
| -------- --------------- required by this bound in `do_stuff`
...
15 | do_stuff(v.into_iter());
| ^^^^^^^^ expected struct `Data`, found &Data
|
= note: expected type `Data`
found type `&Data`
```
This PR fixes this issue by flipping the expected/actual values where appropriate, so it looks like this:
```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
--> main.rs:15:5
|
5 | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
| -------- --------------- required by this bound in `do_stuff`
...
15 | do_stuff(v.into_iter());
| ^^^^^^^^ expected &Data, found struct `Data`
|
= note: expected type `&Data`
found type `Data`
```
This improves the output of a lot of existing tests (check out `associated-types-binding-to-type-defined-in-supertrait`!).
The only change which I wasn't too sure about is in the test `associated-types-overridden-binding-2`, but I think it's an improvement and the underlying problem is with handling of `trait_alias`.
Fix#57226, fix#64760, fix#58092.
Add lint and tests for unnecessary parens around types
This is my first contribution to the Rust project, so I apologize if I'm not doing things the right way.
The PR fixes#64169. It adds a lint and tests for unnecessary parentheses around types. I've run `tidy` and `rustfmt` — I'm not totally sure it worked right, though — and I've tried to follow the instructions linked in the readme.
I tried to think through all the variants of `ast::TyKind` to find exceptions to this lint, and I could only find the one mentioned in the original issue, which concerns types with `dyn`. I'm not a Rust expert, thought, so I may well be missing something.
There's also a problem with getting this to build. The new lint catches several things in the, e.g., `core`. Because `x.py` seems to build with an equivalent of `-Werror`, what would have been warnings cause the build to break. I got it to build and the tests to pass with `--warnings warn` on my `x.py build` and `x.py test` commands.
(Many thanks to alex for 1. making this even smaller than what I had
originally minimized, and 2. pointing out that there is precedent for
having ui tests with crate dependency chains of length > 2, thus
allowing me to avoid encoding this as a run-make test.)
[rustdoc] stabilize cfg(doctest)
Fixes#62210.
Since we removed rustdoc from providing cfg(test) on test runs, it's been replaced by cfg(doctest). It'd be nice to have it in not too far in the future.
save-analysis: Account for async desugaring in async fn return types
Closes#65590
When visiting the return type of an async function we need to take into account its desugaring, since it introduces a new definition under which the return type is redefined.
r? @nikomatsakis
Re-enable Emscripten's exception handling support
Passes LLVM codegen and Emscripten link-time flags for exception
handling if and only if the panic strategy is `unwind`. Sets the
default panic strategy for Emscripten targets to `unwind`. Re-enables
tests that depend on unwinding support for Emscripten, including
`should_panic` tests.
r? @alexcrichton
resolve: Turn the "non-empty glob must import something" error into a lint
This fixes#62334 by changing the error to a lint warning the glob. I changed the test but I'm very unsure of what I did as I do not know how to correctly check for the warning
Add new EFIAPI ABI
Fixes#54527
Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI.
Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
Improve the "try using a variant of the expected type" hint.
Fix https://github.com/rust-lang/rust/issues/65494.
- Change type-printing output.
- Use `span_to_snippet` when possible.
- Change the message to `try using a variant of the expected enum`
Lint ignored `#[inline]` on function prototypes
Fixes https://github.com/rust-lang/rust/issues/51280.
- Adds a `unused_attribute` lint for `#[inline]` on function prototypes.
- As a consequence, foreign items, impl items and trait items now have their attributes checked, which could cause some code to no longer compile (it was previously erroneously ignored).
suggest `const_in_array_repeat_expression` flag
This PR adds a suggestion to add the `#![feature(const_in_array_repeat_expression)]` attribute to the crate when a promotable expression is used in a repeat expression and the feature gate is not enabled.
Unfortunately, this ended up being a little bit more complex than I anticipated, which may not have been worth it given that this would all be removed when the feature is stabilized. However, with #65732 and #65737 being open, and the feature gate having not been being suggested to potential users, the feature might not be stabilized in a while, so maybe this is worth landing.
cc @Centril (addresses [this comment](https://github.com/rust-lang/rust/pull/61749#discussion_r307863857))
r? @ecstatic-morse (opened issues related to RFC 2203 recently)
Use heuristics to recover parsing of missing `;`
- Detect `,` and `:` typos where `;` was intended.
- When the next token could have been the start of a new statement,
detect a missing semicolon.
Fix#48160, fix#44767 (after adding note about statements).
This commit adds a suggestion to add the
`#![feature(const_in_array_repeat_expression)]` attribute to the crate
when a promotable expression is used in a repeat expression.
Signed-off-by: David Wood <david@davidtw.co>
