| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
(compiler front-ends).
|
|
reword #[test] attribute error on fn items
fix of [#55787](https://github.com/rust-lang/rust/issues/55787)
Reworded error message from "#[test] attribute is only allowed on fn items" to "#[test] attribute is only allowed on non associated functions"
|
|
A few tweaks to iterations/collecting
- simplify and speed up `dot::GraphWalk::nodes` for `cfg::CFG`
- `reserve` the capacity for `edges` in `DepGraph::query`
- collect directly to a `HirVec` in `LoweringContext::lower_attrs`
- fix overallocation in `OnDiskCache::serialize`
- preallocate the `new_partitioning` vector in `merge_codegen_units`
- simplify `impl FromHex for str`
- improve the creation of `self_arg_names` in `impl MethodDef`
|
|
|
|
|
|
|
|
|
|
Suggest to remove prefix `b` in cfg attribute lint string
Closes #54926
r? @estebank
|
|
|
|
|
|
The restrictions were introduced in https://github.com/rust-lang/rust/pull/54277 and no longer necessary now because legacy plugins are now expanded in usual left-to-right order
|
|
|
|
Remove usages of span_suggestion without Applicability
Use `Applicability::Unspecified` for all of them instead.
Shall deprecations for the non-`_with_applicability` functions be added?
Shall clippy be addressed somehow?
r? @estebank
|
|
|
|
Also fix some formatting along the way.
|
|
|
|
... and also proc macro attributes used together with test/bench.
|
|
Co-authored-by: nikomatsakis
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Set applicability for more suggestions.
Converts a couple more calls to `span_suggestion_with_applicability` (#50723). To be on the safe side, I marked suggestions that depend on the intent of the user or that are potentially lossy conversions as MaybeIncorrect.
r? @estebank
|
|
Fix typos found by codespell.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[nll] enable feature(nll) on various crates for bootstrap: part 4
#53172
r? @nikomatsakis
|
|
Pointed out by nll. It is correct that the mut annotation is not needed.
|
|
|
|
Slightly refactor syntax_ext/format
expand_preparsed_format_args:
- move a potential error `return` earlier in the processing
- pre-allocate some of the required space for `cx.pieces` and `cx.str_pieces`
- create `cx`-independent objects before `cx`
- build `pieces` and `errs` using `collect` instead of a `push` loop
describe_num_args:
- return `Cow<str>` instead of `String`
|
|
Avoid unnecessary pattern matching against Option and Result
|
|
|
|
|
|
|
|
|
|
Use suggestions for shell format arguments
Follow up to #52649.
|
|
|
|
Replace push loops with extend() where possible
Or set the vector capacity where I couldn't do it.
According to my [simple benchmark](https://gist.github.com/ljedrz/568e97621b749849684c1da71c27dceb) `extend`ing a vector can be over **10 times** faster than `push`ing to it in a loop:
10 elements (6.1 times faster):
```
test bench_extension ... bench: 75 ns/iter (+/- 23)
test bench_push_loop ... bench: 458 ns/iter (+/- 142)
```
100 elements (11.12 times faster):
```
test bench_extension ... bench: 87 ns/iter (+/- 26)
test bench_push_loop ... bench: 968 ns/iter (+/- 3,528)
```
1000 elements (11.04 times faster):
```
test bench_extension ... bench: 311 ns/iter (+/- 9)
test bench_push_loop ... bench: 3,436 ns/iter (+/- 233)
```
Seems like a good idea to use `extend` as much as possible.
|
|
|
|
Prefer to_string() to format!()
Simple benchmarks suggest in some cases it can be faster by even 37%:
```
test converting_f64_long ... bench: 339 ns/iter (+/- 199)
test converting_f64_short ... bench: 136 ns/iter (+/- 34)
test converting_i32_long ... bench: 87 ns/iter (+/- 16)
test converting_i32_short ... bench: 87 ns/iter (+/- 49)
test converting_str ... bench: 54 ns/iter (+/- 15)
test formatting_f64_long ... bench: 349 ns/iter (+/- 176)
test formatting_f64_short ... bench: 145 ns/iter (+/- 14)
test formatting_i32_long ... bench: 98 ns/iter (+/- 14)
test formatting_i32_short ... bench: 93 ns/iter (+/- 15)
test formatting_str ... bench: 86 ns/iter (+/- 23)
```
|
|
Rollup of bare_trait_objects PRs
All deny attributes were moved into bootstrap so they can be disabled with a line of config.
Warnings for external tools are allowed and it's up to the tool's maintainer to keep it warnings free.
r? @Mark-Simulacrum
cc @ljedrz @kennytm
|