| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fixes assertion failure in piglit (gen6, gen8):
spec/glsl-1.30/execution/tex-miplevel-selection textureOffset 1DArrayShadow
In release builds of Mesa, this was observed to cause a GPU hang on
gen8.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Cc: "10.2" <mesa-stable@lists.freedesktop.org>
|
|
For gen6 we will use the ALL_SLICES_AT_EACH_LOD miptree layout for
separate stencil/hiz. This is needed because gen6 hiz and separate
stencil only support a single miplevel. When accessing the other LODs,
we will program a tile aligned offset for the bo.
PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
to [DevSNB]:
"The separate stencil buffer does not support mip mapping, thus the
storage for LODs other than LOD 0 is not needed."
We still allocate storage for the other stencil mip-levels within a
single texture, but each mip-level will use non-mip-array spacing.
PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
"[DevSNB]: The hierarchical depth buffer does not support the LOD
field, it is assumed by hardware to be zero. A separate
hierarachical depth buffer is required for each LOD used, and the
corresponding buffer’s state delivered to hardware each time a new
depth buffer state with modified LOD is delivered."
We allocate storage for the other hiz mip-levels within a single
texture, but each mip-level will use non-mip-array spacing.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
Since gen6 separate stencil & hiz only supports LOD0, we need to
program an offset to the LOD when emitting the separate stencil/hiz.
v3:
* Use new array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
Gen6 doesn't support multiple miplevels for hiz and stencil.
Therefore, we must point to the LOD directly during rendering.
But, we also have removed the tile offsets from normal depth surfaces,
so we need to align each LOD to a tile boundary for hiz and stencil.
v3:
* Use new array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
Previously array spacing lod0 was only used with a single mip level.
It indicated that no mip level spacing should be used between array
slices.
gen6 separate stencil & hiz only support LOD0, so we need to allocate
the miptree similar to array spacing lod0, except we also need
multiple mip levels.
So, the miptree is allocated with tightly packed array slice spacing,
but we still also pack the miplevels into the region similar to a
normal multi mip level packing.
v3:
* Use new array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
gen6 does not support multiple miplevels with separate
stencil/hiz. Therefore we need to layout its miptree with no mipmap
spacing between the slices of each miplevel.
v3:
* Use new array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
We will want to setup gen6 separate stencil and hiz miptrees in a
layout that is similar to array_spacing_lod0. This is needed because
gen6 hiz and stencil only support a single mip-level.
In both use cases (gen7+ LOD0 spacing & gen6 separate stencil/hiz),
the array slices will be packed at each LOD without reserving extra
space for LODs within each array slice.
So, we generalize the name of this field and add comments to indicate
the old and new uses.
Motivation for the gen6 change comes from the PRM:
PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
to [DevSNB]:
"The separate stencil buffer does not support mip mapping, thus the
storage for LODs other than LOD 0 is not needed."
PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
"[DevSNB]: The hierarchical depth buffer does not support the LOD
field, it is assumed by hardware to be zero. A separate
hierarachical depth buffer is required for each LOD used, and the
corresponding buffer’s state delivered to hardware each time a new
depth buffer state with modified LOD is delivered."
v2:
* Rename array_spacing_lod0 to non_mip_arrays
v3:
* Instead, replace array_spacing_lod0 with array_layout enum
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
(bf25ee2 for gen6)
Previously we would always find the 2D sub-surface of interest,
and then program the surface to this location. Now we always
program the 3DSTATE_DEPTH_BUFFER at the start of the surface.
To select the lod/slice, we utilize the lod & minimum array
element fields.
We also must disable brw_workaround_depthstencil_alignment for
gen >= 6. Now the hardware will handle alignment when rendering
to additional slices/LODs.
v3:
* Set depth_mt bo RELOC offset to 0, as was done in bf25ee2
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56127
|
|
(f3c886b for gen6)
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
(e3a49e1 for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
(a23cfb8 for gen6)
In layered rendering this will be 0. Otherwise it will be the
selected slice.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
(08ef1dd for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
(bc1acaa for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
(171e633 for gen6)
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
We will program the gen6 hiz depth state differently to enable layered
rendering on gen6.
v2:
* Remove unneeded gen6_emit_depthbuffer as suggested by Topi
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
|
|
In the gen6 PRM Volume 1 Part 1: Graphics Core, Section
7.18.3.7.1 (Surface Arrays For all surfaces other than separate
stencil buffer):
"[DevSNB] Errata: Sampler MSAA Qpitch will be 4 greater than the
value calculated in the equation above , for every other odd Surface
Height starting from 1 i.e. 1,5,9,13"
Since this Qpitch errata only impacts the sampler, we have to adjust
the input for the rendering surface to achieve the same qpitch. For
the affected heights, we increment the height by 1 for the rendering
surface.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Rather than pointing the surface_state directly at a single
sub-image of the texture for rendering, we now point the
surface_state at the top level of the texture, and configure
the surface_state as needed based on this.
v2:
* Use SET_FIELD as suggested by Topi
* Simplify min_array_element assignment as suggested by Topi
v3:
* Use irb->layer_count for depth instead of rb->Depth
* Make gl_target const
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Since this code was branched from brw_wm_surface_state.c, it had
support for gen < 6. We can now remove this.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
We will program the gen6 renderbuffer surface state differently to
enable layered rendering on gen6.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
The kms-dri swrast driver cannot share buffers using the GEM,
so it must tell the loader to disable extensions relying on
that, without disabling the image DRI extension altogether
(which would prevent the loader from working at all).
This requires a new gallium capability (which is queried on
the pipe_screen and for swrast drivers it's forwarded to the
winsys), and requires a new version of the DRI image extension.
[Emil Velikov]
- Rebased on top of gallium-dri megadrivers.
- Drop PIPE_CAP_BUFFER_SHARE and sw_winsys::get_param hook.
The can_share_buffer cap is set at InitScreen. We use a different
InitScreen (and thus value for the cap) function for kms_dri, due to
deeper differences originating from dri megadrivers.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Add a new winsys and target that can be used with a dri2 state tracker
and loader instead of drisw. This allows to use gbm as a dri2/image
loader and avoid the extra copy from the backbuffer to the shadow
frontbuffer.
The new driver is called "kms_swrast", and is loaded by gbm as a
fallback, because it is only useful with the gbm platform (as no buffer
sharing is possible)
To force select the driver set the environment variable
GBM_ALWAYS_SOFTWARE
[Emil Velikov]
- Rebase on top of gallium megadriver.
- s/text/test/ in configure.ac (Spotted by Andreas Pokorny).
- Add scons support for winsys/sw/kms-dri and fix the build.
- Provide separate DriverAPI, due to different InitScreen hook.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Turn GBM into a swrast loader (providing putimage/getimage backed
by a dumb KMS buffer). This allows to run KMS+DRM GL applications
(such as weston or mutter-wayland) unmodified on cards that don't
have any client side HW acceleration component but that can do
modeset (examples include simpledrm and qxl)
[Emil Velikov]
- Fix make check.
- Split dri_open_driver() from dri_load_driver().
- Don't try to bind the swrast extensions when using dri.
- Handle swrast->CreateNewScreen() failure.
- strdup the driver_name, as it's free'd at destruction.
- s/LIBGL_ALWAYS_SOFTWARE/GBM_ALWAYS_SOFTWARE/
- Move gbm_dri_bo_map/unmap to gbm_driiint.h.
- Correct swrast fallback logic.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
Whenever dd_create_screen/pipe_loader_* fails, gdrm->dev may be NULL.
Thus peeking inside the struct will lead to a crash.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
... on static targets. Otherwise we'll crash badly as gdrm->dev is
NULL when we try to copy the string driver_name.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
|
|
ERROR is a #define in the MSVC WinGDI.h header file.
Add the _TOKEN suffix as we do for a few other lexer tokens.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
|
|
Principle of least surprise: --enable-debug should enable debugging.
Ages ago, Mesa's build system only added -g in dri-debug builds (yay for
the static Makefiles). If you forgot to change it (or wrap the build
with custom scripts), you would often be disappointed when trying to gdb
Mesa bugs. New developers, that may not yet have custom scripts, will
have this same issue.
I think we should enable experienced developers to do what they want,
and make things easier for new developers. I already pass '-ggdb3 -O1'
or '-ggdb3 -Og' for CFLAGS, and I don't want configure to change them
for me.
Signed-off-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
|
|
We've had bugs in the past where we have been inadvertently matching the
default rule.
Just as we did in the pre-processor in the previous commit, we can use:
%option warn nodefault
in the compiler to instruct flex to not generate the default rule, and
further to warn if our set of rules could let any characters go unmatched.
With this warning active, flex actually warns that the catch-all rule we
recently added to the compiler could never be matched. Since that is all
safely determined at compile time now, we can safely drop this run-time
compiler error message, (as we do in this commit).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
We've had multiple bugs in the past where we have been inadvertently matching
the default rule, (which we never want to do). We recently added a catch-all
rule to avoid this, (and made this rule robust for future start conditions).
Kristian pointed out that flex allows us to go one step better. This syntax:
%option warn nodefault
instructs flex to not generate the default rule at all. Further, flex will
generate a warning at compile time if the set of rules we provide are
inadequate, (such that it would be possible for the default rule to be
matched).
With this warning in place, I found that the catch-all rule was in fact
missing something. The catch-all rule uses a pattern of "." which doesn't
match newlines. So here we extend the newline-matching rule to all start
conditions. That is enough to convince flex that it really doesn't need
any default rule.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
Using a single rule here means that we can use the <*> syntax to match
all start conditions. This makes the catch-all rule more robust against
the addition of future start conditions, (no need to maintain an ever-
growing list of start conditions for this rul).
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
There is no behavioral change here. It's just easier to verify that lists
of start conditions include all expected conditions when they appear in a
consistent order.
The <INITIAL> state is special, so it appears first in all lists. All others
appear in alphabetical order.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>
|
|
In some of the recent glcpp bug-fixing, we found that glcpp was emitting
unrecognized characters from the input source file to stdout, and dropping
them from the source passed onto the compiler proper.
This was obviously confusing, and totally undesired.
The bogus behavior comes from an implicit default rule in flex, which is
that any unmatched character is implicitly matched and printed to stdout.
To avoid this implicit matching and printing, here we add an explicit
catch-all rule. If this rule ever matches it prints an internal compiler
error. The correct response for any such error is fixing glcpp to handle
the unexpected character in the correct way.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Previously, the '\r' character was not explicitly matched by any lexer
rule. This means that glcpp would have been using the default flex rule to
match '\r' characters, (where they would have been printed to stdout rather
than actually correctly handled).
With this commit, we treat '\r' as equivalent to '\n'. This is clearly an
improvement the bogus printing to stdout. The resulting behavior is compliant
with the GLSL specification for any source file that uses exclusively '\r' or
'\n' to separate lines.
For shaders that use a multiple-character line separator, (such as "\r\n"),
glcpp won't be precisely compliant with the specification, (treating these as
two newline characters rather than one), but this should not introduce any
semantic changes to the shader programs.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This test is written to exercise a bug which I recently wrote, (but
fortunately caught and fixed before ever committing it).
For the curious:
The bug happened when the NEWLINE_CATCHUP code didn't actually return the
NEWLINE token (due to the skipping). This resulted in the lexer continuing
on through all the subsequent rules while still in the NEWLINE_CATCHUP start
condition, (which then triggered the internal-compiler-error catch-all
rule).
What is intended is for the return of the NEWLINE token to start a new
iteration of the lexer loop, at which time the NEWLINE_CATCHUP-handling code
will reset from the <NEWLINE_CATCHUP> to the <INITIAL> start condition.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
At one point while rewriting the lexing rule for pre-processing numbers, I
made it a bit too aggressive and within a replacement list sucked up a
parameter name that appeared immediately after a period. This caused the
parameter name to be unreplaced when the macro was expanded.
It was in some piglit tests that I originally found this issue. Here, I'm
adding a test to "make check" to ensure that this behavior remains correct.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
These operators aren't defined for preprocessor expressions, so we never
implemented them. This led them to be misinterpreted as strings of unary
'+' or '-' operators.
In fact, what is actually desired is to generate an error if these operators
appear in any preprocessor condition.
So this commit looks like it is strictly adding support for these
operators. And it is supporting them as far as passing them through to the
subsequent compiler, (which was already happening anyway).
What's less apparent in the commit is that with these tokens now being lexed,
but with no change to the grammar for preprocessor expressions, these
operators will now trigger errors there.
A new "make check" test is added to verify the desired behavior.
This commit fixes the following Khronos GLES3 CTS test:
invalid_op_1_vertex
invalid_op_1_fragment
invalid_op_2_vertex
invalid_op_2_fragment
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This will emit an error for something like:
#define FOO(x,x) ...
Obviously, it's not a legal thing to do, and it's easy to check.
Add a "make check" test for this as well.
This fixes the following Khronos GLES3 CTS tests:
invalid_function_definitions.unique_param_name_vertex
invalid_function_definitions.unique_param_name_fragment
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Just reading the code, it looked like a bug that _define_object_macro had this
check, but _define_function_macro did not. Upon further reading, that's
because the check is to allow for our builtins to be defined, (and there are
no builtin function-like macros).
Add my new understanding as a comment to help the next reader.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Previously, we had a single token for "#if" but now that we have two separate
tokens, it looks much better to see:
HASH_TOKEN IF
than:
HASH_TOKEN HASH_IF
(Note, that for the same reason we use HASH_TOKEN instead of HASH, we also use
DEFINE_TOKEN instead of DEFINE to avoid a conflict with the <DEFINE> start
condition in the lexer.)
There should be no behavioral change from this commit.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Without this, in the <PP> state, we would hit Flex's default rule, which
prints tokens to stdout, rather than returning them as tokens. (Or, after the
previous commit, we would hit the new catch-all rule and generate an internal
compiler error.)
With this commit in place, we generate the desired syntax error.
This manifested as a weird bug where shaders with semicolons after
extension directives, such as:
#extension GL_foo_bar : enable;
would print semicolons to the screen, but otherwise compile just fine
(even though this is illegal).
Fixes Piglit's extension-semicolon.frag test.
This also fixes the following Khronos GLES3 conformance tests, (and for real
this time):
invalid_char_in_name_vertex
invalid_char_in_name_fragment
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Carl Worth <cworth@cworth.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This is to avoid the default, silent flex rule which simply prints the
character to stdout.
For the following Khronos GLES3 conformance tests:
invalid_char_in_name_vertex
invalid_char_in_name_fragment
With this commit, these tests now report Pass where they previously reported
Fail, but Mesa isn't behaving correctly yet. It's now reporting the internal
error where what is really desired is a syntax error.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
It's legal (though highly bizarre) for a pre-processor directive to look like
this:
# /* why? */ define FOO bar
This behavior comes about since the specification defines separate logical
phases in a precise order, and comment-removal occurs in a phase before the
identification of directives.
Our implementation does not use an actual separate phase for comment removal,
so some extra care is necessary to correctly parse this. What we want is for
'#' to introduce a directive iff it is the first token on a line, (ignoring
whitespace and comments). Previously, we had a lexical rule that worked only
for whitespace (not comments) with the following regular expression to find a
directive-introducing '#' at the beginning of a line:
HASH ^{HSPACE}*#{HSPACE}*
In this commit, we switch to instead use a simple literal match of '#' to
return a HASH_TOKEN token and add a new <HASH> start condition for whenever
the HASH_TOKEN is the first non-space token of a line. This requires the
addition of the new bit of state: first_non_space_token_this_line.
This approach has a couple of implications on the glcpp parser:
1. The parser now sees two separate tokens, (such as HASH_TOKEN and
HASH_DEFINE) where it previously saw one token (HASH_DEFINE) for
the sequence "#define". This is a straightforward change throughout
the grammar.
2. The parser may now see a SPACE token before the HASH_TOKEN token of
a directive. Previously the lexical regular expression for {HASH}
would eat up the space and there would be no SPACE token.
This second implication is a bit of a nuisance for the parser. It causes a
SPACE token to appear in a production of the grammar with the following two
definitions of a control_line:
control_line
SPACE control_line
This is really ugly, since normally a space would simply be a token
separator, so it wouldn't appear in the tokens of a production. This leads to
a further problem with interleaved spaces and comments:
/* ... */ /* ... */ #define /* ..*/
For this, we must not return several consecutive SPACE tokens, or else we would need an arbitrary number of new productions:
SPACE SPACE control_line
SPACE SPACE SPACE control_line
ad nauseam
To avoid this problem, in this commit we also change the lexer to emit only a
single SPACE token for any series of consecutive spaces, (whether from actual
whitespace or comments). For this compression, we add a new bit of parser
state: last_token_was_space. And we also update the expected results of all
necessary test cases for the new compression of space tokens.
Fortunately, the compression of spaces should not lead to any semantic changes
in terms of what the eventual GLSL compiler sees.
So there's a lot happening in this commit, (particularly for such a tiny
feature). But fortunately, the lexer itself is looking cleaner than ever. The
only ugly bit is all the state updating, but it is at least isolated to a
single shared function.
Of course, a new "make check" test is added for the new feature, (directives
with comments and whitespace interleaved in many combinations).
And this commit fixes the following Khronos GLES3 CTS tests:
function_definition_with_comments_vertex
function_definition_with_comments_fragment
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This is in preparation for the planned addition of a new <HASH> start
condition to the lexer. Both start conditions and token types are, of course,
in the same default C namespace, so a start condition and a token type with
the same name will collide. (And unfortunately, they are both apparently
implemented as equivalent numeric types so the collision is undetected at
compile time and simply leads to unpredictable behavior at run time.)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
This commit does not cause any behavioral change for any valid program. Prior
to entering the <DEFINE> start condition, the only valid start condition is
<INITIAL>, so whether pushing/popping <DEFINE> onto the stack or explicit
returning to <INITIAL> is equivalent.
The reason for this change is that we are planning to soon add a start
condition for <HASH> with the following semantics:
<HASH>: We just saw a directive-introducing '#'
<DEFINE>: We just saw "#define" starting a directive
With these two start conditions in place, the only correct behavior is to
leave <DEFINE> by returning to <INITIAL>. But the old push/pop code would have
returned to the <HASH> start condition which would then cause an error when
the next directive-introducing '#' would be encountered.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
The verbose debug output from the parser is quite useful when debugging, and
having this available as a command-line option is much more convenient than
manually forcing this into the code when needed, (which is what I had been
doing for too long previously).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
For the first line we were initializing the column to 1, but for all
subsequent lines we were initializing the column to 0. The column number is
advanced for each token read before any error message is printed. So the 0
value is the correct initialization, (so that the first column is reported as
column 1).
With this extremely minor change, many of the .expected files are updated such
that error messages for the first line now have the correct column number in
them.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
It makes more sense to print the directive name with the preceding '#'.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Here, "skipping" refers to the lexer not emitting any tokens for portions of
the file within an #if condition (or similar) that evaluates to false.
Previously, the lexer had a special <SKIP> start condition used to control
this skipping. This start condition was not handled like a normal start
condition. Instead, there was a particularly ugly block of code set to be
included at the top of the generated lexing loop that would change from
<INITIAL> to <SKIP> or from <SKIP> to <INITIAL> depending on various pieces of
parser state, (such as parser->skip_state and parser->lexing_directive).
Not only was that an ugly approach, but the <SKIP> start condition was
complicating several glcpp bug fixes I attempted recently that want to use
start conditions for other purposes, (such as a new <HASH> start condition).
The recently added RETURN_TOKEN macro gives us a convenient way to implement
skipping without using a lexer start condition. Now, at the top of the
generated lexer, we examine all the necessary parser state and set a new
parser->skipping bit. Then, in RETURN_TOKEN, we examine parser->skipping to
determine whether to actually emit the token or not.
Besides this, there are only a couple of other places where we need to examine
the skipping bit (other than when returning a token):
* To avoid emitting an error for #error if skipped.
* To avoid entering the <DEFINE> start condition for a #define that is
skipped.
With all of this in place in the present commit, there are hopefully no
behavioral changes with this patch, ("make check" still passes all of the
glcpp tests at least).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
Now that we have a common macro for returning tokens, it makes sense to
perform some of the common work there, (such as copying string values).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
The glcpp parser is line-based, so it needs to see a NEWLINE token at the end
of each line. This causes a trick for files that end without a final newline.
Previously, the lexer for glcpp punted in this case by unconditionally
returning a NEWLINE token at end-of-file, (causing most files to have an extra
blank line at the end). Here, we refine this by lexing end-of-file as a
NEWLINE token only if the immediately preceding token was not a NEWLINE token.
The patch is a minor change that only looks huge for two reasons:
1. Almost all glcpp test result ".expected" files are updated to drop
the extra newline.
2. All return statements from the lexer are adjusted to use a new
RETURN_TOKEN macro that tracks the last-token-was-a-newline state.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
The glcpp implementation has long had code to support a file that ends without
a final newline. But we didn't have a "make check" test for this.
Additionally, the <EOF> action was restricted only to the <INITIAL> state so
it would fail to get invoked if the EOF was encountered in the <COMMENT> or
the <DEFINE> case. Neither of these was a bug, per se, since EOF in either
of these cases is an error anyway, (either "unterminated comment" or
"missing macro name for #define").
But with the new explicit support for these cases, we not generate clean error
messages in these cases, (rather than "unexpected $end" from before).
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
