Downgrade unnested_or_patterns to pedantic
Even with #5704 fixed, I don't believe it is a safe bet that if someone is using or-patterns anywhere in a codebase then they want to use it as much as possible in the whole codebase. I think it would be reasonable to reevaluate after the feature is stable. I feel that a warn-by-default lint suggesting use of an unstable feature, even if already being used in one place, is questionable.
changelog: Remove unnested_or_patterns from default set of enabled lints
In the following example, an inaccessible path is suggested via
`use foo::bar::X;` whereas an accessible public exported path can
be suggested instead.
```
mod foo {
mod bar {
pub struct X;
}
pub use self::bar::X;
}
fn main() { X; }
```
This fixes the issue.
Fix a crash when searching for an alias contained in the currently selected filter crate.
Also remove alias search results for crates that should be filtered out.
The test suite needed to be fixed to actually take into account the crate filtering and check that there are no results when none are expected.
bootstrap: no `config.toml` exists regression
Fixes#73574.
This PR fixes a regression introduced in #73317 where an oversight meant that `config.toml` was assumed to exist.
Fix typos in doc comments
Hello 🦀 ,
This commit fixes typos in the doc comments of 'librustc_mir/monomorphize/collector.rs'
Thank you for reviewing this PR 👍
Add second message for LiveDrop errors
This is an attempt to fix https://github.com/rust-lang/rust/issues/72907 by adding a second message to the `LiveDrop` diagnostics. Changing from this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> src/lib.rs:7:9
|
7 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
error: aborting due to previous error
```
to this
```
error[E0493]: destructors cannot be evaluated at compile-time
--> foo.rs:6:9
|
6 | let mut always_returned = None;
| ^^^^^^^^^^^^^^^^^^^ constants cannot evaluate destructors
...
10 | always_returned = never_returned;
| --------------- value is dropped here
error: aborting due to previous error
```
r? @RalfJung @ecstatic-morse
Account for multiple impl/dyn Trait in return type when suggesting `'_`
Make `impl` and `dyn` Trait lifetime suggestions a bit more resilient.
Follow up to #72804.
r? @nikomatsakis
move leak-check to during coherence, candidate eval
Implementation of MCP https://github.com/rust-lang/compiler-team/issues/295.
I'd like to do a crater run on this.
Note to @rust-lang/lang: This PR is a breaking change (bugfix). It causes tests like the following to go from a future-compatibility warning #56105 to a hard error:
```rust
trait Trait {}
impl Trait for for<'a, 'b> fn(&'a u32, &'b u32) {}
impl Trait for for<'c> fn(&'c u32, &'c u32) {} // now rejected, used to warn
```
I am not aware of any instances of this code in the wild, but that is why we are doing a crater run. The reason for this change is that those two types are, in fact, the same type, and hence the two impls are overlapping.
There will still be impls that trigger #56105 after this lands, however -- I hope that we will eventually just accept those impls without warning, for the most part. One example of such an impl is this pattern, which is used by wasm-bindgen and other crates as well:
```rust
trait Trait {}
impl<T> Trait for fn(&T) { }
impl<T> Trait for fn(T) { } // still accepted, but warns
```
Improve compiler error message for wrong generic parameter order
- Added optional "help" parameter that shows a help message on the compiler error if required.
- Added a simple ordered parameter as a sample help.
@varkor will make more changes as required. Let me know if I'm heading in the right direction.
Fixes#68437
r? @varkor
Also added FIXME comments to note the possible need to accommodate
counter increment calls in source-based functions that differ from the
function context of the caller instance (e.g., inline functions).
The code should to check that the current expression _is_ the end
expression; not that it's equal to it. The equality check seems very
wasteful in terms of performance.
New lint: suggest `ptr::read` instead of `mem::replace(..., uninitialized())`
resolves: #5575
changelog: improvements to `MEM_REPLACE_WITH_UNINIT`:
- add a new test case in `tests/ui/repl_uninit.rs` to cover the case of replacing with `mem::MaybeUninit::uninit().assume_init()`.
- modify the existing `MEM_REPLACE_WITH_UNINIT` when replacing with `mem::uninitialized` to suggest using `ptr::read` instead.
- lint with `MEM_REPLACE_WITH_UNINIT` when replacing with `mem::MaybeUninit::uninit().assume_init()`
Rollup of 7 pull requests
Successful merges:
- #71756 (add Windows system error codes that should map to io::ErrorKind::TimedOut)
- #73495 (Converted all platform-specific stdin/stdout/stderr implementations to use io:: traits)
- #73575 (Fix typo in error_codes doc)
- #73578 (Make is_freeze and is_copy_modulo_regions take TyCtxtAt)
- #73586 (switch_ty is redundant)
- #73600 (Fix spurious 'value moved here in previous iteration of loop' messages)
- #73610 (Clean up E0699 explanation)
Failed merges:
r? @ghost
Currently, rustc uses a heuristic to determine if a range expression is
not a literal based on whether the expression looks like a function call
or struct initialization. This fails for range literals whose
lower/upper bounds are the results of function calls. A possibly-better
heuristic is to check if the expression contains `..`, required in range
literals.
Of course, this is also not perfect; for example, if the range
expression is a struct which includes some text with `..` this will
fail, but in general I believe it is a better heuristic.
A better alternative altogether is to add the `QPath::LangItem` enum
variant suggested in #60607. I would be happy to do this as a precursor
to this patch if someone is able to provide general suggestions on how
usages of `QPath` need to be changed later in the compiler with the
`LangItem` variant.
Closes#73553
Fix spurious 'value moved here in previous iteration of loop' messages
Fixes#46099
Previously, we would check the 'move' and 'use' spans to see if we
should emit this message. However, this can give false positives when
macros are involved, since two distinct expressions may end up with the
same span.
Instead, we check the actual MIR `Location`, which eliminates false
positives.
switch_ty is redundant
This field is redundant, but we cannot remove it currently as pretty-printing relies on it (and it does not have access to `mir::Body` to compute the type itself).
Cc @oli-obk @matthewjasper @jonas-schievink
Make is_freeze and is_copy_modulo_regions take TyCtxtAt
Make is_freeze and is_copy_modulo_regions take TyCtxtAt instead of separately taking TyCtxt and Span. This is consistent with is_sized.
Make is_freeze and is_copy_modulo_regions take TyCtxtAt
Make is_freeze and is_copy_modulo_regions take TyCtxtAt instead of separately taking TyCtxt and Span. This is consistent with is_sized.
Converted all platform-specific stdin/stdout/stderr implementations to use io:: traits
Currently, some of the platform-specific standard streams (`src/libstd/sys/*/stdio.rs`) manually implement parts of the `io::Write` interface directly as methods on the struct, rather than by actually implementing the trait. There doesn't seem to be any reason for this, other than an unused advantage of `fn write(&self, ...)` instead of `fn write(&mut self, ...)`.
Unfortunately, this means that those implementations don't have the default-implemented io methods, like `read_exact` and `write_all`. This caused #72705, which adds forwarding methods to the user-facing standard stream implementations, to fail to compile on those platforms.
This change converts *all* such standard stream structs to use the standard library traits. This change should not cause any breakages, because the changed types are not publicly exported, and in fact are only ever used in `src/libstd/io/stdio.rs`.
