Skip to content

[JuliaSyntax] Add type-asserts to the results of parse_brackets() #60476

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.

Sign up for GitHub

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

Merged
c42f merged 1 commit into from
Jan 5, 2026
Merged

[JuliaSyntax] Add type-asserts to the results of parse_brackets() #60476

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
13 changes: 7 additions & 6 deletions JuliaSyntax/src/julia/parser.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1280,7 +1280,7 @@ function parse_unary(ps::ParseState)
return (needs_parameters=is_paren_call,
is_paren_call=is_paren_call,
is_block=!is_paren_call && num_semis > 0)
end
end::NamedTuple{(:needs_parameters, :is_paren_call, :is_block, :delim_flags), Tuple{Bool, Bool, Bool, RawFlags}}
Copy link
Member

@c42f c42f Jan 4, 2026

Choose a reason for hiding this comment

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

Possibly neater?

Suggested change
end::NamedTuple{(:needs_parameters, :is_paren_call, :is_block, :delim_flags), Tuple{Bool, Bool, Bool, RawFlags}}
end
opts::NamedTuple{(:needs_parameters, :is_paren_call, :is_block, :delim_flags), Tuple{Bool, Bool, Bool, RawFlags}}

Copy link
Member Author

@JamesWrigley JamesWrigley Jan 4, 2026

Choose a reason for hiding this comment

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

I actually didn't realize that was possible 👀 Does a type-assert after the variable initialization have the same effect? I think I have a mild preference for the current version because that's clearer to me.

Copy link
Member

@topolarity topolarity Jan 4, 2026

Choose a reason for hiding this comment

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

Type-inference knows that opts is constrained by the type-assert everywhere "downstream" of this, so this should be effectively the same in practice yeah

(no opinion from me w.r.t. style)

Copy link
Member

@c42f c42f Jan 5, 2026

Choose a reason for hiding this comment

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

yup what Cody said. To expand: type inference follows the data flow according to program control flow. Unlike in some languages, the type assert opts::T is not a global statement about the binding opts. It just asserts the type of the value bound to opts is T at that one point in the program and inference can follow the program dataflow from there.

Style-wise I think it makes slight sense to separate performance annotations from the rest of the code as they're not semantically relevant for humans reading the code. But that's nitpicking, I think this is fine and we can just merge it :)


# The precedence between unary + and any following infix ^ depends on
# whether the parens are a function call or not
Expand Down Expand Up @@ -2242,7 +2242,8 @@ function parse_function_signature(ps::ParseState, is_function::Bool)
parsed_call = _parsed_call,
needs_parse_call = _needs_parse_call,
maybe_grouping_parens = _maybe_grouping_parens)
end
end::NamedTuple{(:needs_parameters, :is_anon_func, :parsed_call, :needs_parse_call, :maybe_grouping_parens, :delim_flags),
Tuple{Bool, Bool, Bool, Bool, Bool, RawFlags}}
is_anon_func = opts.is_anon_func
parsed_call = opts.parsed_call
needs_parse_call = opts.needs_parse_call
Expand Down Expand Up @@ -2776,7 +2777,7 @@ function parse_call_arglist(ps::ParseState, closer)

parse_brackets(ps, closer, false) do _, _, _, _
return (needs_parameters=true,)
end
end::NamedTuple{(:needs_parameters, :delim_flags), Tuple{Bool, RawFlags}}
end

# Parse the suffix of comma-separated array expressions such as
Expand All @@ -2793,7 +2794,7 @@ function parse_vect(ps::ParseState, closer, prefix_trailing_comma)
opts = parse_brackets(ps, closer) do _, _, _, num_subexprs
return (needs_parameters=true,
num_subexprs=num_subexprs)
end
end::NamedTuple{(:needs_parameters, :num_subexprs, :delim_flags), Tuple{Bool, Int, RawFlags}}
delim_flags = opts.delim_flags
if opts.num_subexprs == 0 && prefix_trailing_comma
delim_flags |= TRAILING_COMMA_FLAG
Expand Down Expand Up @@ -3150,7 +3151,7 @@ function parse_paren(ps::ParseState, check_identifiers=true, has_unary_prefix=fa
return (needs_parameters=is_tuple,
is_tuple=is_tuple,
is_block=num_semis > 0)
end
end::NamedTuple{(:needs_parameters, :is_tuple, :is_block, :delim_flags), Tuple{Bool, Bool, Bool, RawFlags}}
if opts.is_tuple
# Tuple syntax with commas
# (x,) ==> (tuple-p x)
Expand Down Expand Up @@ -3328,7 +3329,7 @@ function parse_string(ps::ParseState, raw::Bool)
opts = parse_brackets(ps, K")") do had_commas, had_splat, num_semis, num_subexprs
return (needs_parameters=false,
simple_interp=!had_commas && num_semis == 0 && num_subexprs == 1)
end
end::NamedTuple{(:needs_parameters, :simple_interp, :delim_flags), Tuple{Bool, Bool, RawFlags}}
if !opts.simple_interp || peek_behind(ps, skip_parens=false).kind == K"generator"
# "$(x,y)" ==> (string (parens (error x y)))
emit(ps, m, K"error", error="invalid interpolation syntax")
Expand Down