| Age | Commit message (Collapse) | Author | Lines |
|---|
|
rustc_scalar_valid_range_{start,end}.
|
|
|
|
|
|
Visit `ImplItem` in `dead_code` lint
Fixes https://github.com/rust-lang/rust/issues/47131.
|
|
Do not emit incorrect borrow suggestion involving macros and fix overlapping multiline spans
Fix #58298.
|
|
Better diagnostic for binary operation on BoxedValues
Fixes #59458
|
|
Fix error in Rust 2018 + no_core environment
Minimized reproduction: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=5b9f6c3026ec9d856699fa6dbd4361f0
This is a fix for the error that occurred in #58702.
r? @Centril
|
|
|
|
warn -> deny duplicate match bindings
This is the next step of https://github.com/rust-lang/rust/issues/57742
r? @Centril
- [x] Decide whether to go to deny-by-default or hard error.
- My preference is to make this deny-by-default, rather than going straight to a hard error. The CI should fail because I haven't updated the ui test yet. I'll update it when we decide which to do.
- [x] Update [test](https://github.com/mark-i-m/rust/blob/c25d6b83441e0c060ee0273193ef27b29e1318cd/src/test/ui/macros/macro-multiple-matcher-bindings.rs)
- [ ] ~Crater run~ see https://github.com/rust-lang/rust/pull/59394#issuecomment-477817351
|
|
|
|
This commit removes the check that disallows the `#[non_exhaustive]`
attribute from being placed on enum variants and removes the associated
tests.
Further, this commit lowers the visibility of enum variant constructors
when the variant is marked as non-exhaustive.
|
|
|
|
point at operator
|
|
When moving out of a for loop head, suggest borrowing it in nll mode
Follow up to #59195 for NLL.
|
|
compiletest: make path normalization smarter
Fixes #59109.
|
|
ffi: rename VaList::copy to VaList::with_copy
Rename `VaList::copy` to `VaList::with_copy`
r? @joshtriplett
|
|
Review feedback asked for the test to be generalized to include macros
2.0; that generalization is dyn-2015-idents-in-decl-macros-unlinted.rs
As a drive-by, I also decided to revise the test to make it clear
*why* we cannot generally lint these cases. (I already had similar
demonstrations in dyn-2015-edition-keyword-ident-lint.rs, but it does
not hurt to try to emphasize matters.)
I also added some commentary on the cases where we could choose to
make the lint smarter, namely the situations where a macro is
*definitely* using `dyn` as an identifier (because it is using it as a
path component).
|
|
keyword in test.
Back-story: After reflection this morning, I realized that the
previous form of this test would allow the macro invocation to treat
the `dyn` input as a raw-identifier rather than a keyword, and since
the input was discarded by that version of the macro, the test would
pass despite the detail that the input `dyn` should not have been
parsed as a raw-identifier.
This revision fixes that oversight, by actually *using* the macro
input to construct a `Box<dyn Trait>` type.
|
|
|
|
Do not complain about unmentioned fields in recovered patterns
When the parser has to recover from malformed code in a pattern, do not
complain about missing fields.
Fix #59145.
|
|
fs::copy() unix: set file mode early
A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.
In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.
In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
`/dev/stdout` or for root setting permissions on `/dev/null`.
copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or
a device like "/dev/null", so fallback to io::copy, too.
Fixes: https://github.com/rust-lang/rust/issues/26933
Fixed: https://github.com/rust-lang/rust/issues/37885
|
|
|
|
|
|
When two multiline span labels point at the same span, we special
case the output to avoid weird behavior:
```
foo(
_____^
|_____|
|| bar,
|| );
|| ^
||______|
|______foo
baz
```
instead showing
```
foo(
_____^
| bar,
| );
| ^
| |
|______foo
baz
```
|
|
|
|
|
|
|
|
Add some tests
close #52977
It seems that there are no tests for this issue, so I opened this PR.
off-topic: I noticed [this test](https://github.com/rust-lang/rust/blob/master/src/test/ui/existential_types/nested_existential_types.rs)'s indents are bad, could I include commit to fix this, or should I separate?
r? @oli-obk
|
|
Generalize diagnostic for `x = y` where `bool` is the expected type
Extracted out of https://github.com/rust-lang/rust/pull/59288.
Currently we special case a diagnostic for `if x = y { ...` since the expected type is `bool` in this case and we instead suggest `if x == y`. This PR generalizes this such that given an expression of form `x = y` (`ExprKind::Assign(..)`) where the expected type is `bool`, we emit a suggestion `x == y`.
r? @oli-obk
Let's do a perf run to make sure this was not the source of regressions in #59288.
|
|
Reject integer suffix when tuple indexing
Fix #59418.
r? @varkor
|
|
adjust MaybeUninit API to discussions
uninitialized -> uninit
into_initialized -> assume_init
read_initialized -> read
set -> write
|
|
Add suggestion to use `&*var` when `&str: From<String>` is expected
Fix #53879.
|
|
syntax: Remove warning for unnecessary path disambiguators
`rustfmt` is now stable and it removes unnecessary turbofishes, so removing the warning as discussed in https://github.com/rust-lang/rust/pull/43540 (where it was introduced).
One hardcoded warning less.
Closes https://github.com/rust-lang/rust/issues/58055
r? @nikomatsakis
|
|
Make some lints incremental
Blocked on https://github.com/rust-lang/rust/pull/57253
r? @michaelwoerister
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduce proc_macro::Span::source_text
A function to extract the actual source behind a Span.
Background: I would like to use `syn` in a `build.rs` script to parse the rust code, and extract part of the source code. However, `syn` only gives access to proc_macro2::Span, and i would like to get the source code behind that.
I opened an issue on proc_macro2 bug tracker for this feature https://github.com/alexcrichton/proc-macro2/issues/110 and @alexcrichton said the feature should first go upstream in proc_macro. So there it is!
Since most of the Span API is unstable anyway, this is guarded by the same `proc_macro_span` feature as everything else.
|
|
and bump llvm version in test
|
|
|
|
|
|
|
|
|
|
replace redundant note in deprecation warning
|
|
Add no_hash to query macro and move some queries over
r? @oli-obk
|
