Commit Graph

2000 Commits

Author SHA1 Message Date
Matthias Krüger
6b47c6d786
Rollup merge of #132787 - maxcabrajac:fnctxt, r=petrochenkov
Unify FnKind between AST visitors and make WalkItemKind more straight forward

Unifying `FnKind` requires a bunch of changes to `WalkItemKind::walk` signature so I'll change them in one go

related to #128974

r? `@petrochenkov`
2024-11-16 21:05:46 +01:00
maxcabrajac
516a3b0c9b Make WalkItemKind::walk signature compatible between Visitor versions 2024-11-15 17:01:53 -03:00
maxcabrajac
6180173612 Add WalkItemKind::Ctxt so AssocCtxt is not sent to non-Assoc ItemKinds 2024-11-15 17:00:01 -03:00
Matthias Krüger
b7dc4813a8
Rollup merge of #132653 - BoxyUwU:const_arg_stmt_mac_call, r=compiler-errors
Don't use `maybe_unwrap_block` when checking for macro calls in a block expr

Fixes #131915

Using `maybe_unwrap_block` to determine if we are looking at a `{ mac_call!{} }` will fail sometimes as `mac_call!{}` could be a `StmtKind::MacCall` not a `StmtKind::Expr`. This caused the def collector to think that `{ mac_call!{} }` was a non-trivial const argument and create a definition for it even though it should not.

r? `@compiler-errors`  cc `@camelid`
2024-11-12 06:27:17 +01:00
Michael Goulet
0e481b44f5 use verbose for path separator suggestion 2024-11-08 16:58:19 +00:00
Matthias Krüger
bb50ebfca4
Rollup merge of #132567 - estebank:bad-suggestion, r=Nadrieril
Properly suggest `E::assoc` when we encounter `E::Variant::assoc`

Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code.

Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
2024-11-05 20:10:51 +01:00
Boxy
1d6e847674 Check for both StmtKind::MacCall and ExprKind::MacCall 2024-11-05 18:23:21 +00:00
Esteban Küber
e26ad8b67d Properly suggest E::assoc when we encounter E::Variant::assoc
Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code.

Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
2024-11-03 18:55:19 +00:00
uellenberg
67a85925b1 Suggest fixing typos and let bindings at the same time
Fixes #132483
2024-11-02 14:40:37 -07:00
Camille GILLOT
27c958fb44 Review comments. 2024-10-30 16:20:49 +00:00
Camille GILLOT
b6e1214ac0 Remap impl-trait lifetimes on HIR instead of AST lowering. 2024-10-30 16:18:50 +00:00
Jubilee
5d0f52efa4
Rollup merge of #131375 - klensy:clone_on_ref_ptr, r=cjgillot
compiler: apply clippy::clone_on_ref_ptr for CI

Apply lint https://rust-lang.github.io/rust-clippy/master/index.html#/clone_on_ref_ptr for compiler, also see https://github.com/rust-lang/rust/pull/131225#discussion_r1790109443.

Some Arc's can be misplaced with Lrc's, sorry.

https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/enable.20more.20clippy.20lints.20for.20compiler.20.28and.5Cor.20std.29
2024-10-29 03:11:39 -07:00
klensy
746b675c5a fix clippy::clone_on_ref_ptr for compiler 2024-10-28 18:05:08 +03:00
Vadim Petrochenkov
b93a2dd0ef expand: Stop using artificial ast::Item for macros loaded from metadata 2024-10-26 22:08:55 +03:00
maxcabrajac
64a3451835 Pass Ident by reference in ast Visitor 2024-10-24 11:10:49 -03:00
Ralf Jung
ad3991d303 nightly feature tracking: get rid of the per-feature bool fields 2024-10-23 09:14:41 +01:00
Ralf Jung
46ce5cbf33 terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it) 2024-10-22 07:37:54 +01:00
Noratrieb
0c8d81b4df Stop relying on hashmap iteration for unused macro rules arms 2024-10-20 00:12:52 -07:00
Falco Hirschenberger
8f2273e518 Fix #131471, range misleading field access
Fixes #131471 by checking if the range-start is a literal.
2024-10-18 17:27:28 +02:00
Jubilee Young
47cfaa6d87 compiler: use is_none_or where it is clearly better
heuristic was: if it easily allows removing bangs entirely? worth it.
if it requires more effort or just moves the bang? not.
2024-10-16 23:50:13 -07:00
bors
f79fae3069 Auto merge of #131723 - matthiaskrgr:rollup-krcslig, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #122670 (Fix bug where `option_env!` would return `None` when env var is present but not valid Unicode)
 - #131095 (Use environment variables instead of command line arguments for merged doctests)
 - #131339 (Expand set_ptr_value / with_metadata_of docs)
 - #131652 (Move polarity into `PolyTraitRef` rather than storing it on the side)
 - #131675 (Update lint message for ABI not supported)
 - #131681 (Fix up-to-date checking for run-make tests)
 - #131702 (Suppress import errors for traits that couldve applied for method lookup error)
 - #131703 (Resolved python deprecation warning in publish_toolstate.py)
 - #131710 (Remove `'apostrophes'` from `rustc_parse_format`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-10-15 11:50:31 +00:00
