| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
This reverts commit d6ba1b9b021c408fcad60ee52acf8af5e1b2eb00, reversing
changes made to 8de5353f75dcde04abe947e0560dc5edd861cf3a.
|
|
If a struct pattern has a field error return an error.
|
|
`PointerKind` is included in `LoanPath` and hence forms part of the
equality check; this led to having two unequal paths that both
represent `*x`, depending on whether the `*` was inserted
automatically or explicitly. Bad mojo. The `note` field, in contrast,
is intended more-or-less primarily for this purpose of adding extra
data.
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #50595.
This bug currently affects stable. Why I think we can go for hard error:
- It will in stable for at most one cycle and there is no legitimate
reason to abuse it, nor any known uses in the wild.
- It only affects `bin` crates (which have a `main`), so there is
little practical difference between a hard error or a deny lint, both
are a one line fix.
The fix was to just unshadow a variable. Thanks @nikomatsakis for the
mentoring!
r? @nikomatsakis
|
|
If check_expr_struct_fields fails, do not continue to record update.
If we continue to record update, the struct may cause us to ICE later
on indexing a field that may or may not exist.
|
|
Also, a comment is edited to reflect that spaces around the equals-sign in
attributes is the standard (q.v. rust-lang-nursery/fmt-rfcs@bea80532e7).
|
|
|
|
|
|
This is the first small step towards testing auto-fixable compiler
suggestions using compiletest. Currently, it only checks if next to a
UI test there also happens to a `*.rs.fixed` file, and then uses rustfix
(added as external crate) on the original file, and asserts that it
produces the fixed version.
To show that this works, I've included one such test. I picked this test
case at random (and because it was simple) -- It is not relevant to the
2018 edition. Indeed, in the near future, we want to be able to restrict
rustfix to edition-lints, so this test cast might go away soon.
In case you still think this is somewhat feature-complete, here's a
quick list of things currently missing that I want to add before telling
people they can use this:
- [ ] Make this an actual compiletest mode, with `test [fix] …` output
and everything
- [ ] Assert that fixed files still compile
- [ ] Assert that fixed files produce no (or a known set of) diagnostics
output
- [ ] Update `update-references.sh` to support rustfix
- [ ] Use a published version of rustfix (i.e.: publish a new version
rustfix that exposes a useful API for this)
|
|
Rollup of 12 pull requests
Successful merges:
- #50302 (Add query search order check)
- #50320 (Fix invalid path generation in rustdoc search)
- #50349 (Rename "show type declaration" to "show declaration")
- #50360 (Clarify wordings of the `unstable_name_collision` lint.)
- #50365 (Use two vectors in nearest_common_ancestor.)
- #50393 (Allow unaligned reads in constants)
- #50401 (Revert "Implement FromStr for PathBuf")
- #50406 (Forbid constructing empty identifiers from concat_idents)
- #50407 (Always inline simple BytePos and CharPos methods.)
- #50416 (check if the token is a lifetime before parsing)
- #50417 (Update Cargo)
- #50421 (Fix ICE when using a..=b in a closure.)
Failed merges:
|
|
Forbid constructing empty identifiers from concat_idents
The empty identifier is a [reserved identifier](https://github.com/rust-lang/rust/blob/8a37c75a3a661385cc607d934c70e86a9eaf5fd7/src/libsyntax_pos/symbol.rs#L300-L305) in rust, apparently used for black magicks like representing the crate root or somesuch... and therefore, being able to construct it is Ungood. Presumably.
...even if the macro that lets you construct it is so useless that you can't actually do any damage with it. (and believe me, I tried)
Fixes #50403.
**Note:** I noticed that when you try to do something similar with `proc_macro::Term`, the compiler actually catches it and flags the identifier as reserved. Perhaps a better solution would be to somehow have that same check applied here.
|
|
Allow unaligned reads in constants
fixes #50356
introduced in https://github.com/rust-lang/rust/pull/49513
|
|
r=nikomatsakis
Clarify wordings of the `unstable_name_collision` lint.
Stabilizing an inherent method may cause change in behavior instead of inference error. Updated to use the wording from [varkor's comment].
Closes #50232.
[varkor's comment]: https://github.com/rust-lang/rust/issues/50232#issuecomment-384678097
|
|
Implement tool_attributes feature (RFC 2103)
cc #44690
This is currently just a rebased and compiling (hopefully) version of #47773.
Let's see if travis likes this. I will add the implementation for `tool_lints` this week.
|
|
|
|
|
|
Fix an unresolved import issue with enabled `use_extern_macros`
This is a kinda ugly special-purpose solution that will break if we suddenly add a fourth namespace, but I hope to come up with something more general if I get to import resolution refactoring this summer.
Fixes https://github.com/rust-lang/rust/issues/50187 thus removing a blocker for stabilization of `use_extern_macros`
|
|
Correct initial field alignment for repr(C)/repr(int)
Fixes #50098 following https://github.com/rust-lang/rust/issues/50098#issuecomment-385497333.
(I wasn't sure which kind of test was best suited here — I picked run-pass simply because that was convenient, but if codegen is more appropriate, let me know and I'll change it.)
r? @eddyb
|
|
|
|
Treat generators as if they have an arbitrary destructor
Conservatively assume dropping a generator touches its upvars, via locals' destructors.
Fix #49918
|
|
|
|
|
|
Remove unstable `macro_reexport`
It's subsumed by `feature(use_extern_macros)` and `pub use`
cc https://github.com/rust-lang/rust/issues/35896
closes https://github.com/rust-lang/rust/issues/29638
closes https://github.com/rust-lang/rust/issues/38951
|
|
|
|
|
|
Module experiments: Add one more prelude layer for extern crate names passed with `--extern`
Implements one item from https://internals.rust-lang.org/t/the-great-module-adventure-continues/6678/183
When some name is looked up in lexical scope (`name`, i.e. not module-relative scope `some_mod::name` or `::name`), it's searched roughly in the next order:
- local variables
- items in unnamed blocks
- items in the current module
- :sparkles: NEW! :sparkles: crate names passed with `--extern` ("extern prelude")
- standard library prelude (`Vec`, `drop`)
- language prelude (built-in types like `u8`, `str`, etc)
The last two layers contain a limited set of names controlled by us and not arbitrary user-defined names like upper layers. We want to be able to add new names into these two layers without breaking user code, so "extern prelude" names have higher priority than std prelude and built-in types.
This is a one-time breaking change, that's why it would be nice to run this through crater.
Practical impact is expected to be minimal though due to stylistic reasons (there are not many `Uppercase` crates) and due to the way how primitive types are resolved (https://github.com/rust-lang/rust/pull/32131).
|
|
|
|
|
|
It's subsumed by `feature(use_extern_macros)` and `pub use`
|
|
Remove some unused code
|
|
Stabilizing an inherent method may cause change in behavior instead of
inference error. Updated to use the wording from [varkor's comment].
Closes #50232.
[varkor's comment]: https://github.com/rust-lang/rust/issues/50232#issuecomment-384678097
|
|
|
|
stabilize `#[must_use]` for functions and must-use comparison operators (RFC 1940)
r? @nikomatsakis
|
|
Display correct unused field suggestion for nested struct patterns
Extends https://github.com/rust-lang/rust/pull/47922 by checking more sophisticated patterns (e.g. references, slices, etc.).
Before:
```
warning: unused variable: `bar`
--> src/main.rs:37:21
|
37 | &Foo::Bar { bar } => true,
| ^^^ help: consider using `_bar` instead
|
= note: #[warn(unused_variables)] on by default
```
After:
```
warning: unused variable: `bar`
--> src/main.rs:37:21
|
37 | &Foo::Bar { bar } => true,
| ^^^ help: try ignoring the field: `bar: _`
|
= note: #[warn(unused_variables)] on by default
```
Fixes #50303.
r? @estebank
|
|
|
|
|
|
Add a ui test for an incorrect Result success type in a #[test]
cc https://github.com/rust-lang/rust/issues/48854#issuecomment-384730601
r? @nikomatsakis
|
|
|
|
Warn on pointless #[derive] in more places
This fixes the regression in #49934 and ensures that unused `#[derive]` invocations on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. There is a separate warning hardcoded for `#[derive]` on macro invocations since linting (even the early-lint pass) occurs after expansion. This also adds regression tests for some nodes that were already warning properly.
closes #49934
|
|
|
|
|
|
This fixes the regression in #49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly.
closes #49934
|
