Skip to content

Bogus span identified with unmatched import #1362

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

Jump to bottom
Closed
brson opened this issue Dec 20, 2011 · 6 comments
Closed

Bogus span identified with unmatched import #1362

brson opened this issue Dec 20, 2011 · 6 comments

Comments

@brson
Copy link
Contributor

brson commented Dec 20, 2011

Compiling the rustray.rc crate here https://github.com/brson/rustray/tree/bogus-error results in this error:

-:6:14265: 6:14272 error: unresolved import: option
-:6:14272: 6:14277 error: unresolved import: math
error: aborting due to previous errors

The error is actually in math3d.rs. This is odd that it's calling the file '-' since that is the placeholder for stdin.
@ghost ghost assigned lht Dec 21, 2011
lht added a commit that referenced this issue Dec 21, 2011
@lht
rustc: Exclude stdin from codemap files when lookup_pos
1e4de33 
Fixes issue #1362
@lht
Copy link
Contributor

lht commented Dec 22, 2011

Fixed by 1e4de33. Closing.

@lht lht closed this as completed Dec 22, 2011
@kevina
Copy link
Contributor

kevina commented Jan 21, 2012

@brson: I don't get any error when compiling rustray.rc.

I reverted the commit that fixed the issue (see 891798fb for why) and applied what I believe is the correct fix.

I am 99% sure my fix (b257549) addressed your issue, can you please verify.

@brson
Copy link
Contributor Author

brson commented Jan 21, 2012

@kevina: your commits look correct to me and I can confirm that on your branch the rustray errors indicate the correct location of the error, though I don't see exactly where new_parser_from_source_str comes into play with parsing rustray's math32.rs.

@brson brson reopened this Jan 21, 2012
@kevina
Copy link
Contributor

kevina commented Jan 21, 2012

@brson: The offsets in span are not offsets within a file, but a virtual file which is basically all the source files for a crate. codemap maintains a mapping from each offset to a file and line number. When new_parser_from_source_str starts from 0 some offsets now correspond to two files, with one of them being the non-existent file "-" created by new_parser_from_source_str, hence the reason for the bogus span.

Anyway I will open a pull request soonish, it might be bundled with the fix for #1448 and #1387 which I am working on now.

@brson
Copy link
Contributor Author

brson commented Jan 21, 2012

I understand the situation with the codemap offsets. I just don't see where new_parser_from_source_str is called during the parsing of that crate.

@kevina
Copy link
Contributor

kevina commented Jan 21, 2012

Sorry left that detail out, see src/comp/syntax/ext/expand.rs it calls parse_expr_from_source_str which calls new_parser_from_source_str

This was referenced Jan 22, 2012
Closed
Closed
@brson brson closed this as completed Jan 22, 2012
kevina added a commit to kevina/rust that referenced this issue Jan 23, 2012
@kevina
Don't reset the chpos/byte_pos to 0 in new_parser_from_source_str.
b705926 
This correctly fixes issue rust-lang#1362.

chpos/byte_pos are now the offsets within a particular file, but
rather the offsets within a virtual file with is formed by combing all
of the modules within a crate.  Thus, resetting them to 0 causes an
overlap and hence, bogus source locations.

Fix rust-lang#1362 by moving chpos/byte_pos to parse_sess so that
new_parser_from_source_str has access to them and hence can chose an
initial value that is not already been used in the crate.

Note that the trigger for bug 1361 was that syntax/ext/expand.rs calls
parse_expr_from_source_str (which calls new_parser_from_source_str)
using the same codemap as the current crate (and hence causing overlap
with files in the crate as new_parser_from_source_str resets the
chpos/byte_pos to 0).
kevina added a commit to kevina/rust that referenced this issue Jan 23, 2012
@kevina
Add regression test for issue rust-lang#1362.
fea5b26 
Although its not really needed.  Without that fix, reported spans will
likely be bogus if the error is within the first couple of lines
(probable around 5) of that file.  Thus, many of the compile-fail
tests will fail due to incorrect location.
brson pushed a commit that referenced this issue Jan 24, 2012
@kevina @brson
Don't reset the chpos/byte_pos to 0 in new_parser_from_source_str.
eee2b68 
This correctly fixes issue #1362.

chpos/byte_pos are now the offsets within a particular file, but
rather the offsets within a virtual file with is formed by combing all
of the modules within a crate.  Thus, resetting them to 0 causes an
overlap and hence, bogus source locations.

Fix #1362 by moving chpos/byte_pos to parse_sess so that
new_parser_from_source_str has access to them and hence can chose an
initial value that is not already been used in the crate.

Note that the trigger for bug 1361 was that syntax/ext/expand.rs calls
parse_expr_from_source_str (which calls new_parser_from_source_str)
using the same codemap as the current crate (and hence causing overlap
with files in the crate as new_parser_from_source_str resets the
chpos/byte_pos to 0).
brson pushed a commit that referenced this issue Jan 24, 2012
@kevina @brson
Add regression test for issue #1362.
1032063 
Although its not really needed.  Without that fix, reported spans will
likely be bogus if the error is within the first couple of lines
(probable around 5) of that file.  Thus, many of the compile-fail
tests will fail due to incorrect location.
brson pushed a commit that referenced this issue Jan 24, 2012
@kevina @brson
Don't reset the chpos/byte_pos to 0 in new_parser_from_source_str.
ad21d9c 
This correctly fixes issue #1362.

chpos/byte_pos are now the offsets within a particular file, but
rather the offsets within a virtual file with is formed by combing all
of the modules within a crate.  Thus, resetting them to 0 causes an
overlap and hence, bogus source locations.

Fix #1362 by moving chpos/byte_pos to parse_sess so that
new_parser_from_source_str has access to them and hence can chose an
initial value that is not already been used in the crate.

Note that the trigger for bug 1361 was that syntax/ext/expand.rs calls
parse_expr_from_source_str (which calls new_parser_from_source_str)
using the same codemap as the current crate (and hence causing overlap
with files in the crate as new_parser_from_source_str resets the
chpos/byte_pos to 0).
brson pushed a commit that referenced this issue Jan 24, 2012
@kevina @brson
Add regression test for issue #1362.
664d9cc 
Although its not really needed.  Without that fix, reported spans will
likely be bogus if the error is within the first couple of lines
(probable around 5) of that file.  Thus, many of the compile-fail
tests will fail due to incorrect location.
coastalwhite pushed a commit to coastalwhite/rust that referenced this issue Aug 5, 2023
@Amanieu
Fix typo in LLVM intrinsic names (rust-lang#1362)
c3b6820 
Fixes rust-lang/stdarch#1361
Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
@tshepang
improve rustc_interface examples a little (rust-lang#1362)
698156f
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
@tshepang
improve rustc_interface examples a little (rust-lang#1362)
370fe59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@lht @brson @kevina