Matthias Krüger
fb691b470a
Rollup merge of #130635 - eholk:pin-reborrow-sugar, r=compiler-errors
Add `&pin (mut|const) T` type position sugar

This adds parser support for `&pin mut T` and `&pin const T` references. These are desugared to `Pin<&mut T>` and `Pin<&T>` in the AST lowering phases.

This PR currently includes #130526 since that one is in the commit queue. Only the most recent commits (bd450027eb4a94b814a7dd9c0fa29102e6361149 and following) are new.

Tracking:

- #130494

r? `@compiler-errors`
2024-10-15 05:12:34 +02:00
Michael Goulet
95dba280b9 Move trait bound modifiers into ast::PolyTraitRef 2024-10-14 09:20:38 -04:00
bors
f4966590d8 Auto merge of #131045 - compiler-errors:remove-unnamed_fields, r=wesleywiser
Retire the `unnamed_fields` feature for now

`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.

However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.

Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041

Tracking:
* https://github.com/rust-lang/rust/issues/49804

[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
2024-10-11 13:11:13 +00:00
Eric Holk
ae698f8199
Add sugar for &pin (const|mut) types 2024-10-07 11:15:04 -07:00
bors
0b16baa570 Auto merge of #131235 - codemountains:rename-nestedmetaitem-to-metaitemlnner, r=nnethercote
Rename `NestedMetaItem` to `MetaItemInner`

Fixes #131087

r? `@nnethercote`
2024-10-07 08:59:55 +00:00
codemountains
fc64ff7ec2 Rename nested_meta to meta_item_inner 2024-10-07 15:22:03 +09:00
codemountains
6dfc4a0473 Rename NestedMetaItem to MetaItemInner 2024-10-06 23:28:30 +09:00
bors
373971abe4 Auto merge of #131259 - ismailarilik:handle-potential-query-instability-lint-for-librustdoc, r=notriddle
Handle `librustdoc` cases of `rustc::potential_query_instability` lint

This PR removes `#![allow(rustc::potential_query_instability)]` line from [`src/librustdoc/lib.rs`](https://github.com/rust-lang/rust/blob/master/src/librustdoc/lib.rs#L23) and converts `FxHash{Map,Set}` types into `FxIndex{Map,Set}` to suppress lint errors.

A somewhat tracking issue: https://github.com/rust-lang/rust/issues/84447

r? `@compiler-errors`
2024-10-06 14:04:21 +00:00
ismailarilik
e0a20b484d Handle librustdoc cases of rustc::potential_query_instability lint 2024-10-06 10:39:03 +03: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
Michael Howell
253fec494f rustdoc: prevent ctors from resolving 2024-10-03 22:01:23 -07:00
ismailarilik
3d8bd6bbc5 Handle rustc_metadata cases of rustc::potential_query_instability lint 2024-10-03 08:38:51 +03:00
ismailarilik
807e812077 Handle rustc-hir-analysis cases of rustc::potential_query_instability lint 2024-10-02 08:28:45 +03:00
Michael Goulet
40465d2449 Remove anon struct and union types 2024-10-01 13:55:46 -04:00
Matthias Krüger
71cd918dc7 cleanup: don't clone types that are Copy 2024-09-29 13:31:30 +02:00
Michael Goulet
cfb8419900 Separate collection of crate-local inherent impls from error reporting 2024-09-24 10:12:05 -04:00
Michael Goulet
c682aa162b Reformat using the new identifier sorting from rustfmt 2024-09-22 19:11:29 -04:00
bors
55043f067d Auto merge of #130337 - BoxyUwU:anon_const_macro_call, r=camelid
Fix anon const def-creation when macros are involved take 2

Fixes #130321

There were two cases that #129137 did not handle correctly:

- Given a const argument `Foo<{ bar!() }>` in which `bar!()` expands to `N`, we would visit the anon const and then visit the `{ bar() }` expression instead of visiting the macro call. This meant that we would build a def for the anon const as `{ bar!() }` is not a trivial const argument as `bar!()` is not a path.
- Given a const argument `Foo<{ bar!() }>` is which `bar!()` expands to `{ qux!() }` in which `qux!()` expands to `N`, it should not be considered a trivial const argument as `{{ N }}` has two pairs of braces.  If we only looked at `qux`'s expansion it would *look* like a trivial const argument even though it is not. We have to track whether we have "unwrapped" a brace already when recursing into the expansions of `bar`/`qux`/any macro

