| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Detect more `=>` typos
Handle and recover `match expr { pat >= { arm } }`.
|
|
|
|
|
|
When encountering code that seems like it might be trying to have
multiple tail expressions depending on `cfg` information, suggest
alternatives that will success to parse.
```rust
fn foo() -> String {
#[cfg(feature = "validation")]
[1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
#[cfg(not(feature = "validation"))]
String::new()
}
```
```
error: expected `;`, found `#`
--> $DIR/multiple-tail-expr-behind-cfg.rs:5:64
|
LL | #[cfg(feature = "validation")]
| ------------------------------ only `;` terminated statements or tail expressions are allowed after this attribute
LL | [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
| ^ expected `;` here
LL | #[cfg(not(feature = "validation"))]
| - unexpected token
|
help: add `;` here
|
LL | [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>();
| +
help: alternatively, consider surrounding the expression with a block
|
LL | { [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>() }
| + +
help: it seems like you are trying to provide different expressions depending on `cfg`, consider using `if cfg!(..)`
|
LL ~ if cfg!(feature = "validation") {
LL ~ [1, 2, 3].iter().map(|c| c.to_string()).collect::<String>()
LL ~ } else if cfg!(not(feature = "validation")) {
LL ~ String::new()
LL + }
|
```
Fix #106020.
|
|
Add more APIs to retrieve information about types, and add more instance
resolution options.
Make `Instance::body()` return an Option<Body>, since not every instance
might have an available body. For example, foreign instances, virtual
instances, dependencies.
|
|
r=compiler-errors
Try to use approximate placeholder regions when outputting an AscribeUserType error in borrowck
Fixes #114866
Hi from GOSIM :)
|
|
|
|
|
|
When encountering a `Result<T, _>` or `Option<T>` where `T` has a field
that's being accessed, suggest calling `.unwrap()` to get to the field.
|
|
Take into account implicit dereferences when suggesting fields.
```
error[E0609]: no field `longname` on type `Arc<S>`
--> $DIR/suggest-field-through-deref.rs:10:15
|
LL | let _ = x.longname;
| ^^^^^^^^ help: a field with a similar name exists: `long_name`
```
CC https://github.com/rust-lang/rust/issues/78374#issuecomment-719564114
|
|
|
|
|
|
|
|
When encountering a type error caused by the use of `Self`, suggest
using the actual type name instead.
```
error[E0308]: mismatched types
--> $DIR/struct-path-self-type-mismatch.rs:13:9
|
LL | impl<T> Foo<T> {
| - ------ this is the type of the `Self` literal
| |
| found type parameter
LL | fn new<U>(u: U) -> Foo<U> {
| - ------ expected `Foo<U>` because of return type
| |
| expected type parameter
LL | / Self {
LL | |
LL | | inner: u
LL | |
LL | | }
| |_________^ expected `Foo<U>`, found `Foo<T>`
|
= note: expected struct `Foo<U>`
found struct `Foo<T>`
= note: a type parameter was expected, but a different one was found; you might be missing a type parameter or trait bound
= note: for more information, visit https://doc.rust-lang.org/book/ch10-02-traits.html#traits-as-parameters
help: use the type name directly
|
LL | Foo::<U> {
| ~~~~~~~~
```
Fix #76086.
|
|
When encountering a type error involving a `Self` literal, point at the
self type of the enclosing `impl`.
CC #76086.
|
|
Partially address #71039.
|
|
|
|
Tweak wording of module not found in resolve, when the name exists but
belongs to a non-`mod` item.
Fix #81232.
|
|
|
|
Fix depth check in ProofTreeVisitor.
The hack to cutoff overflows and cycles in the new trait solver was incorrect. We want to inspect everything with depth [0..10].
This fix exposed a previously unseen bug, which caused the compiler to ICE when invoking `trait_ref` on a non-assoc type projection. I simply added the guard in the `AmbiguityCausesVisitor`, and updated the expected output for the `auto-trait-coherence` test which now includes the extra note:
```text
|
= note: upstream crates may add a new impl of trait `std::marker::Send` for type `OpaqueType` in future versions
```
r? `@lcnr`
|
|
Add -Z llvm_module_flag
Allow adding values to the `!llvm.module.flags` metadata for a generated module. The syntax is
`-Z llvm_module_flag=<name>:<type>:<value>:<behavior>`
Currently only u32 values are supported but the type is required to be specified for forward compatibility. The `behavior` element must match one of the named LLVM metadata behaviors.viors.
This flag is expected to be perma-unstable.
|
|
finish `RegionKind` renaming
second step of https://github.com/rust-lang/types-team/issues/95
continues the work from #117876. While working on this and I encountered a bunch of further cleanup which I'll either open a tracking issue for or will do in a separate PR:
- rewrite the `RegionKind` docs, they still talk about `ReEmpty` and are generally out of date
- rename `DescriptionCtx` to `DescriptionCtxt`
- what is `CheckRegions::Bound`?
- `collect_late_bound_regions` et al
- `erase_late_bound_regions` -> `instantiate_bound_regions_with_erased`?
- `EraseEarlyRegions` visitor should be removed, feels duplicate
r? `@BoxyUwU`
|
|
Don't expect a rcvr in `print_disambiguation_help`
We don't necessarily have a receiver when we are both accidentally using the `.` operator *AND* we have more than one ambiguous method candidate.
Fixes #117728
|
|
|
|
Add richer structure for Stable MIR Projections
Resolves https://github.com/rust-lang/project-stable-mir/issues/49.
Projections in Stable MIR are currently just strings. This PR replaces that representation with a richer structure, namely projections become vectors of `ProjectionElem`s, just as in MIR. The `ProjectionElem` enum is heavily based off of the MIR `ProjectionElem`.
This PR is a draft since there are several outstanding issues to resolve, including:
- How should `UserTypeProjection`s be represented in Stable MIR? In MIR, the projections are just a vector of `ProjectionElem<(),()>`, meaning `ProjectionElem`s that don't have Local or Type arguments (for `Index`, `Field`, etc. objects). Should `UserTypeProjection`s be represented this way in Stable MIR as well? Or is there a more user-friendly representation that wouldn't drag along all the `ProjectionElem` variants that presumably can't appear?
- What is the expected behavior of a `Place`'s `ty` function? Should it resolve down the chain of projections so that something like `*_1.f` would return the type referenced by field `f`?
- Tests should be added for `UserTypeProjection`
|
|
Fix def-use check for call terminators
Fixes #117331.
|
|
Suggest dereferencing the LHS for binops such as `&T == T`
Fixes #52544
|
|
Build pre-coroutine-transform coroutine body on error
I was accidentally building the post-transform coroutine body, rather than the pre-transform coroutine body. There's no pinning expected here yet, and the return type isn't yet transformed into `CoroutineState`.
Fixes #117670
|
|
Apply structured suggestion that allows test to work since 1.64
Close #73497.
|
|
|
|
|
|
- `ReFree` -> `ReLateParam`
- `ReEarlyBound` -> `ReEarlyParam`
|
|
ambiguity of projections. Bless test with more specific notes on the ambiguity cause.
|
|
Custom MIR: Support cleanup blocks
Cleanup blocks are declared with `bb (cleanup) = { ... }`.
`Call` and `Drop` terminators take an additional argument describing the unwind action, which is one of the following:
* `UnwindContinue()`
* `UnwindUnreachable()`
* `UnwindTerminate(reason)`, where reason is `ReasonAbi` or `ReasonInCleanup`
* `UnwindCleanup(block)`
Also support unwind resume and unwind terminate terminators:
* `UnwindResume()`
* `UnwindTerminate(reason)`
|
|
Cleanup blocks are declared with `bb (cleanup) = { ... }`.
`Call` and `Drop` terminators take an additional argument describing the
unwind action, which is one of the following:
* `UnwindContinue()`
* `UnwindUnreachable()`
* `UnwindTerminate(reason)`, where reason is `ReasonAbi` or `ReasonInCleanup`
* `UnwindCleanup(block)`
Also support unwind resume and unwind terminate terminators:
* `UnwindResume()`
* `UnwindTerminate(reason)`
|
|
Always point at index span on index obligation failure
Use more targetted span for index obligation failures by rewriting the obligation cause span.
CC #66023
|
|
Handle and recover `match expr { pat >= { arm } }`.
|
|
|
|
|
|
tests: update check for inferred nneg on zext
This was broken by upstream
llvm/llvm-project@dc6d0773960c664eee12a1ed871fad5c81a20a12. It's easy enough to use a regex match to support both, so we do that.
r? `@nikic`
`@rustbot` label: +llvm-main
|
|
3tilley:prioritise-unwrap-expect-over-last-method-call, r=compiler-errors
Reorder checks to make sure potential missing expect on Option/Result…
… runs before removing last method call
Fixes #117669
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #117737 (Remove `-Zkeep-hygiene-data`.)
- #117830 (Small improvements in object lifetime default code)
- #117858 (Compute layout with spans for better cycle errors in coroutines)
- #117863 (Remove some unused stuff from `rustc_index`)
- #117872 (Cranelift isn't available on non-nightly channels)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Compute layout with spans for better cycle errors in coroutines
Split out from #117703, this PR at least gives us a nicer span to point at when we hit a cycle error in coroutine layout cycles.
|
|
This was broken by upstream
llvm/llvm-project@dc6d0773960c664eee12a1ed871fad5c81a20a12. It's easy
enough to use a regex match to support both, so we do that.
r? @nikic
@rustbot label: +llvm-main
|
|
`ReLateBound` -> `ReBound`
first step of https://github.com/rust-lang/types-team/issues/95
already fairly large xx
there's some future work here I intentionally did not contribute as part of this PR, from my notes:
- `DescriptionCtx` to `DescriptionCtxt`
- what is `CheckRegions::Bound`?
- `collect_late_bound_regions` et al
- `erase_late_bound_regions` -> `instantiate_bound_regions_with_erased`?
- `EraseEarlyRegions` should be removed, feels duplicate
r? `@BoxyUwU`
|
|
other changes:
- `Region::new_late_bound` -> `Region::new_bound`
- `Region::is_late_bound` -> `Region::is_bound`
|
|
Turn assert_eq into a delay_span_bug
Fixes #117789
|
|
coverage: Avoid creating malformed macro name spans
This is a workaround for #117788. It detects a particular scenario where we would create malformed coverage spans that might cause `llvm-cov` to immediately exit with an error, preventing the user from processing coverage reports.
The patch has been kept as simple as possible so that it's trivial to backport to beta (or stable) if desired.
---
The `maybe_push_macro_name_span` method is trying to detect macro invocations, so that it can split a span into two parts just after the `!` of the invocation.
Under some circumstances (probably involving nested macros), it gets confused and produces a span that is larger than the original span, and possibly extends outside its enclosing function and even into an adjacent file.
In extreme cases, that can result in malformed coverage mappings that cause `llvm-cov` to fail. For now, we at least want to detect these egregious cases and avoid them, so that coverage reports can still be produced.
|
|
|
