The most typical use of call-site is probably that as presently declared on Wikipedia: it is nothing more than the place in some code where a call to a function or subroutine is made. It is a completely general term that can be applied to all manner of languages (and certainly nothing to do with dynamic programming!).
I usually hear the term used (as oppose to just the term "call") to make it clear that one is discussing the syntax and semantics of the code where a function/method/subroutine is called, as oppose to the underlying semantics of the call, or the semantics at function/method definition: in this way, it is absolutely not about the compiler or any generate code (even though the term will still apply to the code generated by the compiler/runtime, as I think amon has already discussed), it is about bringing the specific code that translates to a call into context, and sometimes the code in the immediate vicinity.
This is the sort of picture I have in my head:
call-site call call-target/method definition
int.TryParse(str, out i); (runtime) public static bool TryPars(...
The 'call-site' is a useful term to talk about syntax of making a call, and the semantics which affect the caller (detailed by amon). Consider, for example, the new
in modifier in C#, a 'call' which passes an argument as 'in' has certain semantics associated with it (it is passed by ref, possibly after a copy), but this isn't necessarily clear from the syntax 'at the call site', where
in isn't mandatory. The idea is that the call-site semantics (i.e. the behaviour which influences the caller/call-site) of passing an argument by reference with
in are close enough to those of passing by value that it doesn't need to disambiguated by syntax at the call-site. I disagree with this claim, and I'd have a hard time discussing it without a term like 'call-site'!
Another example: a dynamic call (e.g. for a virtual/interface method) has somewhat complicated runtime behaviours (again, detailed by amon) and it isn't known at compile time which method will be called, but all the 'call-site' cares about is the semantics of dispatching that call: if you are calling
ToString() on an
object, you don't really care that it is actually a
string at the call-site; you only care that
object exposes a virtual
ToString() method (it's up to the runtime to work out which method to actually call). Indeed, at the call-site (e.g. in C#) it isn't necessarily clear from the syntax whether this is a virtual call: the distinction between a virtual and non-virtual call is often considered unimportant enough at the call-site that it doesn't need to be disambiguated for the programmer at the call-site (even though it is vitally important for the compiler/runtime to make a meaningful call)
One last example: consider C#'s
ref and C++'s
&: the semantics at the call-site in both language are just about the same in both languages: a reference is passed rather than a value, but each language has different syntax at the call-site, where C# requires
ref and C++ does not require
& (or something like that). Again, the language designers have made some syntax decisions about how calls are represented at the call-site, informed by the semantics at the call-site. (I prefer the C# call-site syntax because it exposes the call-site semantics, which I believe I as a programmer should have to acknowledge when I made such a call). It is hopefully obvious that the method definition needs to know it is receiving a parameter by reference, because it changes the behaviour of modifying it (e.g. with
=). You could argue, however, that the runtime doesn't care (in such statically typed languages, where runtime-dispatch is nominally-informed): it just has to get this value from the caller to the callee, it doesn't care whether it is a reference or not, that is a concern for the call-site and call-target.
More loosely, 'call-site' might refer to the code which indicates a call as well as the 'associated' code around it (as opposed to just the 'call'). In C#, for example, one might refer to defining a dummy variable 'at' a call-site, e.g. when calling a
bool looksLikeAnInt = int.TryParse(str, out dummy);
This whole 'block' could be considered part of the call-site. I'd consider this a less 'precise' meaning, but that doesn't stop me using it.