Skip to content

Commit 2843e0c

Browse files
committed
Gardening: Migrate compiler sources to GitHub issues
1 parent 0a9b558 commit 2843e0c

32 files changed

+69
-79
lines changed

lib/CMakeLists.txt

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,9 @@
22
# Swift's libraries all build after the LLVM & Clang tablegen-generated headers
33
# are generated. When building out-of-tree (as with build-script) LLVM & Clang's
44
# CMake configuration files create these targets as dummies so we can safely
5-
# depend on them directly here (See: SR-6026)
5+
# depend on them directly here.
6+
# See https://github.com/apple/swift/issues/48583.
7+
#
68
# LLVM_COMMON_DEPENDS is a construct from the LLVM build system. It is a special
79
# purpose variable that provides common dependencies for all libraries, and
810
# executables generated when it is set. CMake's scoping rules enforce that these

lib/ClangImporter/ClangImporter.cpp

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3125,7 +3125,7 @@ class VectorDeclPtrConsumer : public swift::VisibleDeclConsumer {
31253125
};
31263126
} // unnamed namespace
31273127

3128-
// FIXME: should submodules still be crawled for the symbol graph? (SR-15753)
3128+
// FIXME(https://github.com/apple/swift-docc/issues/190): Should submodules still be crawled for the symbol graph?
31293129
bool ClangModuleUnit::shouldCollectDisplayDecls() const { return isTopLevel(); }
31303130

