1) toolchain and explorer use the same working dir logic, share it
2) explorer's carbon.cpp and main_bin.cpp use the same relative path logic, share it
3) You can append a longer path in one call with the right kind of iterator
4) Fix what's maybe a bug in passing `relative_prelude_path.str()` to `cl::init`
5) Collapse Main and ExplorerMain to avoid passing more parameters between
The only usage of this set is to include this list in trace output when
tracing type-checking of patterns. But that in turn seems arbitrary and
not useful.
Previously explorer worked under `bazel run` but not when run directly, because it was finding the prelude relative to the current working directory. Now it looks for it relative to the location of the binary, so it works both when run directly and when run with `bazel run`.
Instead of forming a `SymbolicWitness` that contains an `Expression` when we can't directly resolve a witness to an `impl`, form different kinds of `Witness` values for the various situations:
- A `BindingWitness` witnesses that a type implements a constraint by reference to an `ImplBinding`.
- A `ConstraintWitness` witnesses that a type implements a constraint by reference to witnesses for each of the impl constraints within the constraint.
- A `ConstraintImplWitness` witnesses that a type implements a constraint by reference to a larger constraint which contains that constraint as an impl constraint.
Remove `SymbolicWitness` values and `InstantiateImpl` expressions, which are now unused. In order to remove the final usage of `SymbolicWitness`, I fixed a TODO to give `Self` the proper type within an interface declaration. I don't think this is an observable change.
No functional change intended.
Previously we used an expression in some places and a `Witness` values in others. The eventual goal is to make `Witness` values behave like other symbolic values such as `NominalClassType`, but the first step is to consistently treat them like values rather than expressions.
No functionality change intended.
This builds on semantics-ir lit support added by #2222
The googletest setup was feeling cumbersome, especially as I'm thinking about how to add more testing: I feel like I'm wrestling with the infrastructure.
The `[[ID1]]` and so on in tests is one advantage of switching: it's easier to do matching of IDs for verification. This is also more agnostic about the numbers than before, something which I'm concerned will be important as I think about builtins.
To explain my builtins thought, I think that needs to be another SemanticsIR with basically names pointing at builtin things. But this (a) creates multiple SemanticsIRs, which would confuse the current singleton approach and (b) starts creating more fluctuation for IDs, potentially impacting the numbers used (also, chandlerc's suggested pointers for some use-cases).
Overall it felt like I was heading towards a situation with googletest where writing the tests would be really difficult, and it was adding to my hesitance to write more code in the toolchain. I'm hoping this acts as a simplification.
Note, the "cp" commit has some incremental changes to googletest that I'd considered for making it easier to add matchers, but ultimately I ended up with this outcome.
run_clang_tidy.py (the clang-tools-extras version) is parallel so should be feasible to work with. I'm trying to codify this mainly because finding out the right invocation can be difficult.
This fixes some loading of re2 and proto that's started to become an issue.
It's hard to see actual issues because of the identifier length warning being turned off in #2244, and just general issue creep. There may be more fixes to do but this should still be an improvement.
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>
The config.yaml doesn't seem to be getting seen. Judging by https://github.com/carbon-language/carbon-lang/tree/trunk/.github/ISSUE_TEMPLATE ("Customize the issue creation experience with a config.yml file.") I think yaml is allowed for a lot of things (including the templates) but not config.yml.
I'm renaming other files for consistency.
This unifies `dump-tokens` and `dump-parse-tree` so that we don't keep writing basically the same code repeatedly.
I'll need to modify the output of SemanticsIR::Print more, and may soon unify printing multiple IRs this way (particularly including the builtins SemanticsIR) but this is intended to offer a starting point.
I may eventually try to unify lit.cfg.py files, but I was thinking about whether that works in various contexts we may run in and eventually decided copying the driver/testdata/lit.cfg.py file would be the easiest solution.
Dashes in bazel package names in particular can cause problems (which renaming `llvm-patches` to `llvm_patches` will fix for me). But we've generally named files with underscores, so there's also consistency.
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 proposal specifies how unused pattern bindings are written in the Carbon programming language. This is a more general problem statement of "how do users specify unused function parameters" as function parameter declarations are a more specific form of pattern
Related issue #1996
Co-authored-by: Geoff Romer <gromer@google.com>
Co-authored-by: Richard Smith <richard@metafoo.co.uk>
We've been having issues with asan builds on linux. This change should fix all of that. A build run can be found at:
https://github.com/carbon-language/carbon-lang/actions/runs/3093378863/jobs/5005683059
(currently in progress, but I'm expecting it to succeed at this point)
It may be that the issues with asan builds were actually related to caching. That is, maybe the brew build command didn't change enough between v14 and v15 that the cache hits were still an issue. We did notice this with 15.0.0 versus 15.0.1 include paths (that is, bazel wasn't happy using the cached results of a 15.0.0 build due to the skew in include paths). In order to address this, I've added CACHE_VERSION to the remote_cache setup. I've also set up corresponding buckets in Cloud.
However, I'm also switching Linux to llvm-15 and apt. I'd originally been looking at this because the issues were linux-specific, and we've previously had linux-specific issues with Homebrew. Although it may have been the cache all along, I would prefer to keep this setup (if nothing else, it made the caching issues more obvious, even though we were still confused by the include path manifestation).
* Multiplication and division have the same priority.
* A new builtin interface DivWith is added.
* In some tests expecting a compilation error (syntax error), the error
message now says it is expecting SLASH or binary *.
Jon Ross-Perkins
Richard Smith
Geoff Romer
Kareem Ergawyandergawy
Adrien Leravat
josh11bandBarry Revzin
pmqtt
micttyl
Junhee Cho