mirror of
https://github.com/carbon-language/carbon-lang.git
synced 2026-09-24 22:02:23 +01:00
Chandler CarruthandJon Meow
3995fc2d6c
The only change here is to update the fuzzer build extension path. The main original commit message: > Add an initial lexer. (#17) > > The specific logic here hasn't been updated to track the latest > discussed changes, much less implement many aspects of things like > Unicode support. > > However, this should lay out a reasonable framework and set of APIs. > It gives an idea of the overall lexer architecture being proposed. The > actual lexing algorithm is a relatively boring and naive hand written > loop. It may make sense to replace this with something generated or > other more advanced approach in the future, getting the implementation > right was not the primary goal here. Instead, the focus was entirely > on the architecture, encapsulation, APIs, and the testing > infrastructure. > > The architecture of the lexer differs from "classical" high > performance lexers in compilers. A high level summary: > > - It is eager rather than lazy, lexing an entire file. > - Tokens intrinsically know their source location. > - Grouping lexical symbols are tracked within the lexer. > - Indentation is tracked within the lexer. > > Tracking of grouping and indentation is intended to simplify the > strategies used for recovery of mismatched grouping tokens, and > eventually use indentation. > > Folding source location into the token itself simplifies the data > structures significantly, and doesn't lose any fidelity due to the > absence of a preprocessor with token pasting. > > The fact that this is an eager lexer instead of a lazy lexer is > designed to simplify the implementation and testing of the lexer (and > subsequent components). There is no reason to expect Carbon to lex so > many tokens that there are significant locality advantages of lazy > lexing. Moreover, if we want comparable performance benefits, I think > pipelining is a much more promising architecture than laziness. For > now, the simplicity is a huge win. > > Being eager also makes it easy for us to use extremely dense memory > encodings for the information about lexed tokens. Everything is > created in a dense array, and small indices are used to identify each > token within the array. > > There is a fuzzer included here that we have run extensively over the > code, but currently toolchain bugs and Bazel limitations prevent it > from easily building. I'm hoping myself or someone else can push on > this soon and enable the fuzzer to at least build if not run fuzz > tests automatically. We have a significant fuzzing corpus that I'll > add in a subsequent commit as well. This also includes the fuzzer whose commit message was: > Add fuzz testing infrastructure and the lexer's fuzzer. (#21) > > This adds a fairly simple `cc_fuzz_test` macro that is specialized for > working with LLVM's LibFuzzer. In addition to building the fuzzer > binary with the toolchain's `fuzzer` feature, it also sets up the test > execution to pass the corpus as file arguments which is a simple > mechanism to enable regression testing against the fuzz corpus. > > I've included an initial fuzzer corpus as well. To run the fuzzer in > an open ended fashion, and build up a larger corpus: > ```shell > mkdir /tmp/new_corpus > cp lexer/fuzzer_corpus/* /tmp/new_corpus > ./bazel-bin/lexer/tokenized_buffer_fuzzer /tmp/new_corpus > ``` > > You can parallelize the fuzzer by adding `-jobs=N` for N threads. For > more details about running fuzzers, see the documentation: > http://llvm.org/docs/LibFuzzer.html > > To minimize and merge any interesting new inputs: > ```shell > ./bazel-bin/lexer/tokenized_buffer_fuzzer -merge=1 \ > lexer/fuzzer_corpus /tmp/new_corpus > ``` Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
61 lines
2.0 KiB
C++
61 lines
2.0 KiB
C++
// Part of the Carbon Language project, under the Apache License v2.0 with LLVM
|
|
// Exceptions. See /LICENSE for license information.
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
#include <cstring>
|
|
|
|
#include "diagnostics/diagnostic_emitter.h"
|
|
#include "lexer/tokenized_buffer.h"
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
namespace Carbon {
|
|
|
|
extern "C" int LLVMFuzzerTestOneInput(const unsigned char* data, size_t size) {
|
|
// We need two bytes of data to compute a file name length.
|
|
if (size < 2)
|
|
return 0;
|
|
unsigned short raw_filename_length;
|
|
std::memcpy(&raw_filename_length, data, 2);
|
|
data += 2;
|
|
size -= 2;
|
|
size_t filename_length = raw_filename_length;
|
|
|
|
// We need enough data to populate this filename length.
|
|
if (size < filename_length)
|
|
return 0;
|
|
llvm::StringRef filename(reinterpret_cast<const char*>(data),
|
|
filename_length);
|
|
data += filename_length;
|
|
size -= filename_length;
|
|
|
|
// The rest of the data is the source text.
|
|
auto source = SourceBuffer::CreateFromText(
|
|
llvm::StringRef(reinterpret_cast<const char*>(data), size), filename);
|
|
|
|
// Use a real diagnostic emitter to get lazy codepaths to execute.
|
|
DiagnosticEmitter emitter = NullDiagnosticEmitter();
|
|
|
|
auto buffer = TokenizedBuffer::Lex(source, emitter);
|
|
if (buffer.HasErrors())
|
|
return 0;
|
|
|
|
// Walk the lexed and tokenized buffer to ensure it isn't corrupt in some way.
|
|
//
|
|
// TODO: We should enhance this to do more sanity checks on the resulting
|
|
// token stream.
|
|
for (TokenizedBuffer::Token token : buffer.Tokens()) {
|
|
int line_number = buffer.GetLineNumber(token);
|
|
(void)line_number;
|
|
assert(line_number > 0 && "Invalid line number!");
|
|
assert(line_number < INT_MAX && "Invalid line number!");
|
|
int column_number = buffer.GetColumnNumber(token);
|
|
(void)column_number;
|
|
assert(column_number > 0 && "Invalid line number!");
|
|
assert(column_number < INT_MAX && "Invalid line number!");
|
|
}
|
|
|
|
return 0;
|
|
}
|
|
|
|
} // namespace Carbon
|