The ModuleManager in Clang maintains a mapping from FileEntry nodes to
ModuleFile data. Because FileEntry nodes are unique'd by underlying
inode number, an attacker can craft a collision by ensuring that two
different PCMs share an inode number.
This failure can be encountered with some regularity in a highly
concurrent compilation session on filesystems that use Orlov's Algorithm
to allocate inode numbers (like ext4 on Linux). Here, we use a much
simpler algorithm that forgets that PCMs have distinct inode numbers.
A future version of clang will increase the entropy of the key value to
take into account the mod time and size, which we also conveniently map
to 0 to throw it off our trail.
In the fast dependency scanner, depending on whether a module intrface was found via the import search path or framework search path, encode into the dependency graph Swift module details, whether a given module is a framework.
In order to make range-shifting for semantic highlighting testable,
disable returning semantic information during an "open" request. This
has no real value anyway, since it only happens very rarely, and it
makes testing range shifting impossible to do deterministically.
rdar://problem/66386179
If a semantic update finishes fast enough, the token snapshot may be
identical to the edit snapshot, but because of getBufferForSnapshot
consolidating edits into a new buffer, we were not detecting that case
properly, and it could cause an assertion failure (or potentially
incorrect range shifting in a release build). This would have reproduced
very rarely in practice, but I can reproduce it by putting `sleep(2)`
calls right before we read the semantic info in open and edit requests.
Incidentally, fix sourcekit-test and unit tests for the (rare) case
where an open or edit already has updated semantic info.
The goal of the test is to test the behaviour when the edit is
range-shifted, but in the (rare) case where the document update happens
before the edit finishes, we need the ranges to be the same. In
particular, using separate statements ensures that the tokens not
touched by the edit are not affected by the edit.
Re-enable the test disabled on ASan, since this seems to be the
underlying issue.
rdar://65934938
This started failing in one CI job that has asan, but it's unclear
whether there is a sanitizer issue or if it's a timing issue, etc.
Disabling while we investigate the root cause.
rdar://65934938
When performing an insertion (replacement length = 0) inside an existing
annotation, we were forming a closed range instead of a half-open range,
causing us to shift the effected token instead of throwing it out. There
were also no tests for this functionality, so add a bunch of annotations
tests.
One area thing that is not tested is what if there have been multiple
edits since the tokens were created. This is difficult to engineer,
because right now making an edit immediately removes the semantic tokens
and returns them. It could happen if the AST build takes longer than the
edits, but there is no way to guarantee that in the current API.
rdar://65748892
* More Python3 lint fixes
Some of the issues addressed include:
* Don't use `l` as a variable name (confusable with `1` or `I`)
* `print` statement does not exist in Py3, use `print` function instead
* Implicit tuple deconstruction in function args is no longer supported,
use explicit splat `*` at the call site instead
* `xrange` does not exist in Py3, use `range` instead
* Better name per review feedback
Since libDemangling is included in the Swift standard library,
ODR violations can occur on platforms that allow statically
linking stdlib if Swift code is linked with other compiler
libraries that also transitively pull in libDemangling, and if
the stdlib version and compiler version do not match exactly
(even down to commit drift between releases). This lets the
runtime conditionally segregate its copies of the libDemangling
symbols from those in the compiler using an inline namespace
without affecting usage throughout source.
There's no reason clients need to be able to access this data directly.
It obscures where module loading is actually happening, and makes it too
easy to accidentally register a module with the wrong identifier in the
context.
Hide the registration operations behind opaque accessors.
-enable-experimental-private-intransitive-dependencies -> -enable-direct-intramodule-dependencies
-disable-experimental-private-intransitive-dependencies -> -disable-direct-intramodule-dependencies
While we're here, rename DependencyCollector::Mode's constants and clean
up the documentation.
Currently when parsing a SourceFile, the parser
gets handed pointers so that it can write the
interface hash and collected tokens directly into
the file. It can also call `setSyntaxRoot` at
the end of parsing to set the syntax tree.
In preparation for the removal of
`performParseOnly`, this commit formalizes these
values as outputs of `ParseSourceFileRequest`,
ensuring that the file gets parsed when the
interface hash, collected tokens, or syntax tree
is queried.
Sink the `BuildSyntaxTree` and
`CollectParsedTokens` bits into
`SourceFile::ParsingFlags`, with a static method
to get the parsing options from the lang opts.
Also add a parsing flag for enabling the interface
hash, which can be used instead of calling
`enableInterfaceHash`.
`swiftDemangling` was built three times:
1. swiftc
2. swiftRuntime
3. swiftReflection
Fold the last two instances into a single build, sharing the objects
across both the target libraries. This ensures that `swiftDemangling`
is built with the same compiler as the target libraries and that the
target library build remains self-contained.
