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.

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

rustc reads directory incorrectly on BSD #12460

Closed
brson opened this issue Feb 22, 2014 · 1 comment
Closed

rustc reads directory incorrectly on BSD #12460

brson opened this issue Feb 22, 2014 · 1 comment
Labels
A-parser Area: The parsing of Rust source code to an AST

Comments

@brson
Copy link
Contributor

brson commented Feb 22, 2014

From the BSD bot, this test makes rustc try to open a directory as a module. On most platforms this results in an 'illegal operation on a directory error' (from libuv), but on BSD rustc succeeds at opening the directory and reads ... something that isn't UTF8.

---- [compile-fail] compile-fail/issue-5806.rs stdout ----

    error: unexpected compiler error or warning: '/home/rustbuild/src/rust-buildbot/slave/auto-bsd-64-opt/build/src/test/compile-fail/issue-5806.rs:22:5: 22:8 error: /home/rustbuild/src/rust-buildbot/slave/auto-bsd-64-opt/build/src/test/compile-fail is not UTF-8 encoded'
    command: x86_64-unknown-freebsd/stage2/bin/rustc /home/rustbuild/src/rust-buildbot/slave/auto-bsd-64-opt/build/src/test/compile-fail/issue-5806.rs -L x86_64-unknown-freebsd/test/compile-fail --target=x86_64-unknown-freebsd -L x86_64-unknown-freebsd/test/compile-fail/issue-5806.stage2-x86_64-unknown-freebsd.libaux -C prefer-dynamic -o x86_64-unknown-freebsd/test/compile-fail/issue-5806.stage2-x86_64-unknown-freebsd --cfg rtopt --cfg debug -O -L x86_64-unknown-freebsd/rt
    stdout:
    ------------------------------------------

    ------------------------------------------
    stderr:
    ------------------------------------------
    /home/rustbuild/src/rust-buildbot/slave/auto-bsd-64-opt/build/src/test/compile-fail/issue-5806.rs:22:5: 22:8 error: /home/rustbuild/src/rust-buildbot/slave/auto-bsd-64-opt/build/src/test/compile-fail is not UTF-8 encoded
    /home/rustbuild/src/rust-buildbot/slave/auto-bsd-64-opt/build/src/test/compile-fail/issue-5806.rs:22 mod foo; //~ ERROR: illegal operation on a directory
                                                                                                             ^~~

    ------------------------------------------

    task '[compile-fail] compile-fail/issue-5806.rs' failed at 'explicit failure', /home/rustbuild/src/rust-buildbot/slave/auto-bsd-64-opt/build/src/compiletest/runtest.rs:950

I think there are two issues here:

  1. rustc shouldn't be deciding to open a directory. What logic lead to that?
  2. libuv does not behave the same on BSD as on other platforms
@brson
Copy link
Contributor Author

brson commented Feb 22, 2014

cc #12304

brson added a commit to brson/rust that referenced this issue Feb 25, 2014
@brson
test: Ignore compile-fail/issue-5806.rs
10b0f16 
Broken on BSD. rust-lang#12460
brson added a commit to brson/rust that referenced this issue Mar 22, 2014
@brson
test: Ignore compile-fail/issue-5806.rs
cdfd4f0 
Broken on BSD. rust-lang#12460
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue Apr 5, 2014
@brson @alexcrichton
test: Ignore compile-fail/issue-5806.rs
3dd9500 
Broken on BSD. rust-lang#12460
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue Apr 6, 2014
@brson @alexcrichton
test: Ignore compile-fail/issue-5806.rs
a6173e1 
Broken on BSD. rust-lang#12460
nodakai added a commit to nodakai/rust that referenced this issue Dec 3, 2014
@nodakai
libstd: explicitly disallow io::fs::File to open a directory.
e7e2d7a 
On *BSD systems, we can open(2) a directory and directly read(2) from
it due to an old tradition.  We should avoid doing so by explicitly
calling fstat(2) to check the type of the opened file.

Opening a directory as a module file can't always be avoided.
Even when there's no "path" attribute trick involved, there can always
be a *directory* named "my_module.rs".

Fix rust-lang#12460

Signed-off-by: NODA, Kai <nodakai@gmail.com>
@bors bors closed this as completed in 3980cde Dec 5, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
@bors
Auto merge of rust-lang#12460 - Veykril:move-guard, r=Veykril
43d9c3f 
minor: Reduce move-guard trigger range
@Oneirical Oneirical mentioned this issue May 13, 2024
Merged
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 27, 2024
@bors
Auto merge of rust-lang#12756 - y21:assigning_clones_lifetimes, r=Ale…
0dc265f 
…xendoo

Avoid emitting `assigning_clones` when cloned data borrows from the place to clone into

Fixes rust-lang#12444
Fixes rust-lang#12460
Fixes rust-lang#12749
Fixes rust-lang#12757
Fixes rust-lang#12929

I think the documentation for the function should describe what- and how this is fixing the issues well.
It avoids emitting a warning when the data being cloned borrows from the place to clone into, which is information that we can get from `PossibleBorrowerMap`. Unfortunately, it is a tiny bit tedious to match on the MIR like that and I'm not sure if this is possibly relying a bit too much on the exact MIR lowering for assignments.

Things left to do:
- [x] Handle place projections (or verify that they work as expected)
- [x] Handle non-`Drop` types

changelog: [`assigning_clones`]: avoid warning when the suggestion would lead to a borrow-check error
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-parser Area: The parsing of Rust source code to an AST
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@brson