Commit Graph
22 Commits
Author SHA1 Message Date
Manmeet Singh 72d8f86e79 fix: incorrect index in TypeEqual for ConstraintType (#2754)
Just a typo.

Closes #2727
2023-04-10 13:17:33 -07:00
josh11bandGeoff Romer 46503c0a9d Explorer and toolchain changes to implement #2483 (#2707)
This PR is making two main changes to the Explorer and Toolchain:
- Replace the `is` keyword in `where SomeType is SomeInterface` with `impls`, so it is `where SomeType impls SomeInterface`
- Rewrite uses of the "impls" to something else to avoid, frequently "`impl` declarations" or "implementations", to avoid confusion with the `impls` keyword.

---------

Co-authored-by: Geoff Romer <gromer@google.com>
2023-03-28 12:28:52 -07:00
Richard Smith 4daaa4866f Rename Type -> type, per #2360. (#2507)
Also make minor updates to the skeletal design in
docs/design/name_lookup.md following #2113, as there are no longer any prelude names that are made available to unqualified name lookup by default.

Add `type` to the keyword list in
docs/design/lexical_conventions/words.md, following #2360.
2023-01-04 14:22:30 -08:00
josh11b 9c8fd6864e Implement rename me -> self (#2444)
Implements change proposed in #1382

Replaces #1624
2022-12-06 20:17:00 -08:00
Richard Smith 9e8cacae00 Implement support for named constraints (#2359)
Basic support for named constraints as described in [the generics design](https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/generics/details.md#named-constraints). Support is provided for `extends` and `impl` declarations in `constraint`, but not yet for member aliases.

The missing prelude named constraints `Add`, `Mul`, `Ordered`, etc. are also added.
2022-11-04 16:23:02 -07:00
Richard Smith 0219218b01 Make type contexts expect a value of type Type. (#2357)
In particular, this means that a type can implement `ImplicitAs(Type)` and have values of that type behave like types.

This implies that `()` and `{}` are no longer types. They are now values whose type is the result of converting `()` or `{}` to type `Type`, as has been discussed recently and seems to be the supported direction. This fixes various cases where these types were previously mishandled.
2022-10-28 08:20:49 -07:00
Richard Smith adc78fbdb0 Defer resolving rewrites until we apply a constraint to a binding (#2333)
Instead of checking and resolving rewrites eagerly, defer doing so until a constraint is applied to a binding. Actual resolution of rewrites is not yet implemented, so this is mostly just refactoring, but the eventual goal is to support things like `(Constraint where .T = .U) & (Constraint where .U = V)` (however they are reached) by applying one rewrite to the other, as agreed with @josh11b in discussion of #2173.

One nice consequence is that substitution into a constraint type no longer has a failure path, so substitution is once again not able to fail.
2022-10-24 15:50:31 -07:00
Richard Smith 561e45033e Remove TypeOf*Type for types whose type-of-type can just be Type (#2302)
We don't seem to have any need for `TypeOf*Type` types, and having them introduces the temptation to use them during type-checking, which would lead to types having different behavior when their type-of-type is `Type` versus when it's a more precise type. Remove these types for now.

If we later decide that we want each type literal to have a unique type, as we do for value literals, we can introduce a single value kind for that rather than one for each kind of type.

No changes to `TypeOfMemberName`, `TypeOfParameterizedEntityName`, and `TypeOfMixinPseudoType`, which are placeholders, not real types.
2022-10-18 14:08:40 -07:00
Jon Ross-Perkins 3578f2b214 Fix AUTOUPDATE lines in new tests (#2306) 2022-10-18 11:26:30 -07:00
Richard Smith b4418e29ec Properly check that a constraint appears after is. (#2304)
In particular, if we find the name of an interface after `is`, it should
be exapnded to a constraint, including any implied constraints such as
extended interfaces, rather than forming a constraint requiring only
that interface in isolation.
2022-10-18 09:07:58 -07:00
Richard Smith fa18cc0f9f Fix test failures caused by interaction between #2294 and #2292. (#2303) 2022-10-18 08:53:12 -07:00
Richard Smith 4b679510e7 Check equality constraints when checking whether a constraint is satisfied (#2294)
Add checking that a type only satisfies a constraint if it satisfies all of that constraint's equality and rewrite constraints.

Enforce the rule that `=` must be used in impls when specifying associated constant values rather than `==`.

Turn off the pre-#2173 single-step equality behavior. This is getting somewhat ahead of the approved design, but it's a one-line change to restore the old behavior.

Fix `CARBON_CHECK` to handle top-level `,`s in its argument, such as may happen in template argument lists, as this change introduces such a check.
2022-10-17 22:07:19 -07:00
Jon Ross-Perkins eac7c2bda4 Automate the addition of RUN and simplify RUN lines (#2292)
This was an offshoot of the discussion about how much boilerplate we could remove. lit requires RUN lines be there, everything else is optional.
2022-10-17 13:52:37 -07:00
Jon Ross-Perkins e111418b32 Merge and label stdout/stderr for FileCheck (#2283)
Adds a simple script to merge stdout/stderr and put on labels. This is hidden to the RUN line using lit.cfg.py.

This is my solution to addressing how errors printed by the toolchain break sorting of stdout output; just put stdout first. We could also have toggles for interleaving output or such, which might help test whether we do it properly.

This also moves some previous-distributed replacement logic into lit_autoupdate_base.py: I think having that adjacent to lit.cfg.py is probably the better choice, and it reduces duplication in toolchain scripts. It happens here because I need to change the resulting commands to include the merge.
2022-10-13 14:46:30 -07:00
Richard Smith 9f534ae004 Implement support for rewrite constraints (#2276)
Implements basic support for rewrite constraints as proposed in #2173.

Support for associated constants and complex constraints in general is also made more robust: argument deduction now properly computes and substitutes witnesses, and interface declarations track a more correct description of the constraint that they introduce than the one we previously built.
2022-10-12 12:55:55 -07:00
Richard Smith 9feff92f22 Track witnesses wherever possible (#2263)
Change explorer's handling of witnesses to track them wherever possible. Associated constant support needs witnesses to be available much more pervasively.

The main changes here are:

-   `Substitute` now takes a set of bindings covering both `Value`s for `GenericBinding`s and `Witness`es for `ImplBinding`s, and substitutes both.
-   Witnesses are now tracked within `ConstraintType`s. The `.Self` type has an `ImplBinding` that self-references from parts of the constraint to other parts of the constraint can use to access the witness for the constraint.
-   The constraint type for an `impl` and for a `GenericBinding` are now stored in pre-substituted form, with references to the actual constrained type rather than symbolic references to `.Self`. This results in minor changes in diagnostic text.

Argument deduction still performs substitutions without remapping witnesses.
2022-10-11 15:20:23 -07:00
Jon Ross-Perkins b9d3d9a3df Unify lit.cfg.py approach (#2249)
On #2224 @zygoloid pointed out we needed --implicit-check-not to ensure we were correctly matching output. This is the standard way we're writing explorer tests, so I was looking at unifying our lit approaches.

This is one take on it, making more use of substitutions to bring various testing into alignment, as well as symlinks to avoid config skew (maybe I'll eventually figure out a better solution than symlinks).

Makes a couple small fixes in explorer to remove end-of-line whitespace on output.
2022-10-06 12:25:23 -07:00
Josh Soref 066b103881 Spelling (#1580)
This PR corrects misspellings identified by the [check-spelling action](https://github.com/marketplace/actions/check-spelling).

The misspellings have been reported at https://github.com/jsoref/carbon-lang/commit/38a1c1640151899fd6da0442a92557f9543b6280#commitcomment-79197316

The action reports that the changes in this PR would make it happy: https://github.com/jsoref/carbon-lang/commit/173c8f9083a68aa61f7cfe94f720f1e5dc7f1ea3

Note: this PR does not include the action. If you're interested in running a spell check on every PR and push, that can be offered separately.

Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2022-07-22 16:14:21 -07:00
Richard SmithandJon Ross-Perkins 663ed32b1b Initial support for associated constants (#1376)
Basic support for declaring, specifying the values of, and using associated constants.

This is incomplete in various ways. For example, when checking whether a type satisfies a constraint, there is no check that its associated constants match those in the constraint, and name lookup into a value whose type is an associated constant is not supported yet.

Co-authored-by: Jon Ross-Perkins <jperkins@google.com>
2022-07-14 18:18:27 -07:00
Richard Smith 2fef76e58c Basic support for .Self within :! bindings and where expressions. (#1311)
`.Self` is modeled as a new kind of expression, `DotSelfExpression`. Name resolution associates each occurrence of a `DotSelfExpression` with a generic binding, much like for an `IdentifierExpression`.

Both `:!` bindings and `where` expressions bring `.Self` into scope. The tentative intent is that if there are multiple `.Self`s in scope and they refer to different bindings, the result of using a `.Self` expression is an ambiguity error, but that is not implemented in this patch. Instead, like for `IdentifierExpression`s, we find the innermost enclosing definition of `.Self`.

`.Foo` expressions are rewritten to `.Self.Foo`, but this isn't enough to make them do anything useful, because associated constants aren't supported in general yet.
2022-06-14 21:49:01 -07:00
Richard Smith 9007b3952d Initial support for where expressions. (#1310)
Build constraint types from `where` expressions. This is very bare-bones; there's no support for constraining `.Self` or associated types yet, but degenerate cases not involving self-reference work.

`==` constraints are syntactically supported but not semantically verified yet, and they aren't used for anything.
2022-06-09 10:31:04 -07:00
Richard Smith 1bb370420b Initial support for constraints formed by combining interfaces (#1307)
Add scaffolding for constraints in general, and support specifically constraints formed by applying a `&` operator.

No support for constraints formed with `where` nor for named constraints at this point.
2022-06-07 13:59:23 -07:00