Adds some notes about the required build flags for lldb to successfully
find the symbols on macOS debug builds. Also adds a recommended debugger
configuration for interactive debugging in VSCode on macOS.
---------
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Unlike in the toolchain, we have not been preferring LLVM facilities
over standard ones. Update the documentation to describe this and
provide some rationale.
This reflects changes from a number of approved proposals:
- #920 : concrete statements about orphan and overlap in Carbon
- #2138 : "generic" -> "checked generic", "template" -> "template
generic"
- #2188 : binding patterns are forbidden in type position
- #2360 : "type", "facet type", "facet". Note: I am not using the term
"generic type" from #2360 since that meaning conflicts with the
generally accepted meaning of "generic type" of a type with a
compile-time parameter.
- #2760 / #2770 : internal/external impl -> extending impl
- #2964 : "symbolic constant" and "template constant"
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
You need bazel version 6.0.0 (with --host_per_file_copt) to build
carbon. This adds versioning info and adds that Linux, Mac and Windows
can use bazelisk.
---------
Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
The Carbon Project relied on the three leads to handle conduct concerns initially as it bootstrapped its community team and expertise. We now have an active and effective community lead and team of moderators. Our community lead has worked to train and ramp up a new and independent conduct team.
This proposal both provides an overview of the process and hands off conduct handling to the new team! Going forward, we expect routine updates to the conduct team to happen without full proposals as they allow trained folks to rotate in and out of this difficult but essential role on the project.
Last but not least, making these changes uncovered a restriction in the Code of
Conduct itself that we expect to be problematic to adhere to going forward.
While well intentioned, it has a bunch of unanticipated effects that made both
current and new conduct teams want to remove it. A related section has had its
wording strengthened to try and address the underlying motivation at least
partially.
Most of this content comes from @CelineausBerlin with some additions and edits from myself and the other leads as we worked toward building the new CoC team.
Co-authored-by: Céline Dedaj <CelineausBerlin@users.noreply.github.com>
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Kate Gregory <kate@Gregcons.com>
Provide a clear definition of our goals for the 0.1 Carbon language, and a
concrete feature-set that is expected to satisfy these goals.
The high level goal proposed for the 0.1 language is to reach an evaluation-MVP
(Minimal Viable Product): it should be sufficiently complete to evaluate its
suitability specifically with respect to fitness as a C++ successor language.
The features proposed for 0.1 language in turn focus on C++ interoperability and
a minimal subset of foundational aspects of the language.
Beyond the language itself, the other project features and milestones proposed
focus on enabling evaluation of the language design and interoperating with C++
in practice.
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
Co-authored-by: jonmeow <jperkins@google.com>
Co-authored-by: josh11b <josh11b@users.noreply.github.com>
Use the keyword `impls` instead of `is` when writing a `where` constraint that a type variable needs to implement an interface or named constraint.
What was previously (provisionally) written:
```
fn Sort[T:! Container where .ElementType is Ordered](x: T*);
```
will now be written:
```
fn Sort[T:! Container where .ElementType impls Ordered](x: T*);
```
---------
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Previous phrasing was unclear, because "language work" sounds like it means language _design_ work.
Co-authored-by: Chandler Carruth <chandlerc@gmail.com>
Ubuntu 22.04 base image and examples using github, a copy instruction and volumes.
I was using this to run examples on a windows machine since it is more comfortable than switching OS or using the WSL subsystem directly.
If this is something that other people would like to have I can add other versions of ubuntu and other linux distributions.
Mostly wanted to more clearly separate the closing observations from the
rest of the report. Noticed the missing link while I was there so fixing
that too.
Provides a documented cadence, publishing target, and template for Code of Conduct and moderation transparency reports.
Based on the initial proposal draft from @CelineausBerlin.
Co-authored-by: Céline Dedaj <CelineausBerlin@users.noreply.github.com>
Key rewrite points:
- Making more use of apt now, since we no longer need `brew` for llvm on Linux.
- Gets ahead of issues with brew's llvm 15 on Linux.
- Clear list of commands for a typical setup.
- Less verbose text about various tool options (I think this was just too much).
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
chandlerc had originally added these and previously expressed being okay with removing them. They've just proven too complex to be applied; it needs to be easier for people to want to do it.
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>
Lucile Rose NihlenandChandler Carruth
Richard Smith
Samiur KhanandJon Ross-Perkins
Adrien Leravatandjonmeow
Avi levy
Nico Z
Enzo Venturi
Dennis Onyeka
Asmi AgarwalandJon Ross-Perkins
Krishna Agarwal
cabmeurer
3405691582
Matt Armstrong
MarchMore
Vitalii
Vaishnavi JoshiandJon Ross-Perkins
yale
SADIK KUZU
Dan Sarginson
Joshua Peterson