They cause their corresponding libraries / frameworks to be loaded via
LC_LOAD_WEAK_DYLIB instead of LC_LOAD_DYLIB.
Details
- Reviewers
gkm - Group Reviewers
Restricted Project - Commits
- rG98f03908d07d: [lld-macho] Support -weak_lx, -weak_library, -weak_framework
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/MachO/Driver.cpp | ||
---|---|---|
603–608 | IMO, there is no benefit in combining these cases, and a deficit in clarity. | |
672–676 | How about setting the forceWeakImport flag immediately after construction? Perhaps create void addWeakFile(StringRef path) and/or void addFile(StringRef path, bool isWeak) APIs around void addFile(StringRef path) that sets the flag when addFlag() returns a DylibFile. That way you don't need weakImportPaths. |
lld/MachO/Driver.cpp | ||
---|---|---|
672–676 | I agree this is kind of janky, but I think having an isWeak parameter that only has an effect when the resulting path contains a DylibFile is also kind of ugly... |
lld/MachO/Driver.cpp | ||
---|---|---|
616–623 | How about something like this ... |
have addFile return the new file
lld/MachO/Driver.cpp | ||
---|---|---|
616–623 | that was cleaner than I'd anticipated it being. thanks! |
lld/MachO/Driver.cpp | ||
---|---|---|
611 | I always find explicit nullptr-inequality checks to be overly noisy. I just looked and found that there are only three instances of != nullptr in all of lld/MachO/*.{h,cpp}, which IMO is at least two too many. The third is semi-legit for highlighting the boolean nature of pointer-to-something vs. pointer-to-nothing: ./UnwindInfoSection.cpp: return (compactUnwindSection != nullptr); If you don't feel so strongly about it, then please allow me to impose my will regarding this stylistic nit. If you do feel strongly, then I bet you could find a ton of places to add != nullptr. We could even start an edit war! 😆 |
lld/MachO/Driver.cpp | ||
---|---|---|
611 | ¯\_(ツ)_/¯ I mean, I think != nullptr is in line with "explicit over implicit" (yeah I know this isn't Python, but I like to carry the zen of Python wherever I go)... but it's a minor issue in the scheme of things |
IMO, there is no benefit in combining these cases, and a deficit in clarity.
By contrast, the other two OPT_weak_l and OPT_weak_framework do benefit from combining, since they have surrounding context that need not be duplicated.