Commit Graph

149 Commits

Author SHA1 Message Date
VulnBandit
9a2772e1c2 Don't assume traits used as type are trait objs 2024-10-11 17:36:04 +02:00
Esteban Küber
7f5548fa8b On function and method calls in patterns, link to the book
```
error: expected a pattern, found an expression
 --> f889.rs:3:13
  |
3 |     let (x, y.drop()) = (1, 2); //~ ERROR
  |             ^^^^^^^^ not a pattern
  |
  = note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>

error[E0532]: expected a pattern, found a function call
 --> f889.rs:2:13
  |
2 |     let (x, drop(y)) = (1, 2); //~ ERROR
  |             ^^^^ not a tuple struct or tuple variant
  |
  = note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html>
```

Fix #97200.
2024-10-06 01:44:59 +00:00
Matthias Krüger
a935064fae
Rollup merge of #130826 - fmease:compiler-mv-obj-safe-dyn-compat, r=compiler-errors
Compiler: Rename "object safe" to "dyn compatible"

Completed T-lang FCP: https://github.com/rust-lang/lang-team/issues/286#issuecomment-2338905118.
Tracking issue: https://github.com/rust-lang/rust/issues/130852

Excludes `compiler/rustc_codegen_cranelift` (to be filed separately).
Includes Stable MIR.

Regarding https://github.com/rust-lang/rust/labels/relnotes, I guess I will manually open a https://github.com/rust-lang/rust/labels/relnotes-tracking-issue since this change affects everything (compiler, library, tools, docs, books, everyday language).

r? ghost
2024-09-27 21:35:08 +02:00
Esteban Küber
c7d171d771 On implicit Sized bound on fn argument, point at type instead of pattern
Instead of

```
error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time
  --> $DIR/issue-59324.rs:23:20
   |
LL | fn with_factory<H>(factory: dyn ThriftService<()>) {}
   |                    ^^^^^^^ doesn't have a size known at compile-time
```

output