r? `@camelid`
2024-09-22 00:31:03 +00:00
Boxy
781ec111b7 Handle macro calls in anon const def creation take 2 2024-09-21 22:17:18 +01:00
Michael Goulet
7c8e281f73 Flesh out some TODOs 2024-09-20 22:18:57 -04:00
Michael Goulet
51b51bb570 Implement RTN in resolve_bound_vars and HIR ty lowering 2024-09-20 22:18:57 -04:00
Michael Goulet
6d788a18c5 Resolve RTN for TyKind::Path ending in (..) 2024-09-20 22:18:57 -04:00
Matthias Krüger
09b255d3d4
Rollup merge of #130116 - veera-sivarajan:freeze-suggestions, r=chenyukang
Implement a Method to Seal `DiagInner`'s Suggestions

This PR adds a method on `DiagInner` called `.seal_suggestions()` to prevent new suggestions from being added while preserving existing suggestions.

This is useful because currently there is no way to prevent new suggestions from being added to a diagnostic. `.disable_suggestions()` is the closest but it gets rid of all suggestions before and after the call.

Therefore, `.seal_suggestions()` can be used when, for example, misspelled keyword is detected and reported. In such cases, we may want to prevent other suggestions from being added to the diagnostic, as they would likely be meaningless once the misspelled keyword is identified. For context: https://github.com/rust-lang/rust/pull/129899#discussion_r1741307132

To store an additional state, the type of the `suggestions` field in `DiagInner` was changed into a three variant enum. While this change affects files across different crates, care was taken to preserve the existing code's semantics. This is validated by the fact that all UI tests pass without any modifications.

r? chenyukang
2024-09-18 04:42:31 +02:00
Matthias Krüger
7be15b850f
Rollup merge of #130033 - compiler-errors:foreign-fn-types, r=BoxyUwU
Don't call `fn_arg_names` query for non-`fn` foreign items in resolver

Fixes #130015
2024-09-16 21:53:06 +02:00
Michael Goulet
ae8b4607c6 Introduce distinct error codes for precise capturing 2024-09-16 10:56:22 -04:00
Michael Goulet
26bdfefae1 Do precise capturing arg validation in resolve 2024-09-16 10:56:22 -04:00
Veera
741005792e Implement a Method to Seal DiagInner's Suggestions 2024-09-12 21:27:44 -04:00
bors
d3a8524e80 Auto merge of #129137 - camelid:lazy-def-macro-const, r=BoxyUwU
Fix anon const def-creation when macros are involved

Fixes #128016.

Ever since #125915, some `ast::AnonConst`s turn into `hir::ConstArgKind::Path`s,
which don't have associated `DefId`s. To deal with the fact that we don't have
resolution information in `DefCollector`, we decided to implement a process
where if the anon const *appeared* to be trivial (i.e., `N` or `{ N }`), we
would avoid creating a def for it in `DefCollector`. If later, in AST lowering,
we realized it turned out to be a unit struct literal, or we were lowering it
to something that didn't use `hir::ConstArg`, we'd create its def there.

However, let's say we have a macro `m!()` that expands to a reference to a free
constant `FOO`. If we use `m!()` in the body of an anon const (e.g., `Foo<{ m!() }>`),
then in def collection, it appears to be a nontrivial anon const and we create
a def. But the macro expands to something that looks like a trivial const arg,
but is not, so in AST lowering we "fix" the mistake we assumed def collection
made and create a def for it. This causes a duplicate definition ICE.

The long-term fix for this is to delay the creation of defs for all expression-like
nodes until AST lowering (see #128844 for an incomplete attempt at this). This
would avoid issues like this one that are caused by hacky workarounds. However,
doing this uncovers a pre-existing bug with opaque types that is quite involved
to fix (see #129023).

In the meantime, this PR fixes the bug by delaying def creation for anon consts
whose bodies are macro invocations until after we expand the macro and know
what is inside it. This is accomplished by adding information to create the
anon const's def to the data in `Resolver.invocation_parents`.

r? `@BoxyUwU`
2024-09-13 01:10:51 +00:00
Noah Lev
e0bd01167e Re-enable ConstArgKind::Path lowering by default
...and remove the `const_arg_path` feature gate as a result. It was only
a stopgap measure to fix the regression that the new lowering introduced
(which should now be fixed by this PR).
2024-09-12 13:56:01 -04:00