| Age | Commit message (Collapse) | Author | Lines |
|
|
|
compiletest: Support matching diagnostics on lines below
Using `//~vvv ERROR`.
This is not needed often, but it's easy to support, and it allows to eliminate a class of `error-pattern`s that cannot be eliminated in any other way.
See the diff for the examples of such patterns coming from parser.
Some of them can be matched by `//~ ERROR` or `//~^ ERROR` as well (when the final newline is allowed), but it changes the shape of reported spans, so I chose to keep the spans by using `//~v ERROR`.
|
|
- Fix #18782
|
|
Reject `{true,false}` as revision names
Because they would imply `--cfg={true,false}` otherwise, and the test writer has to use `cfg(r#true)` and `cfg(r#false)` in the test.
Closes #138663.
|
|
|
|
|
|
Miri subtree update
r? `@ghost`
|
|
machine clock: make 'monotonic' explicit
|
|
|
|
|
|
|
|
|
|
feat: Allow crate authors to control completion of their things
|
|
Where a fundamental type applied twice wasn't considered local.
|
|
This renames `--runtool` and `--runtool-arg` to `--test-runtool` and
`--test-runtool-arg` to maintain consistency with other `--test-*`
arguments.
|
|
"Missing" patterns are possible in bare fn types (`fn f(u32)`) and
similar places. Currently these are represented in the AST with
`ast::PatKind::Ident` with no `by_ref`, no `mut`, an empty ident, and no
sub-pattern. This flows through to `{hir,thir}::PatKind::Binding` for
HIR and THIR.
This is a bit nasty. It's very non-obvious, and easy to forget to check
for the exceptional empty identifier case.
This commit adds a new variant, `PatKind::Missing`, to do it properly.
The process I followed:
- Add a `Missing` variant to `{ast,hir,thir}::PatKind`.
- Chang `parse_param_general` to produce `ast::PatKind::Missing`
instead of `ast::PatKind::Missing`.
- Look through `kw::Empty` occurrences to find functions where an
existing empty ident check needs replacing with a `PatKind::Missing`
check: `print_param`, `check_trait_item`, `is_named_param`.
- Add a `PatKind::Missing => unreachable!(),` arm to every exhaustive
match identified by the compiler.
- Find which arms are actually reachable by running the test suite,
changing them to something appropriate, usually by looking at what
would happen to a `PatKind::Ident`/`PatKind::Binding` with no ref, no
`mut`, an empty ident, and no subpattern.
Quite a few of the `unreachable!()` arms were never reached. This makes
sense because `PatKind::Missing` can't happen in every pattern, only
in places like bare fn tys and trait fn decls.
I also tried an alternative approach: modifying `ast::Param::pat` to
hold an `Option<P<Pat>>` instead of a `P<Pat>`, but that quickly turned
into a very large and painful change. Adding `PatKind::Missing` is much
easier.
|
|
|
|
Report compiletest pass mode if forced
This is very non-obvious if it fails in PR CI, because the starting invocation is miles away from the final test suite outcome.
|
|
expand: Leave traces when expanding `cfg` attributes
This is the same as https://github.com/rust-lang/rust/pull/138515, but for `cfg(true)` instead of `cfg_attr`.
The difference is that `cfg(true)`s already left "traces" after themselves - the `cfg` attributes themselves, with `expanded_inert_attrs` set to true, with full tokens, available to proc macros.
This is not a reasonably expected behavior, but it could not be removed without a replacement, because a [major rustdoc feature](https://github.com/rust-lang/rfcs/pull/3631) and a number of clippy lints rely on it. This PR implements a replacement.
This needs a crater run, because it changes observable behavior (in an intended way) - proc macros can no longer see expanded `cfg(true)` attributes.
(Some minor unnecessary special casing for `sym::cfg_attr` is also removed in this PR.)
r? `@nnethercote`
|
|
|
|
Via the new `#[rust_analyzer::completions(...)]` attribute.
Also fix a bug with existing settings for that where the paths wouldn't resolve correctly.
|
|
fix: Fix `format_args` lowering using wrong integer suffix
|
|
refactor: Shuffle some unsafety around in proc-macro-srv
|
|
|
|
|
|
chore: Remove salsa dependency from proc-macro server again
|
|
|
|
|
|
This is very non-obvious if it fails in PR CI.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #138483 (Target modifiers fix for bool flags without value)
- #138818 (Don't produce debug information for compiler-introduced-vars when desugaring assignments.)
- #138898 (Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax)
- #138930 (Add bootstrap step diff to CI job analysis)
- #138954 (Ensure `define_opaque` attrs are accounted for in HIR hash)
- #138959 (Revert "Make MatchPairTree::place non-optional")
- #138967 (Fix typo in error message)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=compiler-errors
Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax
**Disclaimer**: This PR is intended to mostly clean up code as opposed to bringing about behavioral changes. Therefore it doesn't aim to address any of the 'FIXME: remove after a month [dated: 2023-05-02]: "type ascription syntax has been removed, see issue [#]101728"'.
---
By commit:
1. Removes truly dead code:
* Since 1.71 (#109128) `let _ = { f: x };` is a syntax error as opposed to a semantic error which allows the parse-time diagnostic (suggestion) "*struct literal body without path // you might have forgotten […]*" to kick in.
* The analysis-time diagnostic (suggestion) from <=1.70 "*cannot find value \`f\` in this scope // you might have forgotten […]*" is therefore no longer reachable.
2. Updates `is_certainly_not_a_block` to be in line with the current grammar:
* The seq. `{ ident:` is definitely not the start of a block. Before the removal of ty ascr, `{ ident: ty_start` would begin a block expr.
* This shouldn't make more code compile IINM, it should *ultimately* only affect diagnostics.
* For example, `if T { f: () } {}` will now be interpreted as an `if` with struct lit `T { f: () }` as its *condition* (which is banned in the parser anyway) as opposed to just `T` (with the *consequent* being `f : ()` which is also invalid (since 1.71)). The diagnostics are almost the same because we have two separate parse recovery procedures + diagnostics: `StructLiteralNeedingParens` (*invalid struct lit*) before and `StructLiteralNotAllowedHere` (*struct lits aren't allowed here*) now, as you can see from the diff.
* (As an aside, even before this PR, fn `maybe_suggest_struct_literal` should've just used the much older & clearer `StructLiteralNotAllowedHere`)
* NB: This does sadly regress the compiler output for `tests/ui/parser/type-ascription-in-pattern.rs` but that can be fixed in follow-up PRs. It's not super important IMO and a natural consequence.
3. Removes code that's become dead due to the prior commit.
* Basically reverts #106620 + #112475 (without regressing rustc's output!).
* Now the older & more robust parse recovery procedure (cc `StructLiteralNotAllowedHere`) takes care of the cases the removed code used to handle.
* This automatically fixes the suggestions for \[[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=7e2030163b11ee96d17adc3325b01780)\]:
* `if Ty::<i32> { f: K }.m() {}`: `if Ty::<i32> { SomeStruct { f: K } }.m() {}` (broken) → ` if (Ty::<i32> { f: K }).m() {}`
* `if <T as Trait>::Out { f: K::<> }.m() {}`: `if <T as Trait>(::Out { f: K::<> }).m() {}` (broken) → `if (<T as Trait>::Out { f: K::<> }).m() {}`
4. Merge and simplify UI tests pertaining to this issue, so it's easier to add more regression tests like for the two cases mentioned above.
5. Merge UI tests and add the two regression tests.
Best reviewed commit by commit (on request I'll partially squash after approval).
|
|
bump thorin to 0.9 to drop duped deps
Bumps `thorin`, removing duped deps.
This also changes features for hashbrown:
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
to
```
hashbrown v0.15.2
`-- indexmap v2.7.0
|-- object v0.36.7
|-- wasmparser v0.219.1
|-- wasmparser v0.223.0
`-- wit-component v0.223.0
|-- indexmap feature "default"
|-- indexmap feature "serde"
`-- indexmap feature "std"
|-- hashbrown feature "allocator-api2"
| `-- hashbrown feature "default"
|-- hashbrown feature "default" (*)
|-- hashbrown feature "default-hasher"
| |-- object v0.36.7 (*)
| `-- wasmparser v0.223.0 (*)
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "equivalent"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "inline-more"
| `-- hashbrown feature "default" (*)
|-- hashbrown feature "nightly"
| |-- rustc_data_structures v0.0.0
| `-- rustc_query_system v0.0.0
|-- hashbrown feature "raw-entry"
| `-- hashbrown feature "default" (*)
`-- hashbrown feature "serde"
`-- wasmparser feature "serde"
```
To be safe, as this can be perf-sensitive:
`@bors` rollup=never
|
|
refactor: Use MEDIUM durability for crate-graph changes, high for library source files
|
|
source files
The idea here is that the crate graph may change over time, but library source file contents *never* will (or really never should). Disconnecting the two means that queries that depend on library sources will not need to re-validatewhen the crate graph changes (unless they depend on the crate graph in some capacity).
|
|
This combines the memory layout and drop information on one line,
and makes the wording more succinct.
Closes #19410
|
|
Allow defining opaques in statics and consts
r? oli-obk
Fixes https://github.com/rust-lang/rust/issues/138902
|
|
Rollup of 8 pull requests
Successful merges:
- #135745 (Recognise new IPv6 non-global range from IETF RFC 9602)
- #137247 (cg_llvm: Reduce the visibility of types, modules and using declarations in `rustc_codegen_llvm`.)
- #138317 (privacy: Visit types and traits in impls in type privacy lints)
- #138581 (Abort in deadlock handler if we fail to get a query map)
- #138776 (coverage: Separate span-extraction from unexpansion)
- #138886 (Fix autofix for `self` and `self as …` in `unused_imports` lint)
- #138924 (Reduce `kw::Empty` usage, part 3)
- #138929 (Visitors track whether an assoc item is in a trait impl or an inherent impl)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Visitors track whether an assoc item is in a trait impl or an inherent impl
`AssocCtxt::Impl` now contains an `of_trait` field. This allows ast lowering and nameres to not have to track whether we're in a trait impl or an inherent impl.
|
|
|
|
compiletest: Support matching on diagnostics without a span
Using `//~? ERROR my message` on any line of the test.
The new checks are exhaustive, like all other `//~` checks, and unlike the `error-pattern` directive that is sometimes used now to check for span-less diagnostics.
This will allow to eliminate most on `error-pattern` directives in compile-fail tests (except those that are intentionally imprecise due to platform-specific diagnostics).
I didn't migrate any of `error-pattern`s in this PR though, except those where the migration was necessary for the tests to pass.
|
|
|
|
Note that issue-111692.rs was incorrectly named: It's a regression test for
issue [#]112278, not for [#]111692. That's been addressed, too.
|
|
fix(ide-assists): `let else` to `if let else`
|
|
|
|
|
|
feat: parse `unsafe` record fields
|
|
|
|
Shourya742/2025-03-13-add-diagnostic-for-dnagling-impl-with-lifetime
Add diagnostic for missing ambiguity error for impl trait
|
|
|