```
error[E0277]: the size for values of type `(dyn ThriftService<(), AssocType = _> + 'static)` cannot be known at compilation time
  --> $DIR/issue-59324.rs:23:29
   |
LL | fn with_factory<H>(factory: dyn ThriftService<()>) {}
   |                             ^^^^^^^^^^^^^^^^^^^^^ doesn't have a size known at compile-time
```
2024-09-27 00:45:02 +00:00
León Orell Valerian Liehr
01a063f9df
Compiler: Rename "object safe" to "dyn compatible" 2024-09-25 13:26:48 +02:00
Michael Goulet
29f31c58e9 Don't call fn_arg_names for non-fn in resolver 2024-09-07 07:38:22 -04:00
Michael Goulet
78d0e08504 Don't consider RibKind::Module's bindings when checking generics shadowing 2024-08-19 17:24:27 -04:00
Esteban Küber
b61570ac11 Structured suggestion for extern crate foo when foo isn't resolved in import
When encountering a name in an import that could have come from a crate that wasn't imported, use a structured suggestion to suggest `extern crate foo;` pointing at the right place in the crate.

When encountering `_` in an import, do not suggest `extern crate _;`.

```
error[E0432]: unresolved import `spam`
  --> $DIR/import-from-missing-star-3.rs:2:9
   |
LL |     use spam::*;
   |         ^^^^ maybe a missing crate `spam`?
   |
help: consider importing the `spam` crate
   |
LL + extern crate spam;
   |
```
2024-07-29 23:49:51 +00:00
Trevor Gross
c5788d618e
Rollup merge of #127557 - linyihai:issue-126694, r=compiler-errors
Add a label to point to the lacking macro name definition

Fixes https://github.com/rust-lang/rust/issues/126694, but adopts the suggestion from https://github.com/rust-lang/rust/issues/118295

```
 --> src/main.rs:1:14
  |
1 | macro_rules! {
  |            ^ put a macro name here
```
2024-07-26 02:20:30 -04:00
Trevor Gross
ceae37188b
Rollup merge of #126575 - fmease:update-lint-type_alias_bounds, r=compiler-errors
Make it crystal clear what lint `type_alias_bounds` actually signifies

This is part of my work on https://github.com/rust-lang/rust/labels/F-lazy_type_alias ([tracking issue](#112792)).

---

To recap, the lint `type_alias_bounds` detects bounds on generic parameters and where clauses on (eager) type aliases. These bounds should've never been allowed because they are currently neither enforced[^1] at usage sites of type aliases nor thoroughly checked for correctness at definition sites due to the way type aliases are represented in the compiler. Allowing them was an oversight.

Explicitly label this as a known limitation of the type checker/system and establish the experimental feature `lazy_type_alias` as its eventual proper solution.

Where this becomes a bit tricky (for me as a rustc dev) are the "secondary effects" of these bounds whose existence I sadly can't deny. As a matter of fact, type alias bounds do play some small roles during type checking. However, after a lot of thinking over the last two weeks I've come to the conclusion (not without second-guessing myself though) that these use cases should not trump the fact that these bounds are currently *inherently broken*. Therefore the lint `type_alias_bounds` should and will continue to flag bounds that may have subordinate uses.

The two *known* secondary effects are:

1. They may enable the use of "shorthand" associated type paths `T::Assoc` (as opposed to fully qualified paths `<T as Trait>::Assoc`) where `T` is a type param bounded by some trait `Trait` which defines that assoc ty.
2. They may affect the default lifetime of trait object types passed as a type argument to the type alias. That concept is called (trait) object lifetime default.

The second one is negligible, no question asked. The first one however is actually "kinda nice" (for writability) and comes up in practice from time to time.

So why don't I just special-case trait bounds that "define" shorthand assoc type paths as originally planned in #125709?

1. Starting to permit even a tiny subset of bounds would already be enough to send a signal to users that bounds in type aliases have been legitimized and that they can expect to see type alias bounds in the wild from now on (proliferation). This would be actively misleading and dangerous because those bounds don't behave at all like one would expect, they are *not real*[^2]!
   1. Let's take `type A<T: Trait> = T::Proj;` for example. Everywhere else in the language `T: Trait` means `T: Trait + Sized`. For type aliases, that's not the case though: `T: Trait` and `T: Trait + ?Sized` for that matter do neither mean `T: Trait + Sized` nor `T: Trait + ?Sized` (for both!). Instead, whether `T` requires `Sized` or not entirely depends on the definition of `Trait`[^2]. Namely, whether or not it is bounded by `Sized`.
   2. Given `type A<T: Trait<AssocA = ()>> = T::AssocB;`, while `X: Trait` gets checked given `A<X>` (by virtue of projection wfchecking post alias expansion[^2]), the associated type constraint `AssocA = ()` gets dropped entirely! While we could choose to warn on such cases, it would inevitably lead to a huge pile of special cases.
   3. While it's common knowledge that the body / aliased type / RHS of an (eager) type alias does not get checked for well-formedness, I'm not sure if people would realize that that extends to bounds as well. Namely, `type A<T: Trait<[u8]>> = T::Proj;` compiles even if `Trait`'s generic parameter requires `Sized`. Of course, at usage sites `[u8]: Sized` would still end up getting checked[^2], so it's not a huge problem if you have full control over `A`. However, imagine that `A` was actually part of a public API and was never used inside the defining crate (not unreasonable). In such a scenario, downstream users would be presented with an impossible to use type alias! Remember, bounds may grow arbitrarily complex and nuanced in practice.
   4. Even if we allowed trait bounds that "define" shorthand assoc type paths, we would still need to continue to warn in cases where the assoc ty comes from a supertrait despite the fact that the shorthand syntax can be used: `type A<T: Sub> = T::Assoc;` does compile given `trait Sub: Super {}` and `trait Super { type Assoc; }`. However, `A<X>` does not enforce `X: Sub`, only `X: Super`[^2]. All that to say, type alias bounds are simply not real and we shouldn't pretend they are!
   5. Summarizing the points above, we would be legitimizing bounds that are completely broken!
2. It's infeasible to implement: Due to the lack of `TypeckResults` in `ItemCtxt` (and a way to propagate it to other parts of the compiler), the resolution of type-dependent paths in non-`Body` items (most notably type aliases) is not recoverable from the HIR alone which would be necessary because the information of whether an associated type path (projection) is a shorthand is only present pre&in-HIR and doesn't survive HIR ty lowering. Of course, I could rerun parts of HIR ty lowering inside the lint `type_alias_bounds` (namely, `probe_single_ty_param_bound_for_assoc_ty` which would need to be exposed or alternatively a stripped-down version of it). This likely has a performance impact and introduces complexity. In short, the "benefits" are not worth the costs.

---

* 3rd commit: Update a diagnostic to avoid suggesting type alias bounds
* 4th commit: Flag type alias bounds even if the RHS contains inherent associated types.
  * I started to allow them at some point in the past which was not correct (see commit for details)
* 5th commit: Allow type alias bounds if the RHS contains const projections and GCEs are enabled
  * (and add a `FIXME(generic_const_exprs)` to be revisited before (M)GCE's stabilization)
  * As a matter of fact type alias bounds are enforced in this case because the contained AnonConsts do get checked for well-formedness and crucially they inherit the generics and predicates of their parent item (here: the type alias)
* Remaining commits: Improve the lint `type_alias_bounds` itself

---

Fixes #125789 (sugg diag fix).
Fixes #125709 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #104918 (sugg diag applic fix).
Fixes #100270 (wontfix, acknowledgement, sugg diag applic fix).
Fixes #94398 (true fix).

r? `@compiler-errors` `@oli-obk`

[^1]: From the perspective of the trait solver.
[^2]: Given `type A<T: Trait> = T::Proj;`, the reason why the trait bound "`T: Trait`" gets *seemingly* enforced at usage sites of the type alias `A` is simply because `A<X>` gets expanded to "`<X as Trait>::Proj`" very early on and it's the *expansion* that gets checked for well-formedness, not the type alias reference.
2024-07-26 02:20:28 -04:00
Lin Yihai
2fca4ea317 Add a label to point to the lacking macro name definition 2024-07-26 10:51:55 +08:00
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
León Orell Valerian Liehr
3c8b108512
Inside eager ty aliases on unresolved assoc tys suggest fully qualifying instead of restricting their self ty 2024-07-23 01:26:24 +02:00
Esteban Küber
921de9d8ea Revert suggestion verbosity change 2024-07-22 22:51:53 +00:00
Esteban Küber
5c2b36a21c Change suggestion message wording 2024-07-22 22:04:49 +00:00
Esteban Küber
c807ac0340 Use verbose suggestion for "wrong # of generics" 2024-07-22 22:04:49 +00:00
Esteban Küber
ec7a188f16 More accurate suggestions when writing wrong style of enum variant literal
```
error[E0533]: expected value, found struct variant `E::Empty3`
  --> $DIR/empty-struct-braces-expr.rs:18:14
   |
LL |     let e3 = E::Empty3;
   |              ^^^^^^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     let e3 = E::Empty3 {};
   |                        ++
```
```
error[E0533]: expected value, found struct variant `E::V`
  --> $DIR/struct-literal-variant-in-if.rs:10:13
   |
LL |     if x == E::V { field } {}
   |             ^^^^ not a value
   |
help: you might have meant to create a new value of the struct
   |
LL |     if x == (E::V { field }) {}
   |             +              +
```
```
error[E0618]: expected function, found enum variant `Enum::Unit`
  --> $DIR/suggestion-highlights.rs:15:5
   |
LL |     Unit,
   |     ---- enum variant `Enum::Unit` defined here
...
LL |     Enum::Unit();
   |     ^^^^^^^^^^--
   |     |
   |     call expression requires function
   |
help: `Enum::Unit` is a unit enum variant, and does not take parentheses to be constructed
   |
LL -     Enum::Unit();
LL +     Enum::Unit;
   |
```
```
error[E0599]: no variant or associated item named `tuple` found for enum `Enum` in the current scope
  --> $DIR/suggestion-highlights.rs:36:11
   |
LL | enum Enum {
   | --------- variant or associated item `tuple` not found for this enum
...
LL |     Enum::tuple;
   |           ^^^^^ variant or associated item not found in `Enum`
   |
help: there is a variant with a similar name
   |
LL |     Enum::Tuple(/* i32 */);
   |           ~~~~~~~~~~~~~~~~;
   |
```
2024-07-18 18:20:35 +00:00
Esteban Küber
8eb51852a8 Accurate use rename suggestion span
When suggesting to rename an import with `as`, use a smaller span to
render the suggestion with a better format:

```
error[E0252]: the name `baz` is defined multiple times
  --> $DIR/issue-25396.rs:4:5
   |
LL | use foo::baz;
   |     -------- previous import of the module `baz` here
LL | use bar::baz;
   |     ^^^^^^^^ `baz` reimported here
   |
   = note: `baz` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
   |
LL | use bar::baz as other_baz;
   |              ++++++++++++
```
2024-07-18 00:00:04 +00:00
Zalathar
9aaa0c5867 Always use a colon in //@ normalize-*: headers 2024-07-11 12:23:44 +10:00
Oli Scherer
8c2ea715e9 Use field ident spans directly instead of the full field span in diagnostics on local fields 2024-07-06 19:22:05 +00:00
Esteban Küber
8e9a3661a8 Use verbose style for argument removal suggestion 2024-07-05 19:40:09 +00:00
bohan
1e42bb606d collect attrs in const block expr 2024-06-20 19:59:27 +08:00
Esteban Küber
5de8e6edfc Tweak output of import suggestions
When both `std::` and `core::` items are available, only suggest the
`std::` ones. We ensure that in `no_std` crates we suggest `core::`
items.

Ensure that the list of items suggested to be imported are always in the
order of local crate items, `std`/`core` items and finally foreign crate
items.

Tweak wording of import suggestion: if there are multiple items but they
are all of the same kind, we use the kind name and not the generic "items".

Fix #83564.
2024-06-13 20:22:21 +00:00
Jubilee
78d9a7e107
Rollup merge of #125906 - compiler-errors:simplify-method-error-args, r=fmease
Remove a bunch of redundant args from `report_method_error`

Rebased on top of #125397 because I had originally asked there (https://github.com/rust-lang/rust/pull/125397#discussion_r1610124799) for this change to be made, but I just chose to do it myself.

r? fmease
2024-06-05 01:14:32 -07:00
Jubilee
9ccc7b78ec
Rollup merge of #123168 - joshtriplett:size-of-prelude, r=Amanieu
Add `size_of` and `size_of_val` and `align_of` and `align_of_val` to the prelude

(Note: need to update the PR to add `align_of` and `align_of_val`, and remove the second commit with the myriad changes to appease the lint.)

Many, many projects use `size_of` to get the size of a type. However,
it's also often equally easy to hardcode a size (e.g. `8` instead of
`size_of::<u64>()`). Minimizing friction in the use of `size_of` helps
ensure that people use it and make code more self-documenting.

The name `size_of` is unambiguous: the name alone, without any prefix or
path, is self-explanatory and unmistakeable for any other functionality.
Adding it to the prelude cannot produce any name conflicts, as any local
definition will silently shadow the one from the prelude. Thus, we don't
need to wait for a new edition prelude to add it.
2024-06-05 01:14:29 -07:00
Michael Goulet
8f08625443 Remove a bunch of redundant args from report_method_error 2024-06-03 20:29:09 -04:00
Gurinder Singh
273a78b05b Do not suggest unresolvable builder methods 2024-05-23 07:23:59 +05:30
Josh Triplett
a5a60d75a8 Add size_of, size_of_val, align_of, and align_of_val to the prelude
Many, many projects use `size_of` to get the size of a type. However,
it's also often equally easy to hardcode a size (e.g. `8` instead of
`size_of::<u64>()`). Minimizing friction in the use of `size_of` helps
ensure that people use it and make code more self-documenting.

The name `size_of` is unambiguous: the name alone, without any prefix or
path, is self-explanatory and unmistakeable for any other functionality.
Adding it to the prelude cannot produce any name conflicts, as any local
definition will silently shadow the one from the prelude. Thus, we don't
need to wait for a new edition prelude to add it.

Add `size_of_val`, `align_of`, and `align_of_val` as well, with similar
justification: widely useful, self-explanatory, unmistakeable for
anything else, won't produce conflicts.
2024-05-13 15:11:28 +02:00
bors
fc47cf38e5 Auto merge of #123850 - tspiteri:f16_f128_consts, r=Amanieu
Add constants for f16 and f128

- Commit 1 adds associated constants for `f16`, excluding NaN and infinities as these are implemented using arithmetic for `f32` and `f64`.
- Commit 2 adds associated constants for `f128`, excluding NaN and infinities.
- Commit 3 adds constants in `std::f16::consts`.
- Commit 4 adds constants in `std::f128::consts`.
2024-05-06 14:45:28 +00:00
Urgau
d4e26fbb53 compiletest: add enable-by-default check-cfg 2024-05-04 11:30:38 +02:00
Trevor Spiteri
d8e6b81b59 update error messages in ui tests 2024-05-02 15:13:30 +02:00
Caio
3aaa3941fd Move some tests 2024-04-21 15:43:43 -03:00
Michael Goulet
6288a721f5 Delay span bug when Self resolves to DefKind::{Mod,Trait} 2024-04-15 21:05:15 -04:00
Trevor Gross
9a7b176227 Update f16 and f128 tests to run on both 2015 and 2018 editions
Reproduce the bug from <https://github.com/rust-lang/rust/issues/123282>
that indicates this feature gate hits edition-dependent resolution paths.
Resolution changed in edition 2018, so test that as well.
2024-04-03 16:03:22 -04:00
Oli Scherer
6201ad9205 Update documentation 2024-03-20 09:49:57 +00:00
Oli Scherer
afdcae2860 Rename mir_const query to mir_built 2024-03-20 09:05:22 +00:00
Oli Scherer
36728f1cdd Replace mir_built query with a hook and use mir_const everywhere instead 2024-03-20 09:05:09 +00:00
Esteban Küber
6c31f6ce12 Provide structured suggestion for #![feature(foo)]
```
error: `S2<'_>` is forbidden as the type of a const generic parameter
  --> $DIR/lifetime-in-const-param.rs:5:23
   |
LL | struct S<'a, const N: S2>(&'a ());
   |                       ^^
   |
   = note: the only supported types are integers, `bool` and `char`
help: add `#![feature(adt_const_params)]` to the crate attributes to enable more complex and user defined types
   |
LL + #![feature(adt_const_params)]
   |
```

Fix #55941.
2024-03-18 16:08:58 +00:00
bors
c03ea3dfd9 Auto merge of #121926 - tgross35:f16-f128-step3-feature-gate, r=compiler-errors,petrochenkov
`f16` and `f128` step 3: compiler support & feature gate

Continuation of https://github.com/rust-lang/rust/pull/121841, another portion of https://github.com/rust-lang/rust/pull/114607

This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed).

If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes.

Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step.

Tracking issue: https://github.com/rust-lang/rust/issues/116909

r? `@compiler-errors`
cc `@Nilstrieb`
`@rustbot` label +F-f16_and_f128
2024-03-16 02:02:00 +00:00
Trevor Gross
2098fec080 Add UI tests related to feature-gated primitives
Add a test that `f16` and `f128` are usable with the feature gate
enabled, as well as a test that user types with the same name as
primitives are not improperly gated.
2024-03-14 13:32:54 -04:00
Trevor Gross
e782d27ec6 Add feature gates for f16 and f128
Includes related tests and documentation pages.

Michael Goulet: Don't issue feature error in resolver for f16/f128
unless finalize

Co-authored-by: Michael Goulet <michael@errs.io>
2024-03-14 13:32:54 -04:00
surechen
1a81a941ad fixes #121331 2024-03-14 09:54:42 +08:00
bors
a655e648a9 Auto merge of #122190 - matthiaskrgr:rollup-9ol4y30, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #121025 (add known-bug tests for derive failure to detect packed repr)
 - #121194 (Refactor pre-getopts command line argument handling)
 - #121563 (Use `ControlFlow` in visitors.)
 - #122173 (Don't ICE in CTFE if raw/fn-ptr types differ)
 - #122175 (Bless tidy issues order)
 - #122179 (rustc: Fix typo)
 - #122181 (Fix crash in internal late lint checking)
 - #122183 (interpret: update comment about read_discriminant on uninhabited variants)

Failed merges:

 - #122076 (Tweak the way we protect in-place function arguments in interpreters)
 - #122132 (Diagnostic renaming 3)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-03-08 17:31:00 +00:00
Oli Scherer
bed9d1fb7d Add known-bug tests for derive(PartialEq) mismatches with #[repr(packed)] attributes that are not visible before macro expansion 2024-03-07 21:40:11 +00:00
Oli Scherer
ae50e36dfa Merge collect_mod_item_types query into check_well_formed 2024-03-07 14:26:31 +00:00
clubby789
367126d49a If suggestion would leave an empty line, delete it 2024-03-01 13:48:20 +00:00
Nicholas Nethercote
ec25d6db53 Don't cancel stashed TraitMissingMethod errors.
This gives one extra error message on two tests, but is necessary to fix
bigger problems caused by the cancellation of stashed errors.

(Note: why not just avoid stashing altogether? Because that resulted in
additional output changes.)
2024-02-29 11:05:40 +11:00
Esteban Küber
28c028737d Deduplicate some logic and reword output 2024-02-22 18:05:28 +00:00
Esteban Küber
e1e4da2b0a Make confusable suggestions verbose 2024-02-22 18:04:55 +00:00
许杰友 Jieyou Xu (Joe)
ec2cc761bc
[AUTO-GENERATED] Migrate ui tests from // to //@ directives 2024-02-16 20:02:50 +00:00