- User Since
- Jun 7 2019, 8:13 PM (26 w, 5 d)
Tue, Dec 3
After further testing, this actually doesn't work, but only if you are loading an associated PDB file. I have no idea what's going on, because I don't understand the internals of TypeServerSource, but it's throwing an assertion error at DebugTypes.cpp:191
Mon, Dec 2
Update with full context
Moved the clear commands to where @ruiu suggested. I was unable to upload a full context diff because the web interface refuses to work properly.
Fri, Nov 22
Addressed by https://reviews.llvm.org/D70292
Tue, Nov 19
I am not particularly convinced that this will fix the problem, as it simply moves the problem around - instead of having to remember to clean up global variables, now programmers have to remember to initialize them with invalid values. This would certainly make it easier to detect errors once you realize there is one, but if someone silently adds a global variable and forgets to initialize it, you're back at square one. The only reliable way to fix the problem is to create an object whose constructor or destructor is automatically called when necessary, which is why I suggested a global container object. Adding anything to the global container object doesn't require the programmer to remember anything, because the destructor will automatically destruct everything inside of it. If this is simply not possible, some sort of baseline test as suggested by MaskRay is likely your only option.
Mon, Nov 18
Thu, Nov 14
I can confirm this change would satisfy my use-case, although another reviewer ought to look over it.
Yes, I am calling lld::elf::link from my program, which statically links LLD as a library. I can create a change that adds a diag stream to all the linker calls, but this would touch quite a lot of files. It may be more appropriate to close this change and to create a new change for adding a new stream.
I am calling LLD from within another command line application, and I only want to display output from LLD if there is an actual error, or the user has enabled verbose logging, but several places in LLD use message() during the linking process even if it succeeds, which will output directly to stdout with no way for me to portably redirect it (unless I use freopen, which permanently redirects it to a file, forever, and cannot be restored afterwards). If there needs to be a separate stream for non-error messages, then there should be a way to pass that into the link() function as well, instead of bypassing everything and outputting directly to stdout.
Jun 10 2019
I do not have access to anything. The only repo I currently have cloned is my fork of the official git repository.
That is not an acceptable solution. This compiler is an embedded, statically linked library that can be used by other programs. It is not a standalone compiler. If the library is statically linked, there is literally no way to start a new process without forcing every single user of my library to support their own program being called with a special option for the sole purpose of invoking a linker. Since one of the intended uses, for example, is a game engine script library, which would compile a webassembly script for a map, this compilation process cannot require the game to support calling it's own executable, or link the script engine as a DLL for the sole purpose of having the script engine then load it's own DLL in a new process. These are not reasonable restrictions to have on what is supposed to be a self-contained compiler.