| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Use it for feature-gating `#[bench]`
|
|
|
|
See #58794 for context.
|
|
expression
Maybe it made sense when it was introduced, but now it's doing something incorrect.
|
|
Solve the problem of `ParentScope` entries for eager expansions not exising in the resolver map by creating them on demand.
|
|
|
|
|
|
|
|
|
|
Improve invalid_value lint message
The lint now explains which type is involved and why it cannot be initialized this way. It also points at the innermost struct/enum field that has an offending type, if any.
See https://github.com/erlepereira/x11-rs/issues/99#issuecomment-520311911 for how this helps in some real-world code hitting this lint.
|
|
|
|
Add tests for issue #53598 and #57700
Closes #53598 and #57700
|
|
Regression test for #56870
Closes #56870.
|
|
jakubadamw:resolve-inconsistent-names-suggest-qualified-path, r=petrochenkov
Suggest using a qualified path in patterns with inconsistent bindings
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The help note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
it is the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
Fixes #50831.
|
|
|
|
|
|
|
|
Miri shouldn't look at types
r? @oli-obk
Fixes https://github.com/rust-lang/rust/issues/62137
|
|
Lint on some incorrect uses of mem::zeroed / mem::uninitialized
Cc https://github.com/rust-lang/rust/issues/62825 and https://internals.rust-lang.org/t/make-mem-uninitialized-and-mem-zeroed-panic-for-some-types-where-0-is-a-niche/10605
This does not yet handle `NonNull`/`NonZero*`, but it is a start.
I also improved some doc issues I hit on the way, and added a useful helper to `TyS`.
EDIT: I added the relnotes label mostly as a proposal -- I think this is worth mentioning, but leave the decision up to the release team.
|
|
|
|
|
|
Back out #62150
Ref: #62825
cc @RalfJung
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
A program like the following one:
```rust
enum E { A, B, C }
fn f(x: E) -> bool {
match x {
A | B => false,
C => true
}
}
```
is rejected by the compiler due to `E` variant paths not being in scope.
In this case `A`, `B` are resolved as pattern bindings and consequently
the pattern is considered invalid as the inner or-patterns do not bind
to the same set of identifiers.
This is expected but the compiler errors that follow could be surprising
or confusing to some users. This commit adds a help note explaining that
if the user desired to match against variants or consts, they should use
a qualified path. The note is restricted to cases where the identifier
starts with an upper-case sequence so as to reduce the false negatives.
Since this happens during resolution, there's no clean way to check what
the patterns match against. The syntactic criterium, however, is in line
with the convention that's assumed by the `non-camel-case-types` lint.
|
|
|
|
This reverts commit 1d45156866b54c3fc36edfdfcdd8149ad9cb5711, reversing
changes made to 0f92eb8a4a7d8715381f5b5d748d22315f6ff9c7.
|
|
|
|
Make the `is_import` flag in `ScopeSet` independent from namespace
Fix rebase
|
|
Cleanup some surrounding code.
Support resolution of intra doc links in unnamed block scopes.
(Paths from rustdoc now use early resolution and no longer need results of late resolution like all the built ribs.)
Fix one test hitting file path limits on Windows.
|
|
Move `Resolver` fields specific to late resolution to the new visitor.
The `current_module` field from `Resolver` is replaced with two `current_module`s in `LateResolutionVisitor` and `BuildReducedGraphVisitor`.
Outside of those visitors `current_module` is replaced by passing `parent_scope` to more functions and using the parent module from it.
Visibility resolution no longer have access to later resolution methods and has to use early resolution, so its diagnostics in case of errors regress slightly.
|
|
Mention that tuple structs are private if any of their fields are
CC #39703
|
|
check against more collisions for TypeId of fn pointer
Cc https://github.com/rust-lang/rfcs/pull/2738#issuecomment-519923318
|
|
More explicit diagnostic when using a `vec![]` in a pattern
```
error: unexpected `(` after qualified path
--> $DIR/vec-macro-in-pattern.rs:3:14
|
LL | Some(vec![x]) => (),
| ^^^^^^^
| |
| unexpected `(` after qualified path
| in this macro invocation
| use a slice pattern here instead
|
= help: for more information, see https://doc.rust-lang.org/edition-guide/rust-2018/slice-patterns.html
= note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
```
Fix #61933.
|
|
Add test for issue 36804
I slightly reduced the repro that ICEs on nightly-2017-01-20.
Closes #36804
|
|
Tweak mismatched types error
- Change expected/found for type mismatches in `break`
- Be more accurate when talking about diverging match arms
- Tweak wording of function without a return value
- Suggest calling bare functions when their return value can be coerced to the expected type
- Give more parsing errors when encountering `foo(_, _, _)`
Fix #51767, fix #62677, fix #63136, cc #37384, cc #35241, cc #51669.
|
|
|
|
|
|
|
|
|
|
```
error: unexpected `(` after qualified path
--> $DIR/vec-macro-in-pattern.rs:3:14
|
LL | Some(vec![x]) => (),
| ^^^^^^^
| |
| unexpected `(` after qualified path
| in this macro invocation
| use a slice pattern here instead
|
= help: for more information, see https://doc.rust-lang.org/edition-guide/rust-2018/slice-patterns.html
= note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
