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

add issue numbers to a bunch of code TODOs #441

Merged
merged 1 commit into from
Nov 16, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion cedar-policy-cli/tests/integration_tests/corpus_tests.rs
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ fn folder() -> &'static Path {
// for now we have a single #[test] that runs all the corpus tests.
// The disadvantage of this is that only one error message will be displayed,
// even if many of the corpus tests fail.
// TODO for the future: figure out if we can procedurally generate one #[test]
// TODO(#438): figure out if we can procedurally generate one #[test]
// per corpus test.
#[test]
// Don't run the corpus tests by default because they can take a minute to
Expand Down
7 changes: 4 additions & 3 deletions cedar-policy-core/src/entities/conformance.rs
Original file line number Diff line number Diff line change
Expand Up @@ -263,9 +263,10 @@ pub fn typecheck_restricted_expr_against_schematype(
expected_ty: &SchemaType,
extensions: Extensions<'_>,
) -> Result<(), TypecheckError> {
// TODO: instead of computing the `SchemaType` of `expr` and then checking
// whether the schematypes are "consistent", wouldn't it be less confusing,
// more efficient, and maybe even more precise to just typecheck directly?
// TODO(#440): instead of computing the `SchemaType` of `expr` and then
// checking whether the schematypes are "consistent", wouldn't it be less
// confusing, more efficient, and maybe even more precise to just typecheck
// directly?
match schematype_of_restricted_expr(expr, extensions) {
Ok(actual_ty) => {
if actual_ty.is_consistent_with(expected_ty) {
Expand Down
2 changes: 1 addition & 1 deletion cedar-policy-core/src/parser/cst_to_ast.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1410,7 +1410,7 @@ impl ASTNode<Option<cst::Member>> {
// Starting off with a failure and filtering items from the accessor list
// can cause false error messages. We consider this acceptable for now because
// they only occur along side a real error.
// TODO: eliminate the false errors (likely with `Option`s inside `AstAccessor`)
// TODO(#439): eliminate the false errors (likely with `Option`s inside `AstAccessor`)
//
// This algorithm is essentially an iterator over the accessor slice, but the
// pattern match should be easier to read, since we have to check multiple elements
Expand Down
2 changes: 1 addition & 1 deletion cedar-policy/tests/corpus_tests.rs
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ fn folder() -> &'static Path {
// for now we have a single #[test] that runs all the corpus tests.
// The disadvantage of this is that only one error message will be displayed,
// even if many of the corpus tests fail.
// TODO for the future: figure out if we can procedurally generate one #[test]
// TODO(#438): figure out if we can procedurally generate one #[test]
// per corpus test.
#[test]
// Don't run the corpus tests by default because they can take a minute to
Expand Down
Loading