-
Notifications
You must be signed in to change notification settings - Fork 341
Fix rdar://64538073 #3099
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
Fix rdar://64538073 #3099
Conversation
The new patch requires users to create a source file and pass the file name to the command line. I made this change since I wasn't able to find a clean way to teach the driver to process the arguments and create the correct CC1 invocations without passing a source file. |
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 new patch requires users to create a source file and pass the file name to the command line. I made this change since I wasn't able to find a clean way to teach the driver to process the arguments and create the correct CC1 invocations without passing a source file.
This sounds like we're exposing an implementation detail to the clients and forcing them to work around it. Would it be possible to create the file internally in the dependency scanner? (Probably just in an in-memory VFS.)
The contents of the file don't play any role when scanning dependencies by module name, is that correct?
* but get the dependencies by module name alone. | ||
*/ | ||
CINDEX_LINKAGE CXFileDependencies * | ||
clang_experimental_DependencyScannerWorkerByModName_getFileDependencies_v0( |
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.
Since this now doesn't require a special worker, I think clang_experimental_DependencyScannerWorker_getModuleDependencies_v0
would be a clearer name. WDYT?
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.
It's not clear to me whether the function name should end with getFileDependencies_v0
or getModuleDependencies_v0
. The return type CXFileDependencies
contains both FileDeps
and ModuleDeps
, so it seems to me that a name ending with getFileAndModuleDependencies_v0
would be more accurate, but the two functions declared above this one both use getFileDependencies
.
clang/include/clang-c/Dependencies.h
Outdated
clang_experimental_DependencyScannerWorkerByModName_getFileDependencies_v0( | ||
CXDependencyScannerWorker Worker, int argc, const char *const *argv, | ||
const char *WorkingDirectory, CXModuleDiscoveredCallback *MDC, | ||
void *Context, CXString *error, const char *LookedUpModuleName); |
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.
Just ModuleName
might be clearer. Maybe this should be moved after the argv
parameter, since those are the main inputs to the function.
@@ -45,6 +45,14 @@ class ReadPCHAndPreprocessAction : public FrontendAction { | |||
bool usesPreprocessorOnly() const override { return false; } | |||
}; | |||
|
|||
class ReadPCHAndPreprocessByModNameAction : public ReadPCHAndPreprocessAction { |
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.
Does this need to inherit from ReadPCHAndPreprocessAction
? I think PreprocessorFrontendAction
should be just fine, since precompiled headers don't affect dependencies of a module.
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 it be incorrect to inherit from PreprocessOnlyAction
instead?
// | ||
// RUN: echo %t.dir > %t.result | ||
// RUN: clang-scan-deps -compilation-database %t.cdb -j 4 -format experimental-full \ | ||
// RUN: -generate-modules-path-args -module-files-dir %t.dir/custom \ |
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 -generate-modules-path-args
and -module-files-dir
options are orthogonal to whether we're scanning dependencies of a module by its name or a TU by its source file. You can simplify this test by removing the code testing these.
You need to land it on |
collection Fixes PR51210.
This patch adds the -fminimize-whitespace with the following effects: * If combined with -E, remove as much non-line-breaking whitespace as possible. * If combined with -E -P, removes as much whitespace as possible, including line-breaks. The motivation is to reduce the amount of insignificant changes in the preprocessed output with source files where only whitespace has been changed (add/remove comments, clang-format, etc.) which is in particular useful with ccache. A patch for ccache for using this flag has been proposed to ccache as well: ccache/ccache#815, which will use -fnormalize-whitespace when clang-13 has been detected, and additionally uses -P in "unify_mode". ccache already had a unify_mode in an older version which was removed because of problems that using the preprocessor itself does not have (such that the custom tokenizer did not recognize C++11 raw strings). This patch slightly reorganizes which part is responsible for adding newlines that are required for semantics. It is now either startNewLineIfNeeded() or MoveToLine() but never both; this avoids the ShouldUpdateCurrentLine workaround and avoids redundant lines being inserted in some cases. It also fixes a mandatory newline not inserted after a _Pragma("...") that is expanded into a #pragma. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D104601
…f hasTrait<ReturnLike>. This CL adds a new RegionBranchTerminatorOpInterface to query information about operands that can be passed to successor regions. Similar to the BranchOpInterface, it allows to freely define the involved operands. However, in contrast to the BranchOpInterface, it expects an additional region number to distinguish between various use cases which might require different operands passed to different regions. Moreover, we added new utility functions (namely getMutableRegionBranchSuccessorOperands and getRegionBranchSuccessorOperands) to query (mutable) operand ranges for operations equiped with the ReturnLike trait and/or implementing the newly added interface. This simplifies reasoning about terminators in the scope of the nested regions. We also adjusted the SCF.ConditionOp to benefit from the newly added capabilities. Differential Revision: https://reviews.llvm.org/D105018
…orm. This allows ORC to execute code containing Objective-C and Swift classes and methods (provided that the language runtime is loaded into the executor).
Add 'enconding' attribute visitor. Without it ASM printer doesn't use attribute aliases for 'enconding'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D105554
Suppress only current warning on openmp-clang-x86_64-linux-debian Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D106777
Default to building the amdgpu plugin to use dlopen when hsa is not found instead of disabling it. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D106600
…angler"" This reverts commit 2aa0cf1. Get rid of reference to the temporary.
This patch extends support for (scalable-vector) splats in the DAGCombiner via the `ISD::matchBinaryPredicate` function, which enable a variety of simple combines of constants. Users of this function may now have to distinguish between `BUILD_VECTOR` and `SPLAT_VECTOR` vector operands. The way of dealing with this in-tree follows the approach added for `ISD::matchUnaryPredicate` implemented in D94501. Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D106575
I have added a new FastMathFlags parameter to getArithmeticReductionCost to indicate what type of reduction we are performing: 1. Tree-wise. This is the typical fast-math reduction that involves continually splitting a vector up into halves and adding each half together until we get a scalar result. This is the default behaviour for integers, whereas for floating point we only do this if reassociation is allowed. 2. Ordered. This now allows us to estimate the cost of performing a strict vector reduction by treating it as a series of scalar operations in lane order. This is the case when FP reassociation is not permitted. For scalable vectors this is more difficult because at compile time we do not know how many lanes there are, and so we use the worst case maximum vscale value. I have also fixed getTypeBasedIntrinsicInstrCost to pass in the FastMathFlags, which meant fixing up some X86 tests where we always assumed the vector.reduce.fadd/mul intrinsics were 'fast'. New tests have been added here: Analysis/CostModel/AArch64/reduce-fadd.ll Analysis/CostModel/AArch64/sve-intrinsics.ll Transforms/LoopVectorize/AArch64/strict-fadd-cost.ll Transforms/LoopVectorize/AArch64/sve-strict-fadd-cost.ll Differential Revision: https://reviews.llvm.org/D105432
Reviewed By: tmatheson Differential Revision: https://reviews.llvm.org/D106635
Thanks to gAlfonso-bit for the patch! Differential Revision: https://reviews.llvm.org/D106691
- `scf.yield` in the "after" region supplies new arguments to the "before" region. Differential Revision: https://reviews.llvm.org/D106806
These are required by MemIsShadow for checking if an address actually is shadow memory. Differential Revision: https://reviews.llvm.org/D105745
Change SetCurrentThread*() logic not to include the zero padding in PID/TID that was a side effect of 02ef0f5. This should fix problems caused by sending 64-bit integers to 32-bit servers. Reported by Ted Woodward. Differential Revision: https://reviews.llvm.org/D106832
See llvm.org/pr51221
This is empty for now, but we will add a check that TBI is enabled once the tagged pointer ABI for zircon is finalized. This depends on D105667. Differential Revision: https://reviews.llvm.org/D105668
Ensure that libSupport does not carry any static global initializer. libSupport can be embedded in use cases where we don't want to load all cl::opt unless we want to parse the command line. ManagedStatic can be used to enable lazy-initialization of globals. The -Werror=global-constructors is only added on platform that have support for the flag and for which std::mutex does not have a global destructor. This is ensured by having CMake trying to compile a file with a global mutex before adding the flag to libSupport.
Allegedly the DWARF backend ignores this field of DIEnumerator, but we set it nonetheless in case we decide to use it in the future. Alternatively, we could remove it, but it is simpler to pass down the signed bit as it is in the AST for now. Implemented to address comments on D106585
Before MASSV only supported P8 and P9 on AIX ans Linux . This patch proposes MASSV to add support of P7 and P10 only on AIX too. Differential: https://reviews.llvm.org/D106678
This will just be a call into __sanitizer_fill_shadow defined in the fuchsia source tree. This depends on D105663. Differential Revision: https://reviews.llvm.org/D105664
Differential revision: https://reviews.llvm.org/D106494
…list of module and file dependencies of a module for a particular compiler invocation rdar://64538073
- Define a subclass of FrontendAction and call loadModule there. - Remove the API for creating a worker just for clang_experimental_DependencyScannerWorkerByModName_getFileDependencies_v1. - Add the capability to get the dependencies based on the module name to clang-scan-deps.
- Create a fake virtual source file instead of asking users to create one and pass it to the command line. - Remove the "translation-units" output from test case modules-full-by-mod-name.cpp. The information isn't useful as the source file name isn't passed on the command line in this case. - Inherit from `PreprocessOnlyAction`.
Hmm, I think rebasing onto |
No description provided.