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

Added octal literal support. #10243

Merged
merged 3 commits into from
Nov 8, 2013
Merged

Added octal literal support. #10243

merged 3 commits into from
Nov 8, 2013

Conversation

mattcarberry
Copy link
Contributor

Associated with Issue #6563.

Useful for Apollo Guidance Computer simulation, Unix file system permissions, and maybe one or two other things.

@brson
Copy link
Contributor

brson commented Nov 3, 2013

Thanks! Let's discuss this change to the language in a weekly meeting before merging.

@chris-morgan
Copy link
Member

I experimented some time back with a couple of ways of doing file modes without needing to resort to comparatively meaningless numbers; for example, defining a macro which could take every possible combination and turn it into a number (that revealed severe performance problems on macros with many thousands of rules... who'd 'a thunked it? If you were doing it seriously, you'd do it as an ultra-fast syntax extension, not as a ridiculously expensive macro that adds three minutes to compile time whether used or not) or constants for every possible combination, like rwxr_S__t. That was a fun experiment in testing unusual conditions in the compiler (it didn't crash anywhere, it merely performed atrociously), but I don't expect it to be taken very seriously.

Still, the principle is right: often defining constants will be sufficient for your purposes. A quick look at the Apollo Guidance Computer suggests it uses octal memory addresses, which would suggest that constants are slightly infeasible and having octal literals would indeed be of value for that case (but you could theoretically define lots of constants or use a macro, like I did!). Still, octal is used by surprisingly few things.

Potentially of more use would be making it possible to have arbitrary base literals. As a demo with no more than twenty-seven seconds' thought put into the syntax, I can imagine something like 8b777 meaning octal 777, 56b14NcYrmxFCN9wAHhxCHkyt4PU9bqnveBUj meaning 14NcYrmxFCN9wAHhxCHkyt4PU9bqnveBUj in base-56—Bitcoin address literals! There are times when writing various algorithms when having base-3 or base-4 would be convenient, for example (alas, base64 probably isn't going to work for tokenising reasons).

@thewonderidiot
Copy link

chris-morgan+1

Arbitrary base literals would be really cool. J has them (with the exact same syntax you proposed), and bash and Ada have them with a '#' instead of 'b'.

@mattcarberry
Copy link
Contributor Author

I like the idea of arbitrary base literals. In thinking about the syntax, it makes a problem for the suffixes. Past a certain base, u32, u16, etc are perfectly valid numbers. Ada wraps the number in #, which is definitely one way to fix it.

@huonw
Copy link
Member

huonw commented Nov 5, 2013

This will also need some positive tests, i.e. checking 0o12 == 10 and so on.

@mletterle
Copy link
Contributor

+1 for arbitrary base literals. Though having built in hex, binary, and octal is nice.

@emberian emberian mentioned this pull request Nov 5, 2013
@emberian
Copy link
Member

emberian commented Nov 5, 2013

I've been ambivalent about this for a while. I lean 👎 but octal is extremely useful in the extremely few cases it's useful in.

@brson
Copy link
Contributor

brson commented Nov 5, 2013

Let's add octal literals per this pull request and defer the question of arbitrary bases to later.

@alexcrichton
Copy link
Member

I'm stopping the build for now, the code looks fine but I agree with @huonw that this requires more tests. Having negative tests is a good thing, but we should also have some positive tests (to make sure they're parsed correctly).

bors added a commit that referenced this pull request Nov 8, 2013
Associated with Issue #6563.

Useful for Apollo Guidance Computer simulation, Unix file system permissions, and maybe one or two other things.
@bors bors closed this Nov 8, 2013
@bors bors merged commit 6eba332 into rust-lang:master Nov 8, 2013
chris-morgan added a commit to chris-morgan/rust that referenced this pull request Nov 16, 2013
- Cause `0` to be considered a valid integer literal (it is).
- Add octal literals (missed from rust-lang#10243).

I have *not* modified doc/po/rust.md.pot or doc/po/ja/rust.md.po at all;
they already seem to be out of date so it's easier to ignore them for
myself. I can update them if desired, of course.
bors added a commit that referenced this pull request Nov 17, 2013
…eference-manaul, r=cmr

- Cause `0` to be considered a valid integer literal (it is).
- Add octal literals (missed from #10243).

I have *not* modified doc/po/rust.md.pot or doc/po/ja/rust.md.po at all;
they already seem to be out of date so it's easier to ignore them for
myself. I can update them if desired, of course.
@aaronfranke
Copy link

Where did this code go in the latest rust-lang/rust? I am not able to find fn scan_number, the lexer.rs file, or the src/libsyntax folder.

flip1995 pushed a commit to flip1995/rust that referenced this pull request Sep 5, 2024
…ng_sub_expression, r=xFrednet

Diverging subexpression lint should not fire on todo!()

As per rust-lang#10243  it is not that helpful to point out that a subexpression diverges, so do not fire on todo

changelog: [`diverging_sub_expression`]: do not trigger on todo
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

Successfully merging this pull request may close these issues.

10 participants