Repository navigation
-framework argument not handled correctly #13204
Description
We appear to be mishandling -F, -iframework and -iframeworkwithsysroot compiler arguments, assuming them to be variations of the -framework argument. Rather, these arguments specify where to search for frameworks specified by a -framework argument. These args set up a set of search paths similar to include paths but that apply only to resolving subsequent -framework args on the command line. Also, a -framework argument is intended to be a framework 'name', not a path.
The order of arguments is significant. A -framework preceding a -F does not consider the search path the -F adds. Similarly, if -iframeworkwithsysroot is specified, that applies only to subsequent -framework arg.
It doesn't help that man clang on macOS provides misleading information about -F, associating it specifically with framework include paths (not frameworks themselves), only differing from the description of -I by one word, and not referring to -framework at all.
-I<directory> Add the specified directory to the search path for include files.
-F<directory> Add the specified directory to the search path for framework include files.
Currently, the C/C++ Extension will search directories specified by any of these args (in addition to the default framework paths from a compiler query), for every framework within them, adding all of them to the browse path and IntelliSense configs. It looks like this behavior would be correct, to support sub-frameworks, if applied only to frameworks and not framework search paths.
Most users probably haven't noticed an issue, as this would pick up a superset of frameworks. Though, issues could potentially arise due to IntelliSense picking up headers with conflicting names from incorrect frameworks.
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
Colengms commentedon Jan 28, 2025
It's possible some users are currently benefiting from having all system framework include paths automatically added. If this is 'fixed', those users would have to add the system frameworks they want to use to their configuration using
-frameworkargs, analogous to having to do so on a compiler command line.Colengms commentedon Jan 29, 2025
The
macFrameworkPathsfield unfortunately seems to encode the misconception about these arguments, referring only to paths. For now, we could continue to support this field as indicating either a full path to a framework or a framework name (the later intended to be resolved against system search paths, and any additional framework search paths from compilerArgs, when the configuration is processed).Colengms commentedon Jan 29, 2025
Continuing to dig deeper, what we're doing now appears to be mostly correct.
"-framework" is primarily for linking purposes. It would be impossible to 'use' a framework without linking to it (unless it's a header-only framework?), but it's not strictly required at compile time. Clang does allow references to frameworks not specified with "-framework" in #include statements (framework include statements are special *), making the "framework search paths" interesting to us (and not "-framework"). The only issue here is that we currently look at "-framework" arguments, looking for search paths. Instead we can ignore "-framework" entirely, as it's effectively only useful at link time.
* (i.e.
#include <OpenGLES/ES2/gl.h>, mapping toOpenGLES.framework/Headers/ES2/gl.h).Repurposing this issue to track removing existing handling of "-framework" in favor of ignoring/stripping that argument.
[-]macOS frameworks not handled correctly[/-][+]`-framework` argument not handled correctly[/+]