There are already many good explanations about "inline" in C++, such as this and this.
But generally most of them are talking about "even though a func with inline prefix, may or may not be expanded", or about "it's up to the compiler...".
When I am refactoring my old code recently, I need to decide whether keep or move some inline functions/methods into definite file (instead of header file). So I need to know that "If a func/method (without inline prefix) be implemented in *.cpp file instead of header file, may it NEVER be inline/expanded?". If we keep them stay in headers, at least there be a chance/hope them would be inlined?
Will c++ functions/methods implemented in *.cpp file be NEVER inline expanded?
If you use a recent GCC as your C++ compiler, you could be interested by compiler flags such as -Wall -O0 -fno-inline (or, on the opposite, optimizing with -flto -fwhole-program -Wall -O3 both at compile and link time). Configure wisely your build automation tool (e.g. your Makefile).
But the resulting executable might run slower.
I am using in May 2020 (e.g. in RefPerSys) g++ -fno-inline -O0 -g3 with GCC 9 or GCC 10 for ease of debugging with GDB (on Linux/Debian/Sid/x86-64). The same C++ source code can be compiled twice in two different ELF executables, one with full DWARF information and and no inlining, and another with DWARF information and optimizing flags.
When I am refactoring my old codes recently, I need to decide whether keep or move some inline functions/methods into definite file (instead of header file).
The only rational reason to do that is to reduce compilation time. Is it such a real concern? How many hours do you need to compile your C++ code? You might also ask your manager or client to buy you a more powerful development computer. Ask on Workplace for guidance and provide legal details.
A possibility might be to compile with g++ -Wall -Wextra -O0 -fno-inline -g during the debugging phase, and to deliver the same C++ code compiled and linked with g++ -Wall -Wextra -O3 -flto for production purposes. If executable size is a concern, consider replacing -O3 with -Os. YMMV.
Think also of legal considerations, see this.
The n3337 C++11 standard comes to mind.
Regarding inlining, you could compile with g++ -S -fverbose-asm -O3 and look into the generated code if inlining happened. You could even write your own GCC plugin to drive inlining decisions (see the GCC MILEPOST project or the old GCC MELT one or Bismon). This would require a few months of fulltime work.
PS. I happen to professionally work on Bismon and did contribute to GCC. Feel free to contact me by email to basile.starynkevitch@cea.fr about it. Maybe my boss could be delighted by a contract (only above 50k€) about it. The decision won't be mine, but that of my employer CEA LIST (and then political considerations matter regarding policies between France -near Paris- where I work and live and China -near Singapore- where you work).