Josh Klint said:
The behavior I would prefer is that when you double-click on the error it takes you to this line of code:

You will get to that line if you click on this line:

1> C:\Junk\Src\Thing.cpp(155): note: see reference to function template instantiation 'std::shared_ptr<Point> &std::shared_ptr<Point>::operator =<Triangle>(const std::shared_ptr<Triangle> &) noexcept' being compiled

The actual source of the error for such template-failures is usually the last element down the stack of template-errors. You have to scroll down, looking for the first file that is from your own codebase.

In general, such errors could improve once concepts are being used everywhere in the std-library (and given that you are using c++20), but I'm not sure it would even do anything in your specific case.

I mean, I did test it with a simple test-case in /latest in MSVC 2022, and it did give me a simpler error:

#include <memory>

class A {};
class B {};

int main(void)
{
	std::shared_ptr<A> a2;
	std::shared_ptr<B> b2;

	b2 = a2;
	
	return 0;
}

gives me, in its entirety:

1>H:\Acclimate\Repo\Acclimate Testing\main.cpp(41,9): error C2679: Binärer Operator "=": Es konnte kein Operator gefunden werden, der einen rechtsseitigen Operanden vom Typ "std::shared_ptr<A>" akzeptiert (oder keine geeignete Konvertierung möglich)

1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\memory(1632,17): message : kann "std::shared_ptr<B> &std::shared_ptr<B>::operator =(std::shared_ptr<B> &&) noexcept" sein

1>C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.33.31629\include\memory(1621,17): message : oder "std::shared_ptr<B> &std::shared_ptr<B>::operator =(const std::shared_ptr<B> &) noexcept"

1>H:\Acclimate\Repo\Acclimate Testing\main.cpp(41,9): message : bei Anpassung der Argumentliste "(std::shared_ptr<B>, std::shared_ptr<A>)"

(sorry for the german, but it should be clear whats happening).
Is the code you shown actually the full source of the error? Or is this maybe inside another template-function in your code? Otherwise, I'm not sure which compiler and language-version you are running, but under the assumption that its not 2022 and/or /latests; and/or you need to support users with older versions of MSVC - no, there isn't really anything you can do. There is no setting to make those errors more clear in cases where a template-error happens somewhere inside a nested template-call “stack”. You can try to use the latest versions of c++ and std, and in case of you using template-functions yourself, you can try to use concepts (or SFINEA) as much as possible so that errors will be caught when a template function is used, instead of somewhere inside the nested calls. But if you and your users are using the standard-library, you're out of luck on that front.

Josh Klint said:
It's not really the error message that is the problem, it's the fact that when you double-click on the error it takes you to a confusing header file the user has never seen before. Clicking on the error should take you to the mistake in your code.

Yes, that is whats happening in my version of the compiler with the code i posted. The first line is saying “main.cpp (37)” as the source, and when I click it, I land at the line of “a = b”. If you don't belive me: https://gyazo.com/e05a8f8c32535a772d2450f4b6ceb844

But

(continuing here since my last post won't let me finish writing, thanks site)

But that is due to our erros being different: Mines first line is in “main.cpp”, yours in “memory.h”. So that must mean you are eigther using a different (read; older) version of MSVC or an older language-standard; or the code/error you posted isn't the full picture of what you are doing.
So yes, the problem is the actual error, because the error will always take you to the line of the actual file where it happend. Its just that in my case the error is caugth at the assignment-line (due to my version of shared_ptr having a SFINEA-constraint on it), and yours in memory.h, for some reason.

On a side note IMHO std::shard_ptr is garbage, mainly because it uses twice as much memory as a normal pointer. In addition they lock you into other things like thread safety and a weak pointer counter whether you need those or not.