-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[ClangImporter] Import constant values for 'const' globals #80749
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implementation looks fine, but I'd like to see more test coverage.
// For now, only import integer and float constants. If in the future | ||
// SwiftDeclSynthesizer::createConstant becomes able to import more | ||
// types, we can lift this restriction. | ||
if (val && (val->isFloat() || val->isInt())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a test case where val
would be null here? Do we have one where the type tests fail?
Also, the docs for evaluateValue()
mention that it can sometimes emit notes. Do those notes reach the user if ClangImporter causes them to be emitted? If so, how do they come out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the tests. My reading of evaluateValue()
is that the notes are discarded (unlike e.g. checkForConstantInitialization()
which Clang seems to use to actually surface the notes to the user). That seems like a good conservative default here (i.e. if the value doesn't constant fold, we silently fall back to importing as an external declaration)?
lib/ClangImporter/ImportDecl.cpp
Outdated
decl->getType(), ImportTypeKind::Value, | ||
ImportDiagnosticAdder(Impl, decl, decl->getLocation()), | ||
isInSystemModule(dc), Bridgeability::None, ImportTypeAttrs()); | ||
result = synthesizer.createConstant( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a test case where an __attribute__((swift_name))
is used to import one of these constants as a member of, say, a struct? I don't think createConstant()
is currently being used for anything that can have import-as-member applied to it, and although I don't see any reason why it wouldn't work, I'd like to be certain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added.
static const bool static_const_bool = true; | ||
static const char static_const_char = 42; | ||
static const long static_const_long = 42; | ||
static const float static_const_float = 42.0; | ||
static const double static_const_double = 42.0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some more edge cases it might be good to test:
- Literal uses, say,
ull
to specify a different type from the constant. (Trying to make sure we don't infer a type from the literal like we might in a macro.) - Literal is too big for the type of the constant it's being assigned to (e.g. a
char
initialized to500
). - Initializer refers to another constant which clang could potentially evaluate to find the value.
- Initializer refers to another constant which clang cannot evaluate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not that interesting, but I think it might be nice to test some C++-y things as well:
- Constexpr globals (that potentially are computed by constexpr functions)
- Constants in a namespace (as namespaces are imported as enums)
- Constants in class scope (static and non-static), even if we currently do not import them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 will add all these tests, I started gathering the list of TODOs in the PR description
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should now all be covered by tests.
@beccadax thanks for the awesome quick review, will add the coverage and find out the answers! :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would importing enum
constants already work as expected or does that need additional work to support constant evaluation in Swift?
lib/ClangImporter/ImportDecl.cpp
Outdated
decl->getType(), ImportTypeKind::Value, | ||
ImportDiagnosticAdder(Impl, decl, decl->getLocation()), | ||
isInSystemModule(dc), Bridgeability::None, ImportTypeAttrs()); | ||
result = synthesizer.createConstant( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see that we bail for static constexpr
variables above. I wonder if importing them as a constant would work for the supported types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not for static constexpr
, but for constexpr
that are imported as static, i.e. they are not top-level (in a namespace, or in a class). I quickly tried just removing this restriction, and some basic stuff imports fine, so I don't see a reason why we need this restriction.
That said, I'd like to leave this as a follow-up and a separate change, so that I can explore the consequences here a bit more. Maybe @beccadax has some background on why this restriction exists in the first place?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, this provides the reasoning: #60154
Though it's light on the details...
static const bool static_const_bool = true; | ||
static const char static_const_char = 42; | ||
static const long static_const_long = 42; | ||
static const float static_const_float = 42.0; | ||
static const double static_const_double = 42.0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe not that interesting, but I think it might be nice to test some C++-y things as well:
- Constexpr globals (that potentially are computed by constexpr functions)
- Constants in a namespace (as namespaces are imported as enums)
- Constants in class scope (static and non-static), even if we currently do not import them
Importing |
@swift-ci please test |
…swift + ClangImporter/const_values_cxx.swift
…adjust C++ lit tests
3dbc498
to
8e6071e
Compare
…s when importing const values
Macro-defined constants in C (
#define FOO 42
) get the concrete value imported (as a synthesized getter) into Swift. For global variables with initializer values (in bridging headers and in .h files in modules), we today only import them as external declarations. This PR starts importing the values of constant integer and floating-point global variables. Motivation is two-fold:@const
and constant-value evaluation (see [Compile Time Values] Add a new experimental feature and the parsing of the@const
attribute #79753, [Compile Time Values] Implement a mandatory SIL pass to verify '@const' values #79290 and https://forums.swift.org/t/pitch-3-swift-compile-time-values/77434), where it would be very useful to be able to use imported constants from C in Swift constant expressions.TODOs in this PR:
__attribute__((swift_name))
to import as a memberull
suffix)TODOs leaving as follow-up: