Semantic versioning is quiet on roadmaps: it only cares about the actual release tagged. In your case, if feature 3 is completed ahead of schedule, it's up to you to decide whether it'll make it into 1.1.0 or if it should remain in 1.2.0.
To have that type of flexibility though, you'll want to carefully consider your integration/release process. If you're just merging everything into your release branch/master whenever a feature is done, you won't be able to "hold back" a feature for a future release.
One way to do this is to have release branches. Once you start preparing for the next release, you'd create a branch off of master or trunk that's solely for that release. Only features on the roadmap for that release get merged into that branch. You could have multiple, simultaneous releases being worked on at the same time using this method, with each future release getting its own branch.
With a process like that in place, nothing happens with respect to your versioning when feature 3 is complete: it gets added to the 1.2.0 branch and stays there until you're ready to release 1.2.0.
However, this type of release process can get complicated quickly, and is sometimes prone to error: if a feature is completed but not part of an existing release, where does it go? Should you commit features to both a release branch and a main integration branch? Why was feature 3 promised later if it was going to be worked on first?
Because of this, it's common to take amore agile approach and avoid locking features to specific releases: whenever a feature is ready, it goes into the next release, whatever that is. In your case, you could either:
- tag a new release after feature 3 is done, which would mean 1.1.0 would have feature 3 but not feature 2, and 1.2.0 would have both features
- wait to tag a new release until feature 2 is done, which would mean 1.1.0 would have both features