A race attack (on 0/unconfirmed) uses deception where the Bitcoin node used by the recipient sees one transaction but the miners see a different transaction -- with both transactions spending the same coin.
So if your node were to see one transaction (at 0/unconfirmed) and then eventually a block came in with a different transaction then your node will behave as if the original transaction never occurred.
So there's no alert and no other way to learn that a double spend occurred.
If the race attack failed (i.e., the mining nodes received the same transaction as the recipient's node knew of) then there would be no way for a the recipient's node to know that an attack had been attempted.
Now if there is a block re-org in which a transaction had a confirmation and then a subsequent block arrived causing a transaction to revert to 0/unconfirmed, then that might be visible to someone watching a transaction but the client itself does not alert on such an event.
Some services that have multiple listeners (using a customized client that does not reject invalid double-sped transactions) can recognize double spends, but this detection and alerting is not something the stock bitcoin.org client offers.
Blockchain.info does report double spend conflicts for an address in their web interface.