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

stage1: better error scenarios for panic function; #1895

Closed
wants to merge 4 commits into from

Conversation

Projects
None yet
2 participants
@kristate
Copy link
Contributor

kristate commented Jan 24, 2019

fixes #1894

@Hejsil
Copy link
Member

Hejsil left a comment

I like the hint for comptime paramters because fn([]const u8, var) var is a very confusing type.
Idk about the other hits. I feel like the error message say all that needs to be said.

add_error_note( g
, last_error
, param_node
, buf_sprintf( "Incorrect type '%s' for first parameter; should be of type '[]const u8'"

This comment has been minimized.

Copy link
@Hejsil

Hejsil Jan 25, 2019

Member

use buf_ptr(&const_u8_slice->name) instead hard coding the name.

add_error_note( g
, last_error
, param_node
, buf_sprintf( "Incorrect type '%s' for second parameter; should be of type '?*builtin.StackTrace'"

This comment has been minimized.

Copy link
@Hejsil

Hejsil Jan 25, 2019

Member

use buf_ptr(&optional_ptr_to_stack_trace_type->name) instead hard coding the name.

add_error_note( g
, last_error
, fn_proto->return_type
, buf_sprintf( "Incorrect return type '%s' for panic function; function should return type 'noreturn'"

This comment has been minimized.

Copy link
@Hejsil

Hejsil Jan 25, 2019

Member

use buf_ptr(&g->builtin_types.entry_unreachable->name) instead hard coding the name.

kristate added some commits Jan 24, 2019

src/analyze.cpp: better error scenerios for panic function;
* deny inline/comptime parameters
* set error notes for parameters with invalid types
* set error notes for panic function return type

@kristate kristate force-pushed the kristate:zig-backport-issue1894 branch from 6650db5 to 7addcad Jan 25, 2019

@kristate

This comment has been minimized.

Copy link
Contributor Author

kristate commented Jan 25, 2019

@Hejsil thanks for the ideas. Yes, if the language changes in the future, it is best to take the type definitions directly from the type objects.

I also took this opportunity to normalize the error messages so they match the work I did in #1886

@kristate kristate closed this Jan 25, 2019

@kristate kristate reopened this Jan 25, 2019

kristate added some commits Jan 25, 2019

@andrewrk andrewrk closed this in a05e224 Feb 16, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.