| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Type parameters are referenced in the error message after the previous
few commits (using span label). But when the main error message already
references the very same type parameter it becomes clumsy. Do not show
the additional label in this case as per code review comment by
@estebank.
Also this contains a small style fix.
|
|
Fixes #47319.
Shows the type parameter definition(s) on type mismatch errors so the
context is clearer. Pretty much changes the following:
```
LL | bar1(t);
| ^
| |
| expected enum `std::option::Option`, found type parameter `T`
```
into:
```
LL | fn foo1<T>(t: T) {
| - this type parameter
LL | bar1(t);
| ^
| |
| expected enum `std::option::Option`, found type parameter `T`
```
|
|
Part of #47319.
This just adds type parameter name to type mismatch error message, so
e.g. the following:
```
expected enum `std::option::Option`, found type parameter
```
becomes
```
expected enum `std::option::Option`, found type parameter `T`
```
|
|
|
|
Including removing a bunch of unnecessary `.as_str()` calls, and a bunch
of unnecessary sigils.
|
|
|
|
It makes the relationship with `Symbol` clearer. The `Str` suffix
matches the existing `Symbol::as_str()` method nicely, and is also
consistent with it being a wrapper of `&str`.
|
|
So we can remove the corresponding checks from various code
|
|
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 #64872
Reopen #64319
|
|
ohadravid:fix-incorrect-diagnostics-with-an-associated-type, r=estebank
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.
|
|
Make ItemContext available for better diagnositcs
Fix #62570
|
|
Don't hide ICEs from previous incremental compiles
I think this fixes #65401, the compiler does not fail to ICE after the first compilation, tested on the last snippet of [this comment](https://github.com/rust-lang/rust/issues/63154#issuecomment-541592381).
I am not very sure of the fix as I don't understand much of the structure of the compiler.
|
|
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.
|
|
generics export).
Includes the anticipated fallout to run-make-fulldeps test suite from
this change. (We need to reopen issue 64319 as part of landing this.)
|
|
It's sufficiently simple and fast that memoizing it is a slight
pessimization.
|
|
|
|
|
|
|
|
This changes the mechanism of `-Z dual-proc-macro` to record the host
proc macro hash in the transistive dependency information and use it
during dependency resolution instead of resolving only by name.
|
|
Update comments re type parameter hack in object safety
To check if a method's receiver type is object safe, we create a new receiver type by substituting in a bogus type parameter (let's call it `U`) for `Self`, and checking that the unmodified receiver type implements `DispatchFromDyn<receiver type with Self = U>`. It would be better to use `dyn Trait` directly, and the only reason we don't is because it triggers another check that `Trait` is object safe, resulting in a query cycle. Once the feature `object_safe_for_dispatch` (tracking issue https://github.com/rust-lang/rust/issues/43561) is stabilized, this will no longer be the case, and we'll be able to use `dyn Trait` as the unsized `Self` type. I've updated the comments in object_safety.rs accordingly.
cc @Centril @nikomatsakis @bovinebuddha
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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`
|
|
Update backtrace to 0.3.40
Diff: https://github.com/rust-lang/backtrace-rs/compare/0.3.37...b5cc5b12fa4fd03cb83546a7c62b9fff40086b63
Pretty low risk, considering the only changes are in low-tier targets.
r? @cramertj
cc @alexcrichton
|
|
Call out the types that are non local on E0117
CC #24745.
|
|
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).
|
|
|
|
Output previous stable error messaging when using stable build.
Fixes #65254
As I had mentioned previously there I have the logic running right now however I'm not getting the exact same syntax highlighting as there was originally for this error.
I'm currently getting the following:
```
error: expected expression, found statement (`let`)
--> src/main.rs:2:14
|
2 | let x = (let y = 6);
| ^^^^^^^^^
|
= note: variable declaration using `let` is a statement
```
I'd like to get the following instead:
```
| let x = (let y = 6);
| ^^^
```
My current understanding is that the `span` being passed into `lower_expr_let` is coming from `lowering.rs`. I still don't know how the byte range is calculated for the erroneous syntax and need to look into it a bit more. In the meantime does anybody have any hints/tips regarding this??
|
|
self-profiling: Record something more useful for crate metadata generation event.
Before this commit, we had an event that would only track the compression step
for proc-macros and Rust dylibs. After the commit we measure the time for
acutally generating the crate metadata bytes.
r? @wesleywiser
|
|
r=ecstatic-morse
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)
|
|
rustc: use IndexVec<DefIndex, T> instead of Vec<T>.
Now that `DefIndex` is a proper index type, we can do that.
There was also an unnecessary `Option` I removed, I wonder if that has perf implications.
|
|
r=eddyb
Correct handling of type flags with `ConstValue::Placeholder`
This fixes a mistake, but not https://github.com/rust-lang/rust/issues/65623.
r? @eddyb
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
