Remove unused lowering field and method
r? @nikomatsakis
So while trying to understand lowering better, I found out that there's something related to creating definitions. Analyzing that further, I realized that it is entirely dead code.
The `parent_def` field was only ever used for setting and resetting the field itself. The field was never read anywhere else and thus its value was entirely unused.
Maybe the `unused_field` lint should detect when the only use of a field is the field being read without using the read value other than writing back to the field?
The diff is best viewed without whitespace changes getting in the way: https://github.com/rust-lang/rust/pull/51034/files?w=1
Improve `Debug` impl of `time::Duration`
Hi there!
For a long time now, I was getting annoyed by the derived `Debug` impl of `Duration`. Usually, I use `Duration` to either do quick'n'dirty benchmarking or measuring the time of some operation in general. The output of the derived Debug impl is hard to parse for humans: is { secs: 0, nanos: 968360102 } or { secs: 0, nanos 98507324 } longer?
So after running into the annoyance several times (sometimes building my own function to print the Duration properly), I decided to tackle this. Now the output looks like this:
```
Duration::new(1, 0) => 1s
Duration::new(1, 1) => 1.000000001s
Duration::new(1, 300) => 1.0000003s
Duration::new(1, 4000) => 1.000004s
Duration::new(1, 600000) => 1.0006s
Duration::new(1, 7000000) => 1.007s
Duration::new(0, 0) => 0ns
Duration::new(0, 1) => 1ns
Duration::new(0, 300) => 300ns
Duration::new(0, 4001) => 4.001µs
Duration::new(0, 600300) => 600.3µs
Duration::new(0, 7000000) => 7ms
```
Note that I implemented the formatting manually and didn't use floats. No information is "lost" when printing. So `Duration::new(123_456_789_000, 900_000_001)` prints as `123456789000.900000001s`.
~~This is not yet finished~~, but I wanted to open the PR now already in order to get some feedback (maybe everyone likes the derived impl).
### Still ToDo:
- [x] Respect precision ~~and width~~ parameter of the formatter (see [this comment](https://github.com/rust-lang/rust/pull/50364#issuecomment-386107107))
### Alternatives/Decisions
- Should large durations displayed in minutes, hours, days, ...? For now, I decided not to because the current formatting is close the how a `Duration` is stored. From this new `Debug` output, you can still easily see what the values of `secs` and `nanos` are. A formatting like `3h 27m 12s 9ms` might be more appropriate for a `Display` impl?
- Should this rather be a `Display` impl and should `Debug` be derived? Maybe this formatting is too fancy for `Debug`? In my opinion it's not and, as already mentioned, from the current format one can still very easily determine the values for `secs` and `nanos`.
- Whitespace between the number and the unit?
### Notes for reviewers
- ~~The combined diff sucks. Rather review both commits individually.~~
- ~~In the unit test, I am building my own type implementing `fmt::Write` to test the output. Maybe there is already something like that which I can use?~~
- My `Debug` impl block is marked as `#[stable(...)]`... but that's fine since the derived Debug impl was stable already, right?
---
~~Apart from the main change, I moved all `time` unit tests into the `tests` directory. All other `libcore` tests are there, so I guess it was simply an oversight. Prior to this change, the `time` tests weren't run, so I guess this is kind of a bug fix. If my `Debug` impl is rejected, I can of course just send the fix as PR.~~ (this was already merged in #50466)
stabilize RangeBounds collections_range #30877
The FCP for #30877 closed last month, with the decision to:
1. move from `collections::range::RangeArgument` to `ops::RangeBounds`, and
2. rename `start()` and `end()` to `start_bounds()` and `end_bounds()`.
Simon Sapin already moved it to `ops::RangeBounds` in #49163.
I renamed the functions, and removed the old `collections::range::RangeArgument` alias.
This is my first Rust PR, please let me know if I can improve anything. This passes all tests for me, except the `clippy` tool (which uses `RangeArgument::start()`).
I considered deprecating `start()` and `end()` instead of removing them, but the contribution guidelines indicate we can break `clippy` temporarily. I thought it was best to remove the functions, since we're worried about name collisions with `Range::start` and `end`.
Closes#30877.
Fix naming conventions for new lints
We actually have an RFC from Oct 2014 specifying naming conventions for lints that is still relevant - https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md#lints.
Unfortunately, human memory doesn't work for such prolonged periods of time, so a number of recently added edition-related lints don't follow the conventions.
This PR fixes names for those lints.
Unstable lints, simply renamed:
- `unused_lifetime` -> `unused_lifetimes`
- `absolute_path_not_starting_with_crate` -> `absolute_paths_not_starting_with_crate`
- `unnecessary_extern_crate` -> `unnecessary_extern_crates`
New lints stabilized in the last couple of releases, registered as renamed (old names still work with a warning):
- `single_use_lifetime` -> `single_use_lifetimes`
- `elided_lifetime_in_path` -> `elided_lifetimes_in_paths`
- `bare_trait_object` -> `bare_trait_objects`
- `unstable_name_collision` -> `unstable_name_collisions`
- `unused_doc_comment` -> `unused_doc_comments`
NOT changed, too old to rename:
- `const_err` -> `const_errors`
- `unused_allocation` -> `unused_allocations`
NOT changed, deprecation lints, no need to rename, they are going to be removed anyway:
- `invalid_type_param_default` -> `invalid_type_param_defaults`
- `missing_fragment_specifier` -> `missing_fragment_specifiers`
- `tyvar_behind_raw_pointer` -> `tyvars_behind_raw_pointer`
- `illegal_floating_point_literal_pattern` -> `illegal_floating_point_literal_patterns`
implement the chalk-engine traits
Preliminary implementation for the Chalk traits in rustc. Lots of `panic!()` placeholders to be filled in later.
This is currently blocked on us landing https://github.com/rust-lang-nursery/chalk/pull/131 in chalk and issuing a new release, which should occur later today.
r? @scalexm
cc @leodasvacas
