| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Detect potential cases where `if let` was meant but `let` was left out.
Fix #44990.
|
|
Based off of
https://github.com/kfitch/rust/commit/972560b83f80e1219b5735ff3d751c034115b08e
|
|
Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
additional context for the recursive call.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
|
|
|
|
Don't emit "is not a logical operator" error outside of associative expressions
Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.
Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.
Fixes #75599
---
First time contributor! Let me know if there are any conventions or policies I should be following that I missed here. Thanks :)
|
|
Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.
Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.
Fixes #75599
|
|
|
|
Add regression test for issue-66768
Fixes #66768
This is fixed by #70452 (in particular, https://github.com/rust-lang/rust/pull/70452/files#diff-53aef089a36a8e2ed07627fc8915fe63R1763) and I'm not sure it's worth to add this test (i.e. the tests in #70452 are enough), so r? @eddyb to confirm it.
|
|
Tweak output of E0225
When encountering multiple non-auto trait bounds suggest creating a new
trait and explain what auto-traits are.
_Inspired by https://fasterthanli.me/articles/frustrated-its-not-you-its-rust_
|
|
Tweak suggestion for `this` -> `self`
* When referring to `this` in associated `fn`s always suggest `self`.
* Point at ident for `fn` lacking `self`
* Suggest adding `self` to assoc `fn`s when appropriate
_Improvements based on the narrative in https://fasterthanli.me/articles/i-am-a-java-csharp-c-or-cplusplus-dev-time-to-do-some-rust_
|
|
When encountering multiple non-auto trait bounds suggest creating a new
trait and explain what auto-traits are.
|
|
|
|
Fix ICE #75307 in `format`
Remove usages of `unwrap` (even when some are safe today).
Fix #75307.
|
|
|
|
add regression test for #74739 (mir const-prop bug)
Fixes https://github.com/rust-lang/rust/issues/74739
|
|
|
|
|
|
Tweak conditions for E0026 and E0769
When we have a tuple struct used with struct we don't want to suggest using the (valid) struct syntax with numeric field names. Instead we want to suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant" instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".
|
|
Clean up errors in typeck and resolve
* Tweak ordering of suggestions
* Do not suggest similarly named enclosing item
* Point at item definition in foreign crates
* Add missing primary label
CC #34255.
|
|
|
|
Modify logic to make it easier to follow and recover labels that would
otherwise be lost.
|
|
Remove restriction on type parameters preceding consts w/ feature const-generics
Removed the restriction on type parameters preceding const parameters when the feature const-generics is enabled.
Builds on #74676, which deals with unsorted generic parameters. This just lifts the check in lowering the AST to HIR that permits consts and types to be reordered with respect to each other. Lifetimes still must precede both
This change is not intended for min-const-generics, and is gated behind the `#![feature(const_generics)]`.
One thing is that it also permits type parameters without a default to come after consts, which I expected to not work, and was hoping to get more guidance on whether that should be permitted or how to prevent it otherwise.
I did not go through the RFC process for this pull request because there was prior work to get this feature added. In the previous PR that was cited, work was done to enable this change.
r? @lcnr
|
|
When we have a tuple struct used with struct we don't want to suggest using
the (valid) struct syntax with numeric field names. Instead we want to
suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant"
instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".
|
|
Do not ICE when lowering invalid extern fn with bodies
Fix #75283.
|
|
Fix #75283.
|
|
Added minor fmt change to ast_validation
|
|
Fix #75311.
|
|
Remove usages of `unwrap` (even when some are safe today).
|
|
|
|
Fix change detection in CfgSimplifier::collapse_goto_chain
Check that the old target is different from the new collapsed one, before concluding that anything changed.
Fixes #75074
Fixes #75051
|
|
Stabilize `Result::as_deref` and `as_deref_mut`
FCP completed in https://github.com/rust-lang/rust/issues/50264#issuecomment-645681400.
This PR stabilizes two new APIs for `std::result::Result`:
```rust
fn as_deref(&self) -> Result<&T::Target, &E> where T: Deref;
fn as_deref_mut(&mut self) -> Result<&mut T::Target, &mut E> where T: DerefMut;
```
This PR also removes two rarely used unstable APIs from `Result`:
```rust
fn as_deref_err(&self) -> Result<&T, &E::Target> where E: Deref;
fn as_deref_mut_err(&mut self) -> Result<&mut T, &mut E::Target> where E: DerefMut;
```
Closes #50264
|
|
Check that the old target is different from the new collapsed one,
before concluding that anything changed.
|
|
compiletest: Support ignoring tests requiring missing LLVM components
This PR implements a more principled solution to the problem described in https://github.com/rust-lang/rust/pull/66084.
Builds of LLVM backends take a lot of time and disk space.
So it usually makes sense to build rustc with
```toml
[llvm]
targets = "X86"
experimental-targets = ""
```
unless you are working on some target-specific tasks.
A few tests, however, require non-x86 backends to be built.
A new test directive `// needs-llvm-components: component1 component2 component3` makes such tests to be automatically ignored if one of the listed components is missing in the provided LLVM (this is determined through `llvm-config --components`).
As a result, the test suite now fully passes with LLVM built only with the x86 backend. The component list in this case is
```
aggressiveinstcombine all all-targets analysis asmparser asmprinter binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel instcombine instrumentation interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mirparser native nativecodegen objcarcopts object objectyaml option orcerror orcjit passes profiledata remarks runtimedyld scalaropts selectiondag support symbolize tablegen target textapi transformutils vectorize windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xray
```
(With the default target list it's much larger.)
```
aarch64 aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all all-targets analysis arm armasmparser armcodegen armdesc armdisassembler arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter cfguard codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf debuginfopdb demangle dlltooldriver dwarflinker engine executionengine frontendopenmp fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation interpreter ipo irreader jitlink libdriver lineeditor linker lto mc mca mcdisassembler mcjit mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo objcarcopts object objectyaml option orcerror orcjit passes powerpc powerpcasmparser powerpccodegen powerpcdesc powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser riscvcodegen riscvdesc riscvdisassembler riscvinfo riscvutils runtimedyld scalaropts selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc systemzdisassembler systemzinfo tablegen target textapi transformutils vectorize webassembly webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler webassemblyinfo windowsmanifest x86 x86asmparser x86codegen x86desc x86disassembler x86info x86utils xray
```
https://github.com/rust-lang/rust/pull/66084 is also reverted now.
r? @Mark-Simulacrum
|
|
Fix ICEs with `@ ..` binding
This reverts #74557 and introduces an alternative fix while ensuring that #74954 is not broken.
The diagnostics are verbose though, it fixes three related issues.
cc #74954, #74539, and #74702
|
|
|
|
report kind of deprecated item in message
This is important for fields, which are incorrectly referred to as
"items".
|
|
davidtwco:issue-74636-polymorphized-closures-inherited-params, r=oli-obk
mir: add `used_generic_parameters_needs_subst`
Fixes #74636.
This PR adds a `used_generic_parameters_needs_subst` helper function which checks whether a type needs substitution, but only for parameters that the `unused_generic_params` query considers used. This is used in the MIR interpreter to make the check for some pointer casts and for reflection intrinsics more precise.
I've opened this as a draft PR because this might not be the approach we want to fix this issue and we have to decide what to do about the reflection case.
r? @eddyb
cc @lcnr @wesleywiser
|
|
This commit adds a `ensure_monomorphic_enough` utility function which
checks whether a type needs substitution, but only for parameters
that the `unused_generic_params` query considers used.
`ensure_monomorphic_enough` is then used throughout interpret where
`needs_subst` checks previously existed (in particular, for some
pointer casts and for reflection intrinsics more precise).
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
|
|
|
|
This reverts commit f5e5eb6f46ef2cf0dd45dba4f975305509334fc6.
|
|
Warn about unused expressions with closure or generator type. This follows
existing precedence of must use annotations present on `FnOnce`, `FnMut`, `Fn`
traits, which already indirectly apply to closures in some cases, e.g.,:
```rust
fn f() -> impl FnOnce() {
|| {}
}
fn main() {
// an existing warning: unused implementer of `std::ops::FnOnce` that must be used:
f();
// a new warning: unused closure that must be used:
|| {};
}
```
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #74088 (Avoid writes without any data in `Write::write_all_vectored`)
- #74598 (Fix sync_once_cell_does_not_leak_partially_constructed_boxes)
- #74750 (Clean up some uses of logging in ui tests)
- #74783 (python codes cleanup)
- #74790 (Don't italicize comments in ayu theme)
- #74799 (Fixed typo in `closure`)
Failed merges:
r? @ghost
|
|
Clean up some uses of logging in ui tests
The removed test can't possibly trigger anything today as we don't have logging in libstd.
The `exec-env` flag was mistakenly used for adding env vars to rustc invocations both in test and in the test suite and there were some accidental renames from RUST_LOG to RUSTC_LOG that I reverted.
|
|
Pull out some duplicated code into a new function
I debated pulling the actual struct_span_err calls into the new method, but I felt like having to pass in multiple arguments for it and wiring up string formatting outweighed the benefits.
Viewing the diff with whitespace ignored is recommended.
|
|
Ensure stack when type checking and building MIR for large if expressions
Fixes #74564
|
