These are somewhat stop-gap solutions to address #16625
core: Separate failure formatting in str methods slice, slice_to, slice_from
Use a separate inline-never function to format failure message for
str::slice() errors.
Using strcat's idea, this makes sure no formatting code from failure is
inlined when str::slice() is inlined. The number of `unreachable` being
inlined when usingi `.slice()` drops from 5 to just 1.
The testcase:
```
#![crate_type = "lib"]
pub fn slice(x: &str, a: uint, b: uint) -> &str {
x.slice(a, b)
}
```
shrinks from 16.9 kB to 3.3 kB llvm IR, and the number of `unreachable` drops from 5 to 1.
I was doing a lot of parsing ascii strings, and the generic bsearch functions in `tables.rs` came up very high in the profile.
This should avoid calling those functions for simple ASCII range chars.
There is a check in TwoWaySearcher::new to determine whether the needle is periodic. This is needed because during searching when a match fails, we cannot advance the position by the entire length of the needle when it is periodic, but can only advance by the length of the period.
The reason "bananas".contains("nana") (and similar searches) were returning false was because the periodicity check was wrong.
Closes#16589
Also, thanks to @Gankro, who came up with many buggy examples.
Use a separate inline-never function to format failure message for
str::slice() errors.
Using strcat's idea, this makes sure no formatting code from failure is
inlined when str::slice() is inlined. The number of `unreachable` being
inlined when usingi `.slice()` drops from 5 to just 1.
When MSYS shell executes program, if its arguments look like MSYS paths,
MSYS automatically converts them into Windows paths.
For example, `/c/path:/d/path` becomes `C:\path;D:\path`.
However, if there is only one path e.g. `/c/path`, it becomes `C:/path`.
maketest.py reverts the behavior to reduce confusion between MSYS and
Windows, but it didn't handle the `/c/path` case. This patch fixes the
issue.
Fixes#15297Fixes#15250
Heapify is O(n), extend as currently implemented is O(nlogn). No brainer.
Currently investigating whether extend can just be implemented as a local heapify.
Fixes#12118.
(I sneaked in an unrelated one-character whitespace fix I spotted while reviewing some benchmarks, if that is not okay, I can create a separate pull request for that.)
I don't know if anything else was relying on the old behavior, this seems more correct.
Fixes#16348
If '-F' is allowed to have an optional argument, with the previous version '-FF' would be translated to '-F -F'. In this new version '-FF' translates to '-F' with argument 'F'
Previously, `PrettyEncoder` indented a magic constant of 2 spaces per level, which may be fine for most uses but in my use case I would like to allow the user to specify the indent step for the outputted JSON in my program.
This is small change that does not break any existing code whatsoever, and does not change the behavior of existing uses. `PrettyEncoder::new()` still uses the default of 2.
I couldn't think of any simple tests for this change. The obvious one would be to check the outputted JSON for the correct number of spaces per indent level, but I think that would be more complex than the actual change itself and test little besides correctness and consistency, which can be verified visually. There's already a test for correct parsing of pretty-printed JSON that should still pass with this change.
