Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow compile time bindings where they aren't clearly supported. #4338

Merged
merged 5 commits into from
Sep 25, 2024

Conversation

jonmeow
Copy link
Contributor

@jonmeow jonmeow commented Sep 24, 2024

This is resolving a fuzz-discovered crash related to function suspends and compile time bind indices. Although the crash originally came from clearly invalid syntax (missing the = inside a class decl), the syntax with a value should also be valid but has the same crash.

This approach disallows compile-time bindings in contexts that can create ambiguous results, particularly class declarations. These are an issue because a suspended function can have let declarations after it. I'm allowing them in function bodies and interface scopes.

zygoloid

This comment was marked as resolved.

@jonmeow jonmeow changed the title Update the next compile time bind index during restore. Disallow compile time bindings where they aren't clearly supported. Sep 24, 2024
@jonmeow jonmeow removed the request for review from chandlerc September 24, 2024 23:44
@jonmeow
Copy link
Contributor Author

jonmeow commented Sep 24, 2024

Note, if you prefer, I think I could also only disallow in class and impl scopes. Those both should have suspended function issues. Package scope I think I can actually make work under the current approach.

@jonmeow jonmeow requested a review from zygoloid September 24, 2024 23:48
Comment on lines 19 to 48
let a:! () = ();

// --- implicit.impl.carbon
// --- fail_implicit.impl.carbon

impl package Implicit;

// CHECK:STDERR: fail_implicit.impl.carbon:[[@LINE+4]]:5: error: `let` compile time bindings require function or interface (may be supported later)
// CHECK:STDERR: let b:! () = a;
// CHECK:STDERR: ^~~~~~
// CHECK:STDERR:
let b:! () = a;

// --- other.carbon
// --- fail_other.carbon

package Other;

// CHECK:STDERR: fail_other.carbon:[[@LINE+4]]:5: error: `let` compile time bindings require function or interface (may be supported later)
// CHECK:STDERR: let a:! () = ();
// CHECK:STDERR: ^~~~~~
// CHECK:STDERR:
let a:! () = ();

// --- import_other.carbon
// --- fail_import_other.carbon

import Other;

// CHECK:STDERR: fail_import_other.carbon:[[@LINE+3]]:5: error: `let` compile time bindings require function or interface (may be supported later)
// CHECK:STDERR: let b:! () = Other.a;
// CHECK:STDERR: ^~~~~~
let b:! () = Other.a;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we change these from :! to : bindings? It doesn't look like this test was trying to test compile time bindings in particular.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@jonmeow jonmeow enabled auto-merge September 25, 2024 16:38
@jonmeow jonmeow added this pull request to the merge queue Sep 25, 2024
Merged via the queue into carbon-language:trunk with commit 87678cc Sep 25, 2024
8 checks passed
@jonmeow jonmeow deleted the compile-crash branch September 25, 2024 17:34
geoffromer added a commit to geoffromer/carbon-lang that referenced this pull request Oct 7, 2024
We now allow `let` bindings in all scopes except `class` and `impl`, which are
known to be problematic. This also switches to GetCurrentScopeAs instead of
PeekInstId, to better encapsulate handling of invalid scope inst IDs.
This fixes a fuzzer-found crash when a compile-time binding occurs inside a
block (which is represented by an invalid inst ID).

This partially reverts carbon-language#4338, but is consistent with @jonmeow's comments on
that PR.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants