Commit Graph

758 Commits

Author SHA1 Message Date
Linus Färnstrand
68f275c4ec Adapt issue-77982.stderr to new rustc error 2023-02-26 13:50:10 +01:00
Matthias Krüger
b27f37da07
Rollup merge of #108337 - tshepang:translatable-hir-analysis, r=cjgillot
hir-analysis: make a helpful note
2023-02-26 12:04:58 +01:00
Matthias Krüger
2bc553c6ea
Rollup merge of #107941 - compiler-errors:str-has-u8-slice-for-auto, r=lcnr
Treat `str` as containing `[u8]` for auto trait purposes

Wanted to gauge ``@rust-lang/lang`` and ``@rust-lang/types`` teams' thoughts on treating `str` as "containing" a `[u8]` slice for auto-trait purposes.

``@dtolnay`` brought this up in https://github.com/rust-lang/rust/issues/13231#issuecomment-1399386472 as a blocker for future `str` type librarification, and I think it's both a valid concern and very easy to fix. I'm interested in actually doing that `str` type librarification (#107939), but this probably should be considered in the mean time regardless of that PR.

r? types for the impl, though this definitely needs an FCP.
2023-02-26 12:04:57 +01:00
y21
32da026c35 generalize help message 2023-02-26 11:58:49 +01:00
Camille GILLOT
d35dbbdc8e Store the body type in THIR. 2023-02-26 10:30:27 +00:00
Camille GILLOT
752ddd028c Merge the two diagnostics. 2023-02-26 10:29:25 +00:00
bors
70fd012439 Auto merge of #108473 - matthiaskrgr:rollup-qjyae58, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #107062 (Do some cleanup of doc/index.md)
 - #107890 (Lint against `Iterator::map` receiving a callable that returns `()`)
 - #108431 (Add regression test for #107918)
 - #108432 (test: drop unused deps)
 - #108436 (make "proc macro panicked" translatable)
 - #108444 (docs/test: add UI test and docs for `E0476`)
 - #108449 (Do not lint ineffective unstable trait impl for unresolved trait)
 - #108456 (Complete migrating `ast_passes` to derive diagnostics)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2023-02-26 02:04:23 +00:00
Matthias Krüger
767c865f07
Rollup merge of #108456 - clubby789:ast-passes-diag-migrate, r=compiler-errors
Complete migrating `ast_passes` to derive diagnostics

cc #100717

```@rustbot``` label +A-translation
2023-02-26 00:46:28 +01:00
Matthias Krüger
a223ff7cea
Rollup merge of #108449 - fee1-dead-contrib:do_not_lint_unresolved, r=compiler-errors
Do not lint ineffective unstable trait impl for unresolved trait
2023-02-26 00:46:28 +01:00
Matthias Krüger
65eecc6b59
Rollup merge of #108444 - Ezrashaw:add-test+docs-for-e0476, r=GuillaumeGomez
docs/test: add UI test and docs for `E0476`

Final undocumented error code. Not entirely sure about wording in the docs.

Part of https://github.com/rust-lang/rust/issues/61137.

r? ```@compiler-errors```

cc ```@compiler-errors```
2023-02-26 00:46:28 +01:00
Matthias Krüger
fa10a21bd2
Rollup merge of #107890 - obeis:mapping-to-unit, r=cjgillot
Lint against `Iterator::map` receiving a callable that returns `()`

Close #106991
2023-02-26 00:46:25 +01:00
Tshepang Mbambo
e5d1fcd535 hir-analysis: make a helpful note 2023-02-26 00:01:44 +02:00
Michael Goulet
53fb433652 Special note for str in auto traits 2023-02-25 20:01:33 +00:00
Michael Goulet
3560e65c44 Treat str as containing [u8] for auto trait purposes 2023-02-25 20:01:33 +00:00
Michael Goulet
4723a9ad14
Rollup merge of #108333 - compiler-errors:new-solver-object-sound, r=lcnr
Make object bound candidates sound in the new trait solver

r? `@lcnr`
2023-02-25 11:53:11 -08:00
Michael Goulet
cf049ac2af
Rollup merge of #107911 - blyxyas:issue-107231-fix, r=compiler-errors
Add check for invalid #[macro_export] arguments

Resolves #107231
Sorry if I made something wrong, this is my first contribution to the repo.
2023-02-25 11:53:10 -08:00
Michael Goulet
1a599d7d97
Rollup merge of #107675 - jsgf:link-directives, r=davidtwco
Implement -Zlink-directives=yes/no

`-Zlink-directives=no` will ignored `#[link]` directives while compiling a crate, so nothing is emitted into the crate's metadata.  The assumption is that the build system already knows about the crate's native dependencies and can provide them at link time without these directives.

This is another way to address issue # #70093, which is currently addressed by `-Zlink-native-libraries` (implemented in #70095). The latter is implemented at link time, which has the effect of ignoring `#[link]` in *every* crate. This makes it a very large hammer as it requires all native dependencies to be known to the build system to be at all usable, including those in sysroot libraries. I think this means its effectively unused, and definitely under-used.

Being able to control this on a crate-by-crate basis should make it much easier to apply when needed.

I'm not sure if we need both mechanisms, but we can decide that later.

cc `@pcwalton` `@cramertj`
2023-02-25 11:53:09 -08:00
Camille GILLOT
9aa4f6acb2 MIR-Validate StorageLive. 2023-02-25 16:27:10 +00:00
clubby789
885f9e72d7 Complete migrating ast_passes to derive diagnostics 2023-02-25 15:19:13 +00:00
Deadbeef
ed34354bfa Do not lint unresolved trait for ineffective unstable trait impl 2023-02-25 10:12:20 +00:00
Ezra Shaw
9f876cc900
docs/test: add UI test and docs for E0476 2023-02-25 19:31:02 +13:00
Dylan DPC
c77cf40df0
Rollup merge of #108401 - notriddle:notriddle/diagnostics-article, r=compiler-errors
diagnostics: remove inconsistent English article "this" from E0107

Consider [`tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`][issue-102768.stderr], the error message where it gives additional notes about where the associated type is defined, and how the dead code lint doesn't have an article, like in [`tests/ui/lint/dead-code/issue-85255.stderr`][issue-85255.stderr]. They don't have articles, so it seems unnecessary to have one here.

[issue-102768.stderr]: 07c993eba8/tests/ui/const-generics/generic_const_exprs/issue-102768.stderr
[issue-85255.stderr]: 07c993eba8/tests/ui/lint/dead-code/issue-85255.stderr
2023-02-24 12:02:45 +05:30
Dylan DPC
8acbfe27d6
Rollup merge of #108388 - ohno418:better-suggestion-on-malformed-closure, r=davidtwco
parser: provide better suggestions and errors on closures with braces missing

We currently provide wrong suggestions and unhelpful errors on closure bodies with braces missing.

For example, given the following code:

```rust
fn main() {
    let _x = Box::new(|x|x+1;);
}
```

the current output is:

```
error: expected expression, found `)`
 --> ./main.rs:2:30
  |
2 |     let _x = Box::new(|x|x+1;);
  |                              ^ expected expression

error: closure bodies that contain statements must be surrounded by braces
 --> ./main.rs:2:25
  |
2 |     let _x = Box::new(|x|x+1;);
  |                         ^
3 | }
  | ^
  |
note: statement found outside of a block
 --> ./main.rs:2:29
  |
2 |     let _x = Box::new(|x|x+1;);
  |                          ---^ this `;` turns the preceding closure into a statement
  |                          |
  |                          this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
 --> ./main.rs:2:23
  |
2 |     let _x = Box::new(|x|x+1;);
  |                       ^^^^^^ this is the parsed closure...
3 | }
  | - ...but likely you meant the closure to end here
help: try adding braces
  |
2 ~     let _x = Box::new(|x| {x+1;);
3 ~ }}
  |

error: expected `;`, found `}`
 --> ./main.rs:2:32
  |
2 |     let _x = Box::new(|x|x+1;);
  |                                ^ help: add `;` here
3 | }
  | - unexpected token

error: aborting due to 3 previous errors
```

We got 3 errors, but all but the second are unnecessary or just wrong.

This commit allows outputting correct suggestions and errors. The above code would output like this:

```
error: closure bodies that contain statements must be surrounded by braces
 --> ./main.rs:2:25
  |
2 |     let _x = Box::new(|x|x+1;);
  |                         ^    ^
  |
note: statement found outside of a block
 --> ./main.rs:2:29
  |
2 |     let _x = Box::new(|x|x+1;);
  |                          ---^ this `;` turns the preceding closure into a statement
  |                          |
  |                          this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
 --> ./main.rs:2:23
  |
2 |     let _x = Box::new(|x|x+1;);
  |                       ^^^^^^ - ...but likely you meant the closure to end here
  |                       |
  |                       this is the parsed closure...
help: try adding braces
  |
2 |     let _x = Box::new(|x| {x+1;});
  |                           +    +

error: aborting due to previous error
```

Fixes https://github.com/rust-lang/rust/issues/107959.

r? diagnostics
2023-02-24 12:02:44 +05:30
Dylan DPC
4aff2c5ff8
Rollup merge of #108377 - clubby789:duplicate-diagnostic-ice, r=compiler-errors
Fix ICE in 'duplicate diagnostic item' diagnostic

Not sure how to add this in a test; I found it by mistakenly running `cargo fix --lib -p std` rather than `x fix` at the root.
2023-02-24 12:02:43 +05:30
Dylan DPC
251293ef5e
Rollup merge of #108287 - compiler-errors:new-solver-bad-cast, r=spastorino
Add test for bad cast with deferred projection equality

1. Unification during coercion (`Coerce::unify`) needs to consider deferred projection obligations (at least pass over them with `predicate_may_hold` or something, to disqualify any totally wrong unifications) -- otherwise, we'll shallowly consider `<u8 as Add>::Output` and `char` as coercible during `FnCtxt::try_coerce`, which will fail later when the nested obligations are registered and processed.

2. Cast checking needs to be able to structurally normalize types so it sees `u8` instead of `<u8 as Add>::Output`. Otherwise it'll always consider the latter as part of a non-primitive cast. Currently `FnCtxt::normalize` doesn't do anything useful here, interestingly.

I tried looking into both of these and it's not immediately clear where to refactor existing typeck code to fix this (at least the latter), but I'm gonna commit a test for it at least so we don't forget. This is one of the issues that's keeping us from building larger projects.
2023-02-24 12:02:42 +05:30
Dylan DPC
6826a96067
Rollup merge of #106923 - mejrs:fluent_err, r=davidtwco
Restore behavior when primary bundle is missing

Fixes https://github.com/rust-lang/rust/issues/106755 by restoring some of the behavior prior to https://github.com/rust-lang/rust/pull/106427

Still, I have no idea how this debug assertion can even hit while using `en-US` as primary  bundle.

r? ```@davidtwco```
2023-02-24 12:02:41 +05:30
Dylan DPC
8c135eecac
Rollup merge of #106541 - fee1-dead-contrib:no-const-check-no, r=thomcc
implement const iterator using `rustc_do_not_const_check`

Previous experiment: #102225.

Explanation: rather than making all default methods work under `const` all at once, this uses `rustc_do_not_const_check` as a workaround to "trick" the compiler to not run any checks on those other default methods. Any const implementations are only required to implement the `next` method. Any actual calls to the trait methods other than `next` will either error in compile time (at CTFE runs), or run the methods correctly if they do not have any non-const operations. This is extremely easy to maintain, remove, or improve.
2023-02-24 12:02:40 +05:30
Michael Goulet
ed30efff3b Comments, another test 2023-02-24 02:53:25 +00:00
Michael Goulet
2540c2b761 Make higher-ranked projections in object types work in new solver 2023-02-24 02:48:44 +00:00
Michael Goulet
98525aeee7 Check object's supertrait and associated type bounds in new solver 2023-02-24 02:45:05 +00:00
Michael Howell
a5b639dc01 diagnostics: remove inconsistent English article "this" from E0107
Consider `tests/ui/const-generics/generic_const_exprs/issue-102768.stderr`,
the error message where it gives additional notes about where the associated
type is defined, and how the dead code lint doesn't have an article,
like in `tests/ui/lint/dead-code/issue-85255.stderr`. They don't have
articles, so it seems unnecessary to have one here.
2023-02-23 10:27:06 -07:00
clubby789
4332a27c2d Fix ICE in 'duplicate diagnostic item' diagnostic 2023-02-23 14:58:48 +00:00
Obei Sideg
99344a8b32 Add ui test for E0271 error 2023-02-23 13:57:13 +03:00
Obei Sideg
b93d54556f Add ui test for map_unit_fn lint in closure case 2023-02-23 13:57:13 +03:00
Obei Sideg
ddd7d10879 Add ui test for map_unit_fn lint 2023-02-23 13:57:13 +03:00
Yutaro Ohno
0e42298674 parser: provide better errors on closures with braces missing
We currently provide wrong suggestions and unhelpful errors on closure
bodies with braces missing. For example, given the following code:

```
fn main() {
    let _x = Box::new(|x|x+1;);
}
```

the current output is like this:

```
error: expected expression, found `)`
 --> ./main.rs:2:30
  |
2 |     let _x = Box::new(|x|x+1;);
  |                              ^ expected expression

error: closure bodies that contain statements must be surrounded by braces
 --> ./main.rs:2:25
  |
2 |     let _x = Box::new(|x|x+1;);
  |                         ^
3 | }
  | ^
  |

...

help: try adding braces
  |
2 ~     let _x = Box::new(|x| {x+1;);
3 ~ }}

...

error: expected `;`, found `}`
 --> ./main.rs:2:32
  |
2 |     let _x = Box::new(|x|x+1;);
  |                                ^ help: add `;` here
3 | }
  | - unexpected token

error: aborting due to 3 previous errors
```

This commit allows outputting correct suggestions and errors. The above
code would output like this:

```
error: closure bodies that contain statements must be surrounded by braces
 --> ./main.rs:2:25
  |
2 |     let _x = Box::new(|x|x+1;);
  |                         ^    ^
  |
note: statement found outside of a block
 --> ./main.rs:2:29
  |
2 |     let _x = Box::new(|x|x+1;);
  |                          ---^ this `;` turns the preceding closure into a statement
  |                          |
  |                          this expression is a statement because of the trailing semicolon
note: the closure body may be incorrectly delimited
 --> ./main.rs:2:23
  |
2 |     let _x = Box::new(|x|x+1;);
  |                       ^^^^^^ - ...but likely you meant the closure to end here
  |                       |
  |                       this is the parsed closure...
help: try adding braces
  |
2 |     let _x = Box::new(|x| {x+1;});
  |                           +    +

error: aborting due to previous error
```
2023-02-23 19:05:13 +09:00
Matthias Krüger
ef27e43807
Rollup merge of #108063 - compiler-errors:associated-type-bounds-in-bad-position, r=cjgillot
Ban associated type bounds in bad positions

We should not try to lower associated type bounds into TAITs in positions where `impl Trait` is not allowed (except for in `where` clauses, like `where T: Trait<Assoc: Bound>`).

This is achieved by using the same `rustc_ast_lowering` machinery as impl-trait does to characterize positions as universal/existential/disallowed.

Fixes #106077

Split out the first commit into #108066, since it's not really related.
2023-02-23 06:18:05 +01:00
Michael Goulet
9bf32c40b4 Don't project specializable RPITIT projection 2023-02-23 02:12:51 +00:00
mejrs
4c13a2157a Add stderr 2023-02-23 02:05:03 +01:00
bors
0978711950 Auto merge of #108324 - notriddle:notriddle/assoc-fn-method, r=compiler-errors,davidtwco,estebank,oli-obk
diagnostics: if AssocFn has self argument, describe as method

Discussed in https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515

This commit also changes the tooltips on rustdoc intra-doc links targeting methods.

For anyone not sure why this is being done, see the Reference definitions of these terms in <https://doc.rust-lang.org/1.67.1/reference/items/associated-items.html#methods>

> Associated functions whose first parameter is named `self` are called methods and may be invoked using the [method call operator](https://doc.rust-lang.org/1.67.1/reference/expressions/method-call-expr.html), for example, `x.foo()`, as well as the usual function call notation.

In particular, while this means it's technically correct for rustc to refer to a method as an associated function (and there are a few cases where it'll still do so), rustc *must never* use the term "method" to refer to an associated function that does not have a `self` parameter.
2023-02-23 00:19:12 +00:00
mejrs
634d8cb757 Test that choosing the default bundle does not ice 2023-02-23 01:14:10 +01:00
icedrocket
313f04f4ff Add regression test for #105626 2023-02-23 08:39:23 +09:00
blyxyas
e39fe374df Add check for invalid \#[macro_export]\ arguments 2023-02-22 21:53:16 +00:00
Michael Goulet
b14eb0c497 pluralize stuff 2023-02-22 21:52:26 +00:00
Michael Goulet
deb135748d Suppress duplicated errors for associated type bounds in object types 2023-02-22 21:52:26 +00:00
bors
da439d9874 Auto merge of #108357 - matthiaskrgr:rollup-ceo3q2s, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - #107736 ( Rename atomic 'as_mut_ptr' to 'as_ptr' to match Cell (ref #66893) )
 - #108176 (Don't delay `ReError` bug during lexical region resolve)
 - #108315 (Lint dead code in closures and generators)
 - #108342 (apply query response: actually define opaque types)
 - #108344 (Fix test filename for #105700)
 - #108353 (resolve: Remove `ImportResolver`)

Failed merges:

 - #107911 (Add check for invalid #[macro_export] arguments)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-02-22 21:24:29 +00:00
Camille GILLOT
958419d354 Move the unused extern crate check back to the resolver. 2023-02-22 20:48:27 +00:00
Michael Goulet
e7c490892f Move associated type bounds check to ast lowering
This makes the check for when associated type bounds more accurate
2023-02-22 20:18:14 +00:00
Matthias Krüger
baf6a72155
Rollup merge of #108344 - Alexendoo:test-105700, r=compiler-errors
Fix test filename for #105700

The test is for #105700 rather than #21102
2023-02-22 20:05:59 +01:00
Matthias Krüger
783617b5e4
Rollup merge of #108315 - clubby789:dead-code-in-closure, r=compiler-errors
Lint dead code in closures and generators

Fixes #108296

I think this might be a potentially breaking change, but restores the behaviour of pre-1.64.

`@rustbot` label +A-lint
2023-02-22 20:05:58 +01:00
Matthias Krüger
4d9effc65c
Rollup merge of #108176 - compiler-errors:bad-lexical-region-resolve-bug, r=oli-obk
Don't delay `ReError` bug during lexical region resolve

Lexical region resolution returns a list of `RegionResolutionError` which don't necessarily correspond to diagnostics being emitted. The compiler may, validly, throw away these resolution errors and do something else. Therefore it's not valid to use `ReError` during lifetime resolution, since we may actually be on a totally fine compilation path.