31313131
void ClangModuleUnit::getTopLevelDecls(SmallVectorImpl<Decl*> &results) const {

lib/ClangImporter/ImportDecl.cpp

Lines changed: 3 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -2002,7 +2002,7 @@ namespace {
20022002
return nullptr;
20032003
}
20042004

2005-
// TODO(SR-13809): fix this once we support dependent types.
2005+
// TODO(https://github.com/apple/swift/issues/56206): Fix this once we support dependent types.
20062006
if (decl->getTypeForDecl()->isDependentType()) {
20072007
Impl.addImportDiagnostic(
20082008
decl, Diagnostic(
@@ -3006,8 +3006,7 @@ namespace {
30063006

30073007
auto templateParamTypeUsedInSignature =
30083008
[decl](clang::TemplateTypeParmDecl *type) -> bool {
3009-
// TODO(SR-13809): we will want to update this to handle dependent
3010-
// types when those are supported.
3009+
// TODO(https://github.com/apple/swift/issues/56206): We will want to update this to handle dependent types when those are supported.
30113010
if (hasSameUnderlyingType(decl->getReturnType().getTypePtr(), type))
30123011
return true;
30133012

@@ -3038,8 +3037,7 @@ namespace {
30383037
//
30393038
// If the defaulted template type parameter is used in the signature,
30403039
// then still add a generic so that it can be overrieded.
3041-
// TODO(SR-14837): in the future we might want to import two overloads
3042-
// in this case so that the default type could still be used.
3040+
// TODO(https://github.com/apple/swift/issues/57184): In the future we might want to import two overloads in this case so that the default type could still be used.
30433041
if (templateTypeParam->hasDefaultArgument() &&
30443042
!templateParamTypeUsedInSignature(templateTypeParam))
30453043
continue;

lib/ClangImporter/ImportMacro.cpp

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -405,7 +405,7 @@ static ValueDecl *importMacro(ClangImporter::Implementation &impl,
405405
tokenI[2].is(clang::tok::r_paren)) {
406406
if (!castType.isNull()) {
407407
// this is a nested cast
408-
// TODO(SR-15429): Diagnose nested cast
408+
// TODO(https://github.com/apple/swift/issues/57735): Diagnose nested cast.
409409
return nullptr;
410410
}
411411

@@ -428,11 +428,11 @@ static ValueDecl *importMacro(ClangImporter::Implementation &impl,
428428
if (parsedType && diagPool.empty()) {
429429
castType = parsedType.get();
430430
} else {
431-
// TODO(SR-15429): Add diagnosis
431+
// TODO(https://github.com/apple/swift/issues/57735): Add diagnosis.
432432
return nullptr;
433433
}
434434
if (!castType->isBuiltinType() && !castTypeIsId) {
435-
// TODO(SR-15429): Add diagnosis
435+
// TODO(https://github.com/apple/swift/issues/57735): Add diagnosis.
436436
return nullptr;
437437
}
438438
} else {
@@ -441,7 +441,7 @@ static ValueDecl *importMacro(ClangImporter::Implementation &impl,
441441
if (builtinType) {
442442
castType = builtinType.getValue();
443443
} else {
444-
// TODO(SR-15429): Add diagnosis
444+
// TODO(https://github.com/apple/swift/issues/57735): Add diagnosis.
445445
return nullptr;
446446
}
447447
}
@@ -499,8 +499,7 @@ static ValueDecl *importMacro(ClangImporter::Implementation &impl,
499499
// FIXME: If the identifier refers to a declaration, alias it?
500500
}
501501

502-
// TODO(SR-15429): Seems rare to have a single token that is neither a
503-
// literal nor an identifier, but add diagnosis
502+
// TODO(https://github.com/apple/swift/issues/57735): Seems rare to have a single token that is neither a literal nor an identifier, but add diagnosis.
504503
return nullptr;
505504
}
506505
case 2: {

lib/ClangImporter/ImportType.cpp

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -227,7 +227,7 @@ namespace {
227227

228228
ImportResult VisitType(const Type*) = delete;
229229

230-
// TODO: Add support for dependent types (SR-13809).
230+
// TODO(https://github.com/apple/swift/issues/56206): Add support for dependent types.
231231
#define DEPENDENT_TYPE(Class, Base) \
232232
ImportResult Visit##Class##Type(const clang::Class##Type *) { return Impl.SwiftContext.getAnyExistentialType(); }
233233
#define TYPE(Class, Base)
@@ -697,10 +697,9 @@ namespace {
697697
if (!swiftParamTy)
698698
return Type();
699699

700-
// FIXME: If we were walking TypeLocs, we could actually get parameter
701-
// names. The probably doesn't matter outside of a FuncDecl, which
702-
// we'll have to special-case, but it's an interesting bit of data loss.
703-
// <https://bugs.swift.org/browse/SR-2529>
700+
// FIXME(https://github.com/apple/swift/issues/45134): If we were walking TypeLocs, we could actually get parameter names.
701+
// The probably doesn't matter outside of a FuncDecl, which we'll have
702+
// to special-case, but it's an interesting bit of data loss.
704703
params.push_back(FunctionType::Param(swiftParamTy));
705704
}
706705

@@ -2446,7 +2445,7 @@ ParameterList *ClangImporter::Implementation::importFunctionParameterList(
24462445
bool shouldCheckResultType) -> bool {
24472446
auto paramDecl = genericParam->getClangDecl();
24482447
auto templateTypeParam = cast<clang::TemplateTypeParmDecl>(paramDecl);
2449-
// TODO(SR-13809): This won't work when we support importing dependent types.
2448+
// TODO(https://github.com/apple/swift/issues/56206): This won't work when we support importing dependent types.
24502449
// We'll have to change this logic to traverse the type tree of the imported
24512450
// Swift type (basically whatever ends up in the parameters variable).
24522451
// Check if genericParam's corresponding clang template type is used by

lib/Driver/DarwinToolChains.cpp

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -466,10 +466,11 @@ toolchains::Darwin::addArgsToLinkStdlib(ArgStringList &Arguments,
466466
// If the user has explicitly asked for a toolchain stdlib, we should
467467
// provide one using -rpath. This used to be the default behaviour but it
468468
// was considered annoying in at least the SwiftPM scenario (see
469-
// https://bugs.swift.org/browse/SR-1967) and is obsolete in all scenarios
470-
// of deploying for Swift-in-the-OS. We keep it here as an optional
471-
// behaviour so that people downloading snapshot toolchains for testing new
472-
// stdlibs will be able to link to the stdlib bundled in that toolchain.
469+
// https://github.com/apple/swift/issues/44576) and is obsolete in all
470+
// scenarios of deploying for Swift-in-the-OS. We keep it here as an
471+
// optional behaviour so that people downloading snapshot toolchains for
472+
// testing new stdlibs will be able to link to the stdlib bundled in
473+
// that toolchain.
473474
for (auto path : RuntimeLibPaths) {
474475
Arguments.push_back("-rpath");
475476
Arguments.push_back(context.Args.MakeArgString(path));

lib/Driver/Driver.cpp

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2391,7 +2391,7 @@ bool Driver::handleImmediateArgs(const ArgList &Args, const ToolChain &TC) {
23912391

23922392
std::string executable = getSwiftProgramPath();
23932393

2394-
// FIXME: This bypasses mechanisms like -v and -###. (SR-12119)
2394+
// FIXME(https://github.com/apple/swift/issues/54554): This bypasses mechanisms like -v and -###.
23952395
sys::TaskQueue queue;
23962396
queue.addTask(executable.c_str(), commandLine);
23972397
queue.execute(nullptr,

lib/Frontend/ModuleInterfaceSupport.cpp

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -81,7 +81,7 @@ llvm::Regex swift::getSwiftInterfaceCompilerVersionRegex() {
8181
": (.+)$", llvm::Regex::Newline);
8282
}
8383

84-
// MARK: Module name shadowing warnings (SR-898)
84+
// MARK(https://github.com/apple/swift/issues/43510): Module name shadowing warnings
8585
//
8686
// When swiftc emits a module interface, it qualifies most types with their
8787
// module name. This usually makes the interface less ambiguous, but if a type

lib/FrontendTool/FrontendTool.cpp

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2276,8 +2276,8 @@ int swift::performFrontend(ArrayRef<const char *> Args,
22762276
// diagnostics emitted above, within CompilerInvocation::parseArgs, are never
22772277
// serialized. This is a non-issue because, in nearly all cases, frontend
22782278
// arguments are generated by the driver, not directly by a user. The driver
2279-
// is responsible for emitting diagnostics for its own errors. See SR-2683
2280-
// for details.
2279+
// is responsible for emitting diagnostics for its own errors.
2280+
// See https://github.com/apple/swift/issues/45288 for details.
22812281
std::unique_ptr<DiagnosticConsumer> SerializedConsumerDispatcher =
22822282
createSerializedDiagnosticConsumerIfNeeded(
22832283
Invocation.getFrontendOptions().InputsAndOutputs);

lib/FrontendTool/LoadedModuleTrace.cpp

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -169,8 +169,7 @@ class ABIDependencyEvaluator {
169169

170170
/// Check if a Swift module is an overlay for some Clang module.
171171
///
172-
/// FIXME: Delete this hack once SR-13363 is fixed and ModuleDecl has the
173-
/// right API which we can use directly.
172+
/// FIXME: Delete this hack once https://github.com/apple/swift/issues/55804 is fixed and ModuleDecl has the right API which we can use directly.
174173
bool isOverlayOfClangModule(ModuleDecl *swiftModule);
175174

176175
/// Check for cases where we have a fake cycle through an overlay.

0 commit comments

Comments
 (0)