<div dir="ltr"><div><div><div><div><div><div><div><div><div><div>If we're considering adding items to the release notes:<br><br>A couple of pain points I encountered when migrating my code from 3.5.1 to 3.7.1. I don't keep ToT, and thereby avoid the constant API churn, but then I have a bit of work to do when upgrading from one release to another. <br><br></div>Bitcode reader/writer: I have a class that creates a Module*, and optionally preloads it with bitcode read from a file.<br><br></div>In 3.5.1 I used:<br><br> ErrorOr<Module *> parseBitcodeFile(MemoryBuffer *Buffer,<br> LLVMContext &Context);<br><br></div>In 3.7.1 this became:<br><br> ErrorOr<std::unique_ptr<Module>><br> parseBitcodeFile(MemoryBufferRef Buffer, LLVMContext &Context,<br> DiagnosticHandlerFunction DiagnosticHandler = nullptr);<br><br></div>I had a bit of difficulty figuring out why the unique_ptr<> was used. I thought the purpose of a unique_ptr<> was to ensure that some (temporary) object could never be leaked or dangled, by making it very hard to get at the underlying raw pointer. Yet, everywhere else I needed to pass a Module*, and there's nothing to stop me from dangling it.<br><br></div>I understand we're not out to create a C++11 tutorial, but major changes in the memory ownership semantics ought to be documented.<br><br></div><div><br></div>Debug metadata generation: LOTS of changes, but the worst:<br><br></div>In 3.5.1 we have:<br><br> DICompositeType createReplaceableForwardDecl(<br> unsigned Tag, StringRef Name, DIDescriptor Scope, DIFile F,<br> unsigned Line, unsigned RuntimeLang = 0, uint64_t SizeInBits = 0,<br> uint64_t AlignInBits = 0, StringRef UniqueIdentifier = StringRef());<br><br></div>In 3.7.1 this was changed to:<br><br> DICompositeType *createReplaceableCompositeType(<br> unsigned Tag, StringRef Name, DIScope *Scope, DIFile *F, unsigned Line,<br> unsigned RuntimeLang = 0, uint64_t SizeInBits = 0,<br> uint64_t AlignInBits = 0, unsigned Flags = DINode::FlagFwdDecl,<br> StringRef UniqueIdentifier = "");<br><br></div>However, simply making the code change and adjusting the arguments leads to an assert. I also had to call replaceTemporary() at the point where the replacement was available. This was not required in 3.5.1. Prior to this point I was unaware of the distinction between uniqued and non-uniqued metadata, nor did I have any reason to care.<br><br></div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 1:57 PM, Hans Wennborg via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Feb 10, 2016 at 10:50 AM, Mehdi Amini via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> Is this change indeed intended as a visible API change to source code generating references to argument list values? If so, can you point me to a description of how I should change our code? Should I bug someone else about this problem? Should this API change be documented in the 3.8.0 release notes?<br>
>><br>
>> Release notes is a good idea; somehow I never think of that. Hans, is it<br>
>> too late?<br>
><br>
> I wonder if it isn't it a bit to much detailed to put this in the release notes? I mean we change the C++ API all the time...<br>
<br>
Sure, but I think anything that helps users move to the next version<br>
is valuable. I realize we'll probably never have exhaustive lists of<br>
API changes in the release notes, but every little helps, and if<br>
Duncan wants to write a note for this one, I'll certainly take it.<br>
<br>
Thanks,<br>
Hans<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>