Replace the "why we don't want to discuss things" question with three
questions covering substantially the same topic. Try to strike a balance
between inviting participation and feedback while still making it clear
that the evolution process produces "firm" decisions.
Address issue #1833.
> The only issue that I currently have with this one is that the `clangd` extension is having some hiccups, not being able to find includes like `<gmock/gmock.h>` and `<benchmark/benchmark.h>` and thus showing extra errors. However, this only affects the VSCode extension and bazel seems to work fine.
This might be an issue with the compilation database: you might try ./scripts/create_compdb.py to help.
This provides a natural place for questions about the specifics of how to
contribute effectively, which, near term, is probably where the FAQ will
grow the most near term. This allows the other headings to remain more
focused on their original questions.
Move two existing questions to the new place without changing their
content: "What are the prerequisites for contributing [...]?" and "Why
aren't people willing to discuss certain topics [...]?".
Fixes#1527
On Debian, the zlib1g-dev package is required to build and should be given as a requirement.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
We've observed the following things cropping up regularly enough to
address as 'frequently asked':
* Why isn't there a Carbon logo?
* Where should I ask questions?
* What are the prerequisites for building Carbon?
* Why aren't people willing to discuss certain topics?
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Older versions of GDB (before version 10.1) don't work with the
DWARF v5 debugging format the LLVM uses. The error message
which GDB shows when this happens is a bit misleading though.
Provide documentation about how to deal with that error message.
This is a proposal to make the Carbon experiment public.
We have not yet hit many of the originally suggested criteria for going
public. However, this proposal suggests that increasingly there is more
value to moving public sooner rather than waiting to hit these criteria.
We are increasingly unable to substantially learn more about the broader
interest in Carbon without it being public and we increasingly see value
in working with the industry to build and shape the language.
Given this, the proposal removes the old plan-of-record and suggests
a concrete set of steps to make the experiment public in the immediate
future.
This is not a change that we can make lightly to the project, and so we
worked to check with as many folks as we could first and all three
leads were unanimous to move forward here.
Note that this proposal was originally discussed in PR #1315.
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This proposal establishes a plan for moving away from the embedded copy
of LLVM and instead downloading it with Bazel.
The goal is that after this lands, we will do a history-rewrite to
cleanup the repository. There are instructions on how folks can move any
in-flight work over to the newly tidied repo.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Prior to this change, the section headings for the 7 main goals are visually indistinguishable (in GitHub's rendering) from the boldfaced paragraph headings in those sections. This makes the doc hard to navigate because the structure is hidden.
Some review feedback from outside the team directly working on Carbon suggested
two pretty significant updates here. First, we didn't do a good job of
motivating Carbon. This takes two parts, first explaining what we'd like to
accomplish with this approach generally, and second explaining why alternative
approaches don't work. A particularly difficult case here is articulating
effectively the difficulties that motivate an approach other than improving C++
incrementally.
Co-authored-by: Jon Meow <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
A rephrasing was suggested on https://github.com/carbon-language/carbon-lang/pull/1188#discussion_r851416370 because "explorer" alone could be hard to parse; I'm suggesting just replacing with "Carbon explorer" to get precision without changing phrasing, as well as rephrasing "Executable semantic" as "Carbon explorer" (which... the former *may* have meant "executable semantics", but the difference in pluralization made it vague, so I'm not sure this is right -- but it also didn't explain _where_, so "executable semantics" seems the right reading)
Co-authored-by: Geoff Romer <gromer@google.com>
Encourage reviewers to merge when they feel okay doing so. Let reviewers make
that choice. Let authors say they'll merge themselves.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Right now, the text is disallowing appeals to logic (which are persuasive methods, per the linked wikipedia article). Consensus seems to be that this is unintentional.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Given repeated concerns about C++ interop priorities: taking a pass at being more direct about priorities and tradeoffs.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Roadmap updates for 2022. Key goals:
* Reach the point where the first draft of the core language design is complete, with some test programs and an approximate implementation in executable semantics.
* Go public, and improve public participation.
Co-authored-by: Jon Meow <46229924+jonmeow@users.noreply.github.com>
This proposal addresses the question of whether we should perform a fully top-down compilation (like in C), a mostly top-down compilation (like in C++), or whether we should allow information from later in the same source file to be used in earlier program constructs (like in Rust, Swift, Java, C#, Haskell, and so on).
The proposed direction is:
- Entities declared later in the same source file cannot be used earlier; top-down semantics apply everywhere.
- As an exception, class member function bodies are parsed as if they appeared after the class.
- Forward declarations can be used to separate interface from implementation and to allow entities to be used before they are defined.
- The behavior of the program is nonetheless required to be the same as if we had a globally-consistent rule: it's always a hard error to depend on any information that is not known or that is provided later.
Moves common script logic into utils.py (not a great name, but couldn't come up with better). This is in particular to make the buildifier.py script really trivial, allowing that pre-commit to be easily added. However, scripts have also been diverging on how we find bazel, so I'm trying to unify that.
The advantage of reimplementing buildifier's pre-commit is that (a) we can now run buildifier server-side, and (b) we can stop advising installing it manually. Then the only Linux-specific package manager is Cargo, which is only used for watchman, which is optional -- so stop highlighting Linux-specific package managers in the tool instructions.
This is a proposal to adopt interfaces as the single static open extension mechanism for things like selecting how operators are implemented for types.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
This proposed style change allows C++ classes in the Carbon project to provide methods that are named like variables, so long as they behave like _properties_ of the class. It also requires data member names to have a trailing `_`.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Jon Ross-Perkins
Matt Armstrong
MarchMore
Vitalii
Vaishnavi JoshiandJon Ross-Perkins
yale
SADIK KUZU
Dan Sarginson
Joshua Peterson
CharlieS1103andJon Ross-Perkins
Parisa KhaleghiandJon Ross-Perkins
Josh Soref
Wolfgang E SanyerandChandler Carruth
Arno Gourdol
mconst
Thomas Lively
Matt Godbolt
Laurent Le Brun
