/gem5/src/ |
H A D | Doxyfile | 788 # The HTML_FOOTER tag can be used to specify a personal HTML footer for 790 # standard footer. 792 HTML_FOOTER = doxygen/footer.html 803 # If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
|
/gem5/src/gpu-compute/ |
H A D | wavefront.hh | 96 * int foo(int arg1, double arg2)
|
/gem5/tests/test-progs/asmtest/src/riscv/isa/rv64ua/ |
H A D | lrsc.S | 30 la a0, foo; \ 37 la a0, foo; \ 45 # have each core add its coreid+1 to foo 1024 times 46 la a0, foo 66 lw a0, foo; \ 84 foo: .word 0 label
|
/gem5/ext/googletest/googlemock/docs/ |
H A D | CheatSheet.md | 9 class Foo { 11 virtual ~Foo(); 18 (note that `~Foo()` **must** be virtual) we can define its mock as 22 class MockFoo : public Foo { 68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n)); 88 MockFoo foo; // #2 90 ON_CALL(foo, GetSize()) // #3 94 EXPECT_CALL(foo, Describe(5)) // #4 99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5 258 1. a native array passed by reference (e.g. in `Foo(cons [all...] |
H A D | CookBook.md | 8 readability, it is recommended to write `using ::testing::Foo;` once in 9 your file before using the name `Foo` defined by Google Mock. We omit 25 class Foo { 37 class MockFoo : public Foo { 54 class Foo { 57 // Must be virtual as we'll inherit from Foo. 58 virtual ~Foo(); 69 class MockFoo : public Foo { 84 class MockFoo : public Foo { 86 using Foo [all...] |
H A D | DesignDoc.md | 77 ACTION(Foo) { 84 defines an action `Foo()` that invokes argument #2 (a function pointer) 177 ACTION(Foo) { 201 | `ACTION(Foo)` | `Foo()` | `FooAction` | 238 * They have subtle semantics that easily confuses new users. For example, in expression `_1++ + foo++`, `foo` will be incremented only once where the expression is evaluated, while `_1` will be incremented every time the unnamed function is invoked. This is far from intuitive.
|
H A D | ForDummies.md | 111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?) 113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed. 115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo [all...] |
H A D | FrequentlyAskedQuestions.md | 85 *os << "the Foo property is " << value.GetFoo(); 105 *listener << "the Foo property is " << value.GetFoo(); 258 class Foo { 263 class MockFoo : public Foo { 270 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier 276 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers 280 `const` modifier is _ignored_. Therefore, the `Foo` base class above 283 class Foo { 294 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`. 322 EXPECT_CALL(foo, Ba [all...] |
/gem5/ext/googletest/googlemock/docs/v1_5/ |
H A D | CheatSheet.md | 9 class Foo { 11 virtual ~Foo(); 18 (note that `~Foo()` **must** be virtual) we can define its mock as 22 class MockFoo : public Foo { 68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n)); 88 MockFoo foo; // #2 90 ON_CALL(foo, GetSize()) // #3 94 EXPECT_CALL(foo, Describe(5)) // #4 99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5 235 1. a native array passed by reference (e.g. in `Foo(cons [all...] |
H A D | CookBook.md | 8 readability, it is recommended to write `using ::testing::Foo;` once in 9 your file before using the name `Foo` defined by Google Mock. We omit 25 class Foo { 37 class MockFoo : public Foo { 54 class Foo { 57 // Must be virtual as we'll inherit from Foo. 58 virtual ~Foo(); 69 class MockFoo : public Foo { 84 class MockFoo : public Foo { 86 using Foo [all...] |
H A D | ForDummies.md | 111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?) 113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed. 115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo [all...] |
H A D | FrequentlyAskedQuestions.md | 81 *os << "the Foo property is " << value.GetFoo(); 101 *listener << "the Foo property is " << value.GetFoo(); 254 class Foo { 259 class MockFoo : public Foo { 266 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier 272 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers 276 `const` modifier is _ignored_. Therefore, the `Foo` base class above 279 class Foo { 290 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`. 318 EXPECT_CALL(foo, Ba [all...] |
/gem5/ext/googletest/googlemock/docs/v1_6/ |
H A D | CheatSheet.md | 9 class Foo { 11 virtual ~Foo(); 18 (note that `~Foo()` **must** be virtual) we can define its mock as 22 class MockFoo : public Foo { 68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n)); 88 MockFoo foo; // #2 90 ON_CALL(foo, GetSize()) // #3 94 EXPECT_CALL(foo, Describe(5)) // #4 99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5 240 1. a native array passed by reference (e.g. in `Foo(cons [all...] |
H A D | CookBook.md | 8 readability, it is recommended to write `using ::testing::Foo;` once in 9 your file before using the name `Foo` defined by Google Mock. We omit 25 class Foo { 37 class MockFoo : public Foo { 54 class Foo { 57 // Must be virtual as we'll inherit from Foo. 58 virtual ~Foo(); 69 class MockFoo : public Foo { 84 class MockFoo : public Foo { 86 using Foo [all...] |
H A D | ForDummies.md | 111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?) 113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed. 115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo [all...] |
H A D | FrequentlyAskedQuestions.md | 85 *os << "the Foo property is " << value.GetFoo(); 105 *listener << "the Foo property is " << value.GetFoo(); 258 class Foo { 263 class MockFoo : public Foo { 270 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier 276 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers 280 `const` modifier is _ignored_. Therefore, the `Foo` base class above 283 class Foo { 294 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`. 322 EXPECT_CALL(foo, Ba [all...] |
/gem5/ext/googletest/googlemock/docs/v1_7/ |
H A D | CheatSheet.md | 9 class Foo { 11 virtual ~Foo(); 18 (note that `~Foo()` **must** be virtual) we can define its mock as 22 class MockFoo : public Foo { 68 MOCK_METHOD_1_WITH_CALLTYPE(STDMETHODCALLTYPE, Foo, bool(int n)); 88 MockFoo foo; // #2 90 ON_CALL(foo, GetSize()) // #3 94 EXPECT_CALL(foo, Describe(5)) // #4 99 EXPECT_EQ("good", MyProductionFunction(&foo)); // #5 253 1. a native array passed by reference (e.g. in `Foo(cons [all...] |
H A D | CookBook.md | 8 readability, it is recommended to write `using ::testing::Foo;` once in 9 your file before using the name `Foo` defined by Google Mock. We omit 25 class Foo { 37 class MockFoo : public Foo { 54 class Foo { 57 // Must be virtual as we'll inherit from Foo. 58 virtual ~Foo(); 69 class MockFoo : public Foo { 84 class MockFoo : public Foo { 86 using Foo [all...] |
H A D | ForDummies.md | 111 When you define a mock class, you need to decide where to put its definition. Some people put it in a `*_test.cc`. This is fine when the interface being mocked (say, `Foo`) is owned by the same person or team. Otherwise, when the owner of `Foo` changes it, your test could break. (You can't really expect `Foo`'s maintainer to fix every test that uses `Foo`, can you?) 113 So, the rule of thumb is: if you need to mock `Foo` and it's owned by others, define the mock class in `Foo`'s package (better, in a `testing` sub-package such that you can clearly separate production code and testing utilities), and put it in a `mock_foo.h`. Then everyone can reference `mock_foo.h` from their tests. If `Foo` ever changes, there is only one copy of `MockFoo` to change, and only tests that depend on the changed methods need to be fixed. 115 Another way to do it: you can introduce a thin layer `FooAdaptor` on top of `Foo` and code to this new interface. Since you own `FooAdaptor`, yo [all...] |
H A D | FrequentlyAskedQuestions.md | 85 *os << "the Foo property is " << value.GetFoo(); 105 *listener << "the Foo property is " << value.GetFoo(); 258 class Foo { 263 class MockFoo : public Foo { 270 warning C4301: 'MockFoo::Bar': overriding virtual function only differs from 'Foo::Bar' by const/volatile qualifier 276 warning C4373: 'MockFoo::Bar': virtual function overrides 'Foo::Bar', previous versions of the compiler did not override when parameters only differed by const/volatile qualifiers 280 `const` modifier is _ignored_. Therefore, the `Foo` base class above 283 class Foo { 294 _declaration_, we recommend to remove it in both `Foo` and `MockFoo`. 322 EXPECT_CALL(foo, Ba [all...] |
/gem5/ext/googletest/googlemock/include/gmock/ |
H A D | gmock-actions.h | 55 // To implement an action Foo, define: 56 // 1. a class FooAction that implements the ActionInterface interface, and 58 // const FooAction*. 197 // // Sets the default value for type T to be foo. 198 // DefaultValue<T>::Set(foo); 412 // class FooAction { 423 // MakePolymorphicAction(object) where object has type FooAction. See 471 // MakePolymorphicAction(foo); 473 // PolymorphicAction<TypeOfFoo>(foo); 520 // Foo fo [all...] |
H A D | gmock-cardinalities.h | 48 // To implement a cardinality Foo, define: 49 // 1. a class FooCardinality that implements the 52 // const FooCardinality*.
|
H A D | gmock-generated-actions.h | 829 // 'foo', you can write 'foo_type'. For example, in the body of 838 // ACTION_Pk(Foo, p1, ..., pk) { ... } 843 // FooActionPk<p1_type, ..., pk_type> Foo(p1_type p1, ..., pk_type pk) { ... } 846 // explicitly when invoking Foo(), as in Foo<long, bool>(5, false); 849 // Foo(p1, ..., pk) to a variable of type FooActionPk<p1_type, ..., 922 // EXPECT_CALL(mock, Foo( [all...] |
H A D | gmock-generated-actions.h.pump | 311 // 'foo', you can write 'foo_type'. For example, in the body of 320 // ACTION_Pk(Foo, p1, ..., pk) { ... } 325 // FooActionPk<p1_type, ..., pk_type> Foo(p1_type p1, ..., pk_type pk) { ... } 328 // explicitly when invoking Foo(), as in Foo<long, bool>(5, false); 331 // Foo(p1, ..., pk) to a variable of type FooActionPk<p1_type, ..., 400 // EXPECT_CALL(mock, Foo( [all...] |
H A D | gmock-generated-function-mockers.h | 831 // Foo(1); 832 // Foo(2); 833 // Foo(3); 835 // and want to verify that Foo(1) and Foo(3) both invoke 836 // mock.Bar("a"), but Foo(2) doesn't invoke anything, you can write: 838 // TEST(FooTest, InvokesBarCorrectly) { 849 // Foo(1); 851 // Foo(2); 853 // Foo( [all...] |