This removes the separate data files, which have been failing to load properly ([example](https://github.com/carbon-language/carbon-lang/runs/7957047892?check_suite_focus=true)). This one wasn't working previously, but hopefully will with these changes (and it might've also just been a pull_request_target issue, but the silent "Resource not accessible by integration" failures aren't great).
This is being done because Projects v1 requires repo write access, a serious limitation for letting people use it. Projects v2 isn't a great option because it lacks event support. Labels are pretty stable in GitHub, so this switches to that.
Note this assumes we're fine renaming "decision: accepted" -> "proposal accepted", etc. There are two reasons for this:
1) To make it clear that this is a proposal-specific label, versus something like an issue for leads label.
2) Removing the colon because it was causing trouble with yaml syntax.
This also adds the "proposal draft" label, mainly to complete the taxonomy.
I was considering whether this should be a proposal itself, but it feels like maybe it's not necessary because it's a fairly low-key infrastructure change, and I'm not sure how much people were relying on the project board anyways.
I tested this in a personal repo, basically just poking at https://github.com/jonmeow/test/pull/2
Note, partly writing this down to make sure everyone's in agreement with what's written.
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Part of #1902Fixes#1904
Regarding #1904, using #access-requests because I've decided I feel weird using any other channel for this (including #proposal-prs-and-process)
Trying to do this without affecting too much. I think we've generally considered this to be part of "refactoring tools", since large-scale refactoring is assisted by automatic formatting, but formatting is visible enough that it's probably worth addressing directly.
Fixes https://github.com/carbon-language/carbon-lang/issues/1656
The most significant change here is that explorer now uses the chosen spelling
rather than the old `Bool` spelling. Also update a few documentation examples
and some skeletal design docs to use the chosen spelling.
The toolchain embeds the assumption that `clang` and `llvm-ar` are
adjacent, which may not be true on all host platforms. Moreover,
in #1842 and #1843, we test if Homebrow LLVM is in `PATH` by checking
that `llvm-ar` is adjacent to `clang` and if it isn't, we `fail()` the
build, even if `llvm-ar` *is* in `PATH`.
Instead, actually check `PATH` with `repository_ctx.which`. This however
necessitates the assumption that `llvm-ar` and other LLVM binutils
are adjacent, and subsequently that `clang` and `ld.lld` are adjacent.
It appears that we don't seem to always be using these tools, but we
should avoid embedding wrong assumptions regardless.
Update docs to reflect this change.
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>