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

are feature gates for tuple indexing and slicing properly enforced? #18180

Closed
pnkfelix opened this issue Oct 20, 2014 · 4 comments
Closed

are feature gates for tuple indexing and slicing properly enforced? #18180

pnkfelix opened this issue Oct 20, 2014 · 4 comments

Comments

@pnkfelix
Copy link
Member

I have seen evidence that both tuple indexing and slicing syntax are silently allowed by rustc, rather than requiring the feature gate turned on to enable them.

It could be that I missed some step along the way where these features were officially enabled. But I think its more likely that someone has accidentally turned them both on somehow, especially since the team discussion from last Thursday on #18006 included statements that tuple-indexing is meant to be feature gated.

% cat /tmp/f.rs 
fn main() {
    let t = ('a', 'b', 'c');
    let v = vec!['x', 'y', 'z'];
    println!("t: {} v: {}", t.1, v[]);
}
% rustc-0.12-x64 --version=verbose
rustc 0.12.0 (ba4081a5a 2014-10-07 13:44:41 -0700)
binary: rustc
commit-hash: ba4081a5a8573875fed17545846f6f6902c8ba8d
commit-date: 2014-10-07 13:44:41 -0700
host: x86_64-apple-darwin
release: 0.12.0
% rustc-0.12-x64 /tmp/f.rs 
% rustc --version
rustc 0.13.0-dev (4480caf2a 2014-10-18 06:22:15 +0000)
% rustc /tmp/f.rs 
% ./f
t: b v: [x, y, z]
% 
@pnkfelix
Copy link
Member Author

Note that I demonstrated running both the release (0.12) and a recent development (4480caf) build of rustc on the file that is using these features without the gate.

@nrc
Copy link
Member

nrc commented Oct 20, 2014

#18102 ?

@pnkfelix
Copy link
Member Author

oh... right.

@pnkfelix
Copy link
Member Author

(closing as duplicate of #18102 )

lnicola pushed a commit to lnicola/rust that referenced this issue Oct 8, 2024
feat: Index workspace symbols at startup rather than on the first symbol search.

This will eliminate potential many-second delays when performing the first search, at the price of making cache priming (“Indexing N/M” in the VS Code status bar) take a little longer in total. Hopefully this additional time is insignificant because a typical session will involve at least one symbol search.

Further improvement would be to do this as a separate parallel task (which will be beneficial if the workspace contains a small number of large crates), but that would require significant additional refactoring of the progress-reporting mechanism to understand multiple tasks per crate. Happy to tackle that in this PR if desired, but I thought I'd propose the minimal change first.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants