Prior to this commit, there was a stack of ReaderDatas, each one has a
reference to a Parser (same Parser in each, for now). However, the current
ReaderData is globally accessible. Because it holds a Parser, effectively
anything can run fish script; this also prevents us from making the Parser
&mut.
Split these up. Create ReaderData, which holds the data portion of the
reader machinery, and then create Reader which holds a ReaderData and a
Parser. Now `reader_current_data()` can only return the data itself; it
cannot execute fish script.
This results in some other nice simplifications.
This is a start on untangling input. Prior to this, a ReaderData and an
Inputter would communicate with each other; this is natural in C++ but
difficult in Rust because the Reader would own an Inputter and therefore
the Inputter could not easily reference the Reader. This was previously
"resolved" via unsafe code.
Fix this by collapsing Inputter into Reader. Now they're the same object!
Migrate Inputter's logic into a trait, so we get some modularity, and then
directly implement the remaining input methods on ReaderData.
* completions/magento: Fixes module aggregation for module related commmands
Previousely when attempting completion for commands `module:enable`,
`mmodule:disable` and `module:uninstall` and error would be disaplyed,
stating that "magento" was not found.
Upon inspection of the issue in the related completion script it became
clear that:
1. The shell command `magento` does not exist as the CLI script of
Magentoresides under `bin/magento`.
2. The module aggregation would not work after referncing the
appropriate CLI command as an undeclared variable was being
introspected.
3. Using Magento's CLI command took too long to respond as it has to
bootstrap the whole Magento stack in order to deliver modules.
Thus the whole aggregation was rewritten to a form that actually works
and reduces the aggregation to reading the appropriate information
directly from the configuration file, provided that the file exists and
PHP is installed.
* completions/magento: Refactors module aggregation for module related commmands to not use PHP script
Executing random scripts from fish completion poses a threat to the
system. While this would indicate that the Magento installation has been
corrupted, it still is better to not run `app/etc/config.php` to get
hold of the modules.
Thus the module aggregation was rewritten to make use of `sed` instead,
which has the additional benefit of being faster than using PHP.
Add round options, but I think can also add floor, ceiling, etc. And
the default mode is trunc.
Closes#9117
Co-authored-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
A few specific tests fail under i586 due to its inherent floating point
inaccuracy issues (rust-lang/rust#114479), so ignore these tests if certain
are met.
We have specific integration tests elsewhere in fish to check that even under
i586 we get mostly sane results, so this is OK. I tried to modify the assert
macros to check for a loose string match (up to one character difference) or an
f64 abs diff of less than epsilon, but it was a lot of code with little value
and increased the friction to contributing to the tests. Also, let's just
acknowledge the fact that all of i686, let alone i586 specifically, is a dead
end and not worth investing such time and effort into so long as it more or less
"works".
Closes#10474.
Due to the inherent floating point accuracy issues under i586 described
in #10474 and at https://github.com/rust-lang/rust/issues/114479, we need to add
a workaround to our littlecheck math tests to perform less stringent comparisons
when fish was built for x86 without SSE2 support.
This commit addresses the littlecheck issues that caused #10474 to be re-opened,
but I still have to reproduce the cargo test failures for
`negative_precision_width`, `test_float`, `test_float_g`, and `test_locale`.
The CMake `cargo test` integration was broken if Rust_CARGO_TARGET were used
with `CARGO_FLAGS` set to `-Zbuild-std` (e.g. to target i586 under i686 without
the i586 toolchain installed).
This would fail the FreeBSD tests whenever we merge or push multiple
times in quick succession.
Basically:
- Commits up to ABCDEF are pushed, which triggers a CI run
- Cirrus starts up, but takes a while - it knows to use commit ABCDEF
- More commits are pushed up to 123456
- Cirrus does a shallow clone, only has 123456
- Cirrus tries to check out ABCDEF, but doesn't know it - instant failure
Instead, let's use 100 commits, which should be enough
