user64911: Let’s have 2 transactions. The second one is duplicating Input of the first one.
Both have very high fees so they are selected by miner to be included in the same block but before passing validation (because it makes no sense to validate transactions if they aren’t included in the block after because the fee is too low).
Which is the transaction is going to be rejected by not being included in the block ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?
And where is the code in Bitcoin core handling this ? I mean which source files and lines ?

user48884: I am going to interpret this question from a different angle: If a node were to receive a block with two transactions that spend the same input, which transaction will it return to the mempool and which will it discard?

When a node receives a block that contains two or more transactions that spend the same inputs, the block would be marked invalid and thrown away entirely. None of the transactions in that block would be considered confirmed and any transaction that was already in the mempool will remain there. A transaction was not in the mempool but was in the block will not be added to the mempool.
As such, when the node receives this invalid block and validates it, when it determines it to be invalid, it throws away the block and does nothing. It does not change the UTXO set and it does not change the mempool. This means that if any of the conflicting transactions were in the mempool when the block is received, it will remain there. If none were, none of those transactions will be added to the mempool.
So if one of the conflicting transactions paid a higher fee, but the lower fee transaction was already in the node's mempool, the lower fee transaction would stay in the mempool and the higher fee one thrown away with the block.
The code for this behavior is here. ConnectBlock takes a CCoinsViewCache which is a cache for the UTXO set. This cache only writes out the changes made to it when its Flush() function is called. ConnectBlock will return false because the block is invalid and as such, this function will return here before Flush() can be called here. So no changes will be made to the UTXO set.
Furthermore, that early return due to an invalid block means that the mempool update will not occur either. The call for the mempool update here will not be reached because of the early return and thus the the transactions that were in the mempool at the time the block was received will remain there, and the ones that weren't in the mempool will be thrown out along with the block.

user63872: Every transaction included in a block must be valid in order for the block to be valid. An input can only be spent once, any attempt to spend it again would be invalid. 
So in your example, the entire block would be invalid and thus rejected by the network. Nodes that hear about and attempt to validate the block would get to the second transaction, see it is invalid (because one of its inputs was already spent), and reject the entire block. 
Generally, miners will choose the transaction that pays them the most. The bitcoin-core rules for relaying transactions are separate from this, so they aren’t of much consequence in the real world. A miner could easily run their own modified software that builds blocks in a way they like. Even if a transaction isn’t marked RBF, there is nothing stopping a miner from including a higher paying transaction they heard about instead. 

user13440: 
Which is the transaction is going to be rejected ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?

Generally speaking, miners will choose the transaction that has the highest fee, but they are not obliged to.  In fact they don't need to mine any of your transactions if they don't want to.

Both have very high fees so they are selected by miner to be included in the same block.

No, the miner must choose 1 or zero not both, otherwise the block they create will be invalid if it contains a double-spend.  Invalid blocks will waste the miners time and money as they will be rejected by the network.

And where is the code in Bitcoin core handling this ?

Sorry, can't help with specific location.

64911: <p>Let’s have 2 transactions. The second one is duplicating Input of the first one.<br>
Both have very high fees so they are selected by miner to be included in the same block but before passing validation (because it makes no sense to validate transactions if they aren’t included in the block after because the fee is too low).</p>

<p>Which is the transaction is going to be rejected by not being included in the block ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?</p>

<p>And where is the code in Bitcoin core handling this ? I mean which source files and lines ?</p>
 48884: <p>I am going to interpret this question from a different angle: If a node were to receive a block with two transactions that spend the same input, which transaction will it return to the mempool and which will it discard?</p>

<hr>

<p>When a node receives a block that contains two or more transactions that spend the same inputs, the block would be marked invalid and thrown away entirely. None of the transactions in that block would be considered confirmed and any transaction that was already in the mempool will remain there. A transaction was not in the mempool but was in the block will not be added to the mempool.</p>

<p>As such, when the node receives this invalid block and validates it, when it determines it to be invalid, it throws away the block and does nothing. It does not change the UTXO set and it does not change the mempool. This means that if any of the conflicting transactions were in the mempool when the block is received, it will remain there. If none were, none of those transactions will be added to the mempool.</p>

<p>So if one of the conflicting transactions paid a higher fee, but the lower fee transaction was already in the node's mempool, the lower fee transaction would stay in the mempool and the higher fee one thrown away with the block.</p>

<p>The code for this behavior is <a href="https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2407" rel="nofollow noreferrer">here</a>. <code>ConnectBlock</code> takes a <code>CCoinsViewCache</code> which is a cache for the UTXO set. This cache only writes out the changes made to it when its <code>Flush()</code> function is called. <code>ConnectBlock</code> will return false because the block is invalid and as such, this function will return <a href="https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2412" rel="nofollow noreferrer">here</a> before <code>Flush()</code> can be called <a href="https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2416" rel="nofollow noreferrer">here</a>. So no changes will be made to the UTXO set.</p>

<p>Furthermore, that early return due to an invalid block means that the mempool update will not occur either. The call for the mempool update <a href="https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2427" rel="nofollow noreferrer">here</a> will not be reached because of the early return and thus the the transactions that were in the mempool at the time the block was received will remain there, and the ones that weren't in the mempool will be thrown out along with the block.</p>
 63872: <p>Every transaction included in a block must be valid in order for the block to be valid. An input can only be spent once, any attempt to spend it again would be invalid. </p>

<p>So in your example, the entire block would be invalid and thus rejected by the network. Nodes that hear about and attempt to validate the block would get to the second transaction, see it is invalid (because one of its inputs was already spent), and reject the entire block. </p>

<p>Generally, miners will choose the transaction that pays them the most. The bitcoin-core rules for relaying transactions are separate from this, so they aren’t of much consequence in the real world. A miner could easily run their own modified software that builds blocks in a way they like. Even if a transaction isn’t marked RBF, there is nothing stopping a miner from including a higher paying transaction they heard about instead. </p>
 13440: <blockquote>
  <p>Which is the transaction is going to be rejected ? The first one with a slightly lower fee than the second or as it’s the same block, the second one ?</p>
</blockquote>

<p>Generally speaking, miners will choose the transaction that has the highest fee, but they are not obliged to.  In fact they don't need to mine any of your transactions if they don't want to.</p>

<blockquote>
  <p>Both have very high fees so they are selected by miner to be included in the same block.</p>
</blockquote>

<p>No, the miner must <strong>choose 1 or zero</strong> not both, otherwise the block they create will be invalid if it contains a double-spend.  Invalid blocks will waste the miners time and money as they will be rejected by the network.</p>

<blockquote>
  <p>And where is the code in Bitcoin core handling this ?</p>
</blockquote>

<p>Sorry, can't help with specific location.</p>