For example, the `implied_bounds_entailment` lint runs region resolution twice, and only emits an error if it fails both times. If we delay a bug and create a `ReError` during this first run, then we will ICE.

Fixes #108170

----

Side-note: this is conceptually equivalent to how we can't necessarily delay bugs or create `ty::Error` during trait solving/fulfillment, since the compiler is allowed to throw away these fulfillment errors to do other things. It's only once we actually emit an error (`report_region_errors` / `report_fulfillment_errors`)
2023-02-22 20:05:58 +01:00
Jeremy Fitzhardinge
fc5db2cd4f Implement -Zlink-directives=yes/no
`-Zlink-directives=no` will ignored `#[link]` directives while compiling a
crate, so nothing is emitted into the crate's metadata.  The assumption is
that the build system already knows about the crate's native dependencies
and can provide them at link time without these directives.

This is another way to address issue # #70093, which is currently addressed
by `-Zlink-native-libraries` (implemented in #70095). The latter is
implemented at link time, which has the effect of ignoring `#[link]`
in *every* crate. This makes it a very large hammer as it requires all
native dependencies to be known to the build system to be at all usable,
including those in sysroot libraries. I think this means its effectively
unused, and definitely under-used.

Being able to control this on a crate-by-crate basis should make it much
easier to apply when needed.

I'm not sure if we need both mechanisms, but we can decide that later.
2023-02-22 10:18:01 -08:00
Alan Egerton
a9b2354a1d
Normalize line+col in normalize-tait-in-const test 2023-02-22 17:05:04 +00:00
Alan Egerton
695072daa6
Remove type-traversal trait aliases 2023-02-22 17:04:58 +00:00
Michael Howell
3f374128ee diagnostics: update test cases to refer to assoc fn with self as method 2023-02-22 08:40:47 -07:00
clubby789
c7a4f387fd Lint dead code in closures 2023-02-22 15:27:19 +00:00
Alex Macleod
4fba0c0449 Fix test filename for #105700 2023-02-22 13:08:13 +00:00
Guillaume Gomez
437f210af5
Rollup merge of #108239 - clubby789:overlapping-spans, r=compiler-errors
Fix overlapping spans in removing extra arguments

Fixes #108225

Each span is already extended to include the previous comma, so extending to the *next* comma is unecessary and causes an ICE with assertions on.

``@rustbot`` label +A-diagnostics
2023-02-22 10:35:08 +01:00
Guillaume Gomez
a32c500400
Rollup merge of #108230 - LittleFall:enhance/warning, r=estebank
Convert a hard-warning about named static lifetimes into lint "unused_lifetimes"

Fixes https://github.com/rust-lang/rust/issues/96956.

Some changes are ported from https://github.com/rust-lang/rust/pull/98079, thanks to jeremydavis519.

r? `@estebank` `@petrochenkov`

Any feedback is appreciated!

## Actions
- [x] resolve conflicts
- [x] fix build
- [x] address review comments in last pr
- [x] update tests
2023-02-22 10:35:08 +01:00
Guillaume Gomez
89c201e3be
Rollup merge of #108168 - clubby789:recursive-type-alias, r=compiler-errors
Fix ICE on type alias in recursion

Fixes #108160
2023-02-22 10:35:07 +01:00
Zhi Qi
ce2ae62d68 Convert a hard-warning about named static lifetimes into lint "unused_lifetimes"
Define the `named_static_lifetimes` lint

This lint will replace the existing hard-warning.

Replace the named static lifetime hard-warning with the new lint

Update the UI tests for the `named_static_lifetimes` lint

Remove the direct dependency on `rustc_lint_defs`

fix build

Signed-off-by: Zhi Qi <qizhi@pingcap.com>

use "UNUSED_LIFETIMES" instead

Signed-off-by: Zhi Qi <qizhi@pingcap.com>

update 1 test and fix typo

Signed-off-by: Zhi Qi <qizhi@pingcap.com>

update tests

Signed-off-by: Zhi Qi <qizhi@pingcap.com>

fix tests: add extra blank line

Signed-off-by: Zhi Qi <qizhi@pingcap.com>
2023-02-22 09:44:26 +08:00
Matthias Krüger
ae01430078
Rollup merge of #108295 - compiler-errors:wtf-is-this, r=cjgillot
Use DefKind to give more item kind information during BindingObligation note

The current label says "required by a bound in this". When I see that label, my immediate impression is "this... **what**?". It feels like it was cut short.

Alternative to this would be saying "in this item", but adding the item kind is strictly more informational and adds very little overhead to the existing error presentation.
2023-02-21 23:02:00 +01:00
Matthias Krüger
8a5843f07f
Rollup merge of #108202 - compiler-errors:non_lifetime_binders-type-match-ice, r=davidtwco
Make sure `test_type_match` doesn't ICE with late-bound types

Fixes #108190 (in a kind of hacky way, anyways doesn't really matter)
2023-02-21 23:01:59 +01:00
bors
f4c7596ac3 Auto merge of #108311 - oli-obk:invert_defines, r=lcnr
Make hidden type registration opt-in, so that each site can be reviewed on its own and we have the right defaults for trait solvers

r? `@lcnr`

pulled out of https://github.com/rust-lang/rust/pull/107891 as it is the uncontroversial part
2023-02-21 15:48:40 +00:00
Oli Scherer
88a7b6803b Make hidden type registration opt-in, so that each site can be reviewed on its own and we have the right defaults for trait solvers 2023-02-21 14:50:51 +00:00
clubby789
0b9a3e29d4 Fix overlapping spans in removing extra arguments 2023-02-21 13:13:09 +00:00
bors
3200982b76 Auto merge of #108138 - compiler-errors:malformed-fn-trait, r=TaKO8Ki
Move `Fn*` traits malformedness protections to typeck

I found it strange that we were doing a custom well-formedness check just for the `Fn*` traits' `call_*` fn items. My understanding from the git history is that this is just to avoid ICEs later on in typeck.

Well, that well-formedness check isn't even implemented correctly for `FnOnce::call_once`, or `FnMut::call_mut` for that matter. Instead, this PR just makes the typeck checks more robust, and leaves it up to the call-site to report errors when lang items are implemented in funny ways.

This coincidentally fixes another ICE where a the `Add` lang item is implemented with a `add` item that's a const instead of a method.
2023-02-21 12:59:11 +00:00
bors
bda32a4023 Auto merge of #108301 - Dylan-DPC:rollup-70zpkt0, r=Dylan-DPC
Rollup of 7 pull requests

Successful merges:

 - #108000 (lint: don't suggest MaybeUninit::assume_init for uninhabited types)
 - #108105 (Explain the default panic hook better)
 - #108141 (Add rpitit queries)
 - #108272 (docs: wrong naming convention in struct keyword doc)
 - #108285 (remove unstable `pick_stable_methods_before_any_unstable` flag)
 - #108289 (Name placeholder in some region errors)
 - #108290 (Add a test for default trait method with RPITITs)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2023-02-21 09:51:03 +00:00
Dylan DPC
60c0972af7
Rollup merge of #108290 - compiler-errors:rpitit-trait-default-constraint, r=oli-obk
Add a test for default trait method with RPITITs

This didn't work in #107013, but now that #108203 has landed, let's make sure we don't regress it.

r? types
2023-02-21 14:20:01 +05:30
Dylan DPC
270f45e172
Rollup merge of #108289 - compiler-errors:name-placeholder, r=petrochenkov
Name placeholder in some region errors

Also don't print `ReVar` or `ReLateBound` as debug... these error messages are super uncommon anyways, but in the case they do trigger, let's be slightly more helpful.
2023-02-21 14:20:01 +05:30
Dylan DPC
4dea3a295f
Rollup merge of #108000 - y21:no-zero-init-for-uninhabited, r=jackh726
lint: don't suggest MaybeUninit::assume_init for uninhabited types

Creating a zeroed uninhabited type such as `!` or an empty enum with `mem::zeroed()` (or transmuting `()` to `!`) currently triggers this lint:
```rs
warning: the type `!` does not permit zero-initialization
 --> test.rs:5:23
  |
5 |         let _val: ! = mem::zeroed();
  |                       ^^^^^^^^^^^^^
  |                       |
  |                       this code causes undefined behavior when executed
  |                       help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
  |
  = note: the `!` type has no valid value
```
The `MaybeUninit` suggestion in the help message seems confusing/useless for uninhabited types, as such a type cannot be fully initialized in the first place (as the note implies).
This PR limits this help message to inhabited types which can be initialized
2023-02-21 14:19:58 +05:30
bors
3fee48c161 Auto merge of #104754 - nnethercote:more-ThinVec-in-ast, r=the8472
Use `ThinVec` more in the AST

r? `@ghost`
2023-02-21 07:02:57 +00:00
Michael Goulet
a58682d7cc Specify what 'this' actually is 2023-02-21 05:21:07 +00:00
bors
f715e430aa Auto merge of #107728 - RalfJung:miri-dyn-star, r=RalfJung,oli-obk
Miri: basic dyn* support

As usual I am very unsure about the dynamic dispatch stuff, but it passes even the `Pin<&mut dyn* Trait>` test so that is something.

TBH I think it was a mistake to make `dyn Trait` and `dyn* Trait` part of the same `TyKind` variant. Almost everywhere in Miri this lead to the wrong default behavior, resulting in strange ICEs instead of nice "unimplemented" messages. The two types describe pretty different runtime data layout after all.

Strangely I did not need to do the equivalent of [this diff](https://github.com/rust-lang/rust/pull/106532#discussion_r1087095963) in Miri. Maybe that is because the unsizing logic matches on `ty::Dynamic(.., ty::Dyn)` already? In `unsized_info` I don't think the `target_dyn_kind` can be `DynStar`, since then it wouldn't be unsized!

r? `@oli-obk` Cc `@eholk` (dyn-star) https://github.com/rust-lang/rust/issues/102425
2023-02-21 04:22:23 +00:00
Michael Goulet
dfc4a580f2 Add a test for default trait method with RPITITs 2023-02-21 02:01:26 +00:00
bors
2deff71719 Auto merge of #105462 - oli-obk:feeding_full, r=cjgillot,petrochenkov
give the resolver access to TyCtxt

The resolver is now created after TyCtxt is created. Then macro expansion and name resolution are run and the results fed into queries just like before this PR.

Since the resolver had (before this PR) mutable access to the `CStore` and the source span table, these two datastructures are now behind a `RwLock`. To ensure that these are not mutated anymore after the resolver is done, a read lock to them is leaked right after the resolver finishes.

### PRs split out of this one and leading up to it:

* https://github.com/rust-lang/rust/pull/105423
* https://github.com/rust-lang/rust/pull/105357
* https://github.com/rust-lang/rust/pull/105603
* https://github.com/rust-lang/rust/pull/106776
* https://github.com/rust-lang/rust/pull/106810
* https://github.com/rust-lang/rust/pull/106812
* https://github.com/rust-lang/rust/pull/108032
2023-02-21 01:19:25 +00:00
Nicholas Nethercote
7e855d5f31 Use ThinVec in a few more AST types. 2023-02-21 11:51:56 +11:00
Nicholas Nethercote
912b825002 Use ThinVec in ast::PatKind::Struct. 2023-02-21 11:51:56 +11:00
Nicholas Nethercote
b14b7ba5dd Use ThinVec in ast::Block. 2023-02-21 11:51:56 +11:00
Nicholas Nethercote
4143b101f9 Use ThinVec in various AST types.
This commit changes the sequence parsers to produce `ThinVec`, which
triggers numerous conversions.
2023-02-21 11:51:56 +11:00
Nicholas Nethercote
068db466e8 Use ThinVec in ast::WhereClause. 2023-02-21 11:51:55 +11:00
Nicholas Nethercote
dd7aff5cc5 Use ThinVec in ast::Generics and related types. 2023-02-21 11:51:55 +11:00
Michael Goulet
eb1f9babec Add test for bad cast with deferred projection equality 2023-02-21 00:07:06 +00:00
Michael Goulet
2895731e5e Name placeholder in some region errors 2023-02-21 00:00:49 +00:00
Matthias Krüger
194d52cc18
Rollup merge of #108254 - Nathan-Fenner:nathanf/error-span-ref-trait-refine, r=WaffleLapkin
Refine error span for trait error into borrowed expression

Extends the error span refinement in #106477 to drill into borrowed expressions just like tuples/struct/enum literals. For example,

```rs
trait Fancy {}
trait Good {}
impl <'a, T> Fancy for &'a T where T: Good {}
impl <S> Good for Option<S> where S: Iterator {}

fn want_fancy<F>(f: F) where F: Fancy {}

fn example() {
    want_fancy(&Some(5));
//  (BEFORE)   ^^^^^^^^ `{integer}` is not an iterator
//  (AFTER)          ^  `{integer}` is not an iterator
}
```

Existing heuristics try to find the right part of the expression to "point at"; current heuristics look at e.g. struct constructors and tuples. This PR adds a new check for borrowed expressions when looking into a borrowed type.
2023-02-20 22:12:18 +01:00
bors
8973049549 Auto merge of #108268 - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #108124 (Document that CStr::as_ptr returns a type alias)
 - #108171 (Improve building compiler artifacts output)
 - #108200 (Use restricted Damerau-Levenshtein distance for diagnostics)
 - #108259 (remove FIXME that doesn't require fixing)
 - #108265 ("`const` generic" -> "const parameter")

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
2023-02-20 16:19:06 +00:00
Oli Scherer
c3522d0637 Move the resolver into a query 2023-02-20 15:28:59 +00:00
Ralf Jung
57056d7f8f slightly beef up dyn-star-to-dyn test 2023-02-20 15:08:05 +01:00
Ralf Jung
b2f58146b9 basic dyn* support for Miri 2023-02-20 15:08:05 +01:00
Matthias Krüger
e4dadd6416
Rollup merge of #108265 - lcnr:cg-error-msg, r=BoxyUwU
"`const` generic" -> "const parameter"
2023-02-20 14:32:56 +01:00
Matthias Krüger
226ce31edd
Rollup merge of #108200 - jhpratt:restricted-damerau-levenshtein-distance, r=tmiasko
Use restricted Damerau-Levenshtein distance for diagnostics

This replaces the existing Levenshtein algorithm with the Damerau-Levenshtein algorithm. This means that "ab" to "ba" is one change (a transposition) instead of two (a deletion and insertion). More specifically, this is a _restricted_ implementation, in that "ca" to "abc" cannot be performed as "ca" → "ac" → "abc", as there is an insertion in the middle of a transposition. I believe that errors like that are sufficiently rare that it's not worth taking into account.

This was first brought up [on IRLO](https://internals.rust-lang.org/t/18227) when it was noticed that the diagnostic for `prinltn!` (transposed L and T) was `print!` and not `println!`. Only a single existing UI test was effected, with the result being an objective improvement.

~~I have left the method name and various other references to the Levenshtein algorithm untouched, as the exact manner in which the edit distance is calculated should not be relevant to the caller.~~

r? ``@estebank``

``@rustbot`` label +A-diagnostics +C-enhancement
2023-02-20 14:32:55 +01:00
bors
267cd1d2c5 Auto merge of #107721 - megakorre:issue_105700, r=petrochenkov
create dummy placeholder crate to prevent compiler from panicing

This PR is to address the panic found in https://github.com/rust-lang/rust/issues/105700.

There are 2 separate things going on with this panic.
First the code could not generate a dummy response for crate fragment types when it hits the recursion limit.
This PR adds the method to the trait implementation for `DymmyResult` to be able to create a dummy crate node.
This stops the panic from happening.

The second thing that is not addressed (and maybe does not need addressing? 🤷🏻)
is that when you have multiple attributes it ends up treating attributes that follow another as being the result of expanding the former (maybe there is a better way to say that). So you end up hitting the recursion limit. Even though you would think there is no expansion happening here.

If you did not hit the recursion limit the compiler would output that `invalid_attribute` does not exists. But it currently exits before the resolution step when the recursion limit is reached here.
2023-02-20 13:23:47 +00:00
lcnr
2cbe583593 const generic -> const parameter in err msg 2023-02-20 12:58:11 +01:00
bors
e7eaed21d5 Auto merge of #107969 - b-naber:proj-relate-variance, r=lcnr
Use covariance on type relations of field projection types if possible

It's fine to use covariance here unless we're in a mutating context.

Fixes https://github.com/rust-lang/rust/issues/96514

Supersedes https://github.com/rust-lang/rust/pull/105958

r? `@lcnr`
2023-02-20 09:25:51 +00:00
Patrik Kårlin
0fd2a70b90
create dummy placeholder crate to prevent compiler 2023-02-20 10:20:57 +01:00
Nathan Fenner
fbcca2aaf0 Refine error span for trait error into borrowed expression 2023-02-19 21:27:04 -08:00
bors
7b552967b8 Auto merge of #105961 - fmease:iat-type-directed-probing, r=jackh726
Type-directed probing for inherent associated types

When probing for inherent associated types (IATs), equate the Self-type found in the projection with the Self-type of the relevant inherent impl blocks and check if all predicates are satisfied.
Previously, we didn't look at the Self-type or at the bounds and just picked the first inherent impl block containing an associated type with the name we were searching for which is obviously incorrect.

Regarding the implementation, I basically copied what we do during method probing (`assemble_inherent_impl_probe`, `consider_probe`). Unfortunately, I had to duplicate a lot of the diagnostic code found in `rustc_hir_typeck::method::suggest` which we don't have access to in `rustc_hir_analysis`. Not sure if there is a simple way to unify the error handling. Note that in the future, `rustc_hir_analysis::astconv` might not actually be the place where we resolve inherent associated types (see https://github.com/rust-lang/rust/pull/103621#issuecomment-1304309565) but `rustc_hir_typeck` (?) in which case the duplication may naturally just disappear. While inherent associated *constants* are currently resolved during "method" probing, I did not find a straightforward way to incorporate IAT lookup into it as types and values (functions & constants) are two separate entities for which distinct code paths are taken.

Fixes #104251 (incl. https://github.com/rust-lang/rust/issues/104251#issuecomment-1338501171).
Fixes #105305.
Fixes #107468.

`@rustbot` label T-types F-inherent_associated_types
r? types
2023-02-20 00:37:20 +00:00
León Orell Valerian Liehr
00b976a138
Collect fulfillment errors across impls 2023-02-19 22:54:08 +01:00
bors
21e5b941e0 Auto merge of #108128 - clubby789:builtin-derived-attr, r=jackh726
Properly check for builtin derived code

Fixes #108122
2023-02-19 21:18:07 +00:00
León Orell Valerian Liehr
6eb6455c46
Add a test and several known bugs 2023-02-19 18:35:36 +01:00