about summary refs log tree commit diff
path: root/src/test/run-make/coverage-reports
AgeCommit message (Collapse)AuthorLines
2023-01-11Move /src/test to /testsAlbert Larsan-2946/+0
2022-12-09Ignore errors when including clear_expected_if_blessedTomasz Miąsko-1/+1
Include is there only for the effect executing the rule. The file is not intended to be remade successfully to be actually included.
2022-11-26Attempt to solve problem with globsJubilee Young-1/+1
2022-11-24Avoid `GenFuture` shim when compiling async constructsArpad Borsos-2/+2
Previously, async constructs would be lowered to "normal" generators, with an additional `from_generator` / `GenFuture` shim in between to convert from `Generator` to `Future`. The compiler will now special-case these generators internally so that async constructs will *directly* implement `Future` without the need to go through the `from_generator` / `GenFuture` shim. The primary motivation for this change was hiding this implementation detail in stack traces and debuginfo, but it can in theory also help the optimizer as there is less abstractions to see through.
2022-10-18partially fix src/test/run-make/coverage-reports when cross-compilingPietro Albini-2/+7
The test does not work on cross-compiled targets because the --target flag was not passed to rustc inside the test. This commit fixes that by adding the flag to the invocations. Note that the test still fails on cross-compiled targets using remote-test, as remote-test is not capable (yet) of sending back to the host system the *.profraw file generated by the instrumentation. Because of that, this is only a partial fix, and the test has been ignored on cross-compilation.
2022-09-13Bless coverage report.Camille GILLOT-14/+14
2022-08-31Fix a bunch of typoDezhi Wu-3/+3
This PR will fix some typos detected by [typos]. I only picked the ones I was sure were spelling errors to fix, mostly in the comments. [typos]: https://github.com/crate-ci/typos
2022-08-23Diagnose missing includes in run-make testsTomasz Miąsko-1/+1
2022-08-01Don't derive `PartialEq::ne`.Nicholas Nethercote-23/+0
Currently we skip deriving `PartialEq::ne` for C-like (fieldless) enums and empty structs, thus reyling on the default `ne`. This behaviour is unnecessarily conservative, because the `PartialEq` docs say this: > Implementations must ensure that eq and ne are consistent with each other: > > `a != b` if and only if `!(a == b)` (ensured by the default > implementation). This means that the default implementation (`!(a == b)`) is always good enough. So this commit changes things such that `ne` is never derived. The motivation for this change is that not deriving `ne` reduces compile times and binary sizes. Observable behaviour may change if a user has defined a type `A` with an inconsistent `PartialEq` and then defines a type `B` that contains an `A` and also derives `PartialEq`. Such code is already buggy and preserving bug-for-bug compatibility isn't necessary. Two side-effects of the change: - There is only one error message produced for types where `PartialEq` cannot be derived, instead of two. - For coverage reports, some warnings about generated `ne` methods not being executed have disappeared. Both side-effects seem fine, and possibly preferable.
2022-07-28Diagnose missing make includesTomasz Miąsko-1/+1
2022-07-28Move coverage tests from run-make-fulldeps to run-makeTomasz Miąsko-0/+2964