This is a patch for #8005, thanks @lfairy for the hint.
It seems like `block.expr` is None, if the last line of a function has a semi colon (= it ends with a statement).
@kmcallister does this error message cover the intended use cases?
I'm not sure about the message, the wording and the span could probably be improved.
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with \<V0>, \<VI0>
and \<VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
Unsuffixed literals like 1 and 1.1, and free type parameters sometimes
have to be printed in error messages, which ended up with <V0>, <VI0>
and <VF0>. This change puts the words "generic" and "integer"/"float"
into the message so it's not a completely black box.
These functions are of little utility outside a small subset of use cases. If people need them for their own projects then they can use their own bindings for libm (which aren't hard to make).
This is unnecessary and also leads to a bug: When the user specifies
```
#[crate_type = "rlib"];
```
rustpkg still creates a dylib.
Also it's good not to duplicate functionality. `build_session_options` handles this just fine.
Dead code pass now explicitly checks for `#[allow(dead_code)]` and
`#[lang=".."]` attributes on items and marks them as live if they have
those attributes. The former is done so that if we want to suppress
warnings for a group of dead functions, we only have to annotate the
"root" of the call chain.
This fixes the incorrect lexing of things like:
~~~rust
let b = 0o2f32;
let d = 0o4e6;
let f = 0o6e6f32;
~~~
and brings the float literal lexer in line with the description of the float literals in the manual.
Specifically, dissallow setting the number base for every type of float
literal, not only those that contain the decimal point. This is in line with
the description in the manual.
In general, you can run "rustpkg help <cmd>" to see some specific usage information for <cmd>. However, this was handled in a very ad-hoc and buggy manner. For example, running "rustpkg help prefer" would actually show you the usage information for the "uninstall" cmd. Or "rustpkg help test" would show you the usage information for the "build" command. Or "rustpkg help list" would just run the "list" command (and not show you anything usage information)
This commit attempts to fix this by making a new HelpCmd (and handling it explicitly)
This fixes#11336
I guess the type sizes are correct for both OS X and iOS, but i am not certain.
In any case, i'd rather have any iOS build at all, so that we have something to improve upon.
In general, you could run "rustpkg help <cmd>" to see some specific
usage information for <cmd>. However, this was handled in a very ad-hoc
and buggy manner. For example, running "rustpkg help prefer" would
actually show you the usage information for the "uninstall" cmd.
This commit attempts to fix this by making Help a real Command, and
making the handing of it explicit.
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
