2011/11/4 Nick Sabalausky <[email protected]>: > "kenji hara" <[email protected]> wrote in message > news:[email protected]... >> 2011/11/3 Nick Sabalausky <[email protected]>: >>> I don't know much about the internals of DMD, but would this make any >>> sense?: >>> >>> When unrolling code, keep track of where the unrolled parts came from. >>> Only >>> issue an unreachable code warning if *all* the unrolled versions of the >>> original line X are unreachable. >> >> First, when we use -w option, we usually want to show *all* warnings of >> codes. >> Isn't it your expects? >> > > All real warnings, yes, but this one is just simply incorrect. The line *in > the source code* that says "writeln( "A: ", member );" *does*, in fact, get > reached. Just because it doesn't get reached in *every* iteration doesn't > change that fact that it *does* get reached and is therefore *not* > unreachable code. The fact that the compiler unrolls it behind-the-scenes is > irrelevent to the user - that merely explains why the warning is *currently* > thrown, not why it *should* be thrown. > >> Second, each unrolled loop bodies is separately analyzable by the >> compiler. >> There is no reason to drop the detectable information, unless other >> factors affect (such as performance). >> >> I don't know why you want to reduce warnings that (probably) you expects. >> > > I don't see why anyone would ever expect this warning at all. *All* lines > inside the user's foreach body *do* get used. It's the *compiler's* internal > processing that *adds* in some dead code behind-the-scenes. The source > doesn't have any dead code. It's just like inlining: > > int foo(int x) > { > if(x > 5) > return 5; > return 1; > } > > void main() > { > int x; > x = foo(22); > } > > > Inlining could turn that into: > > void main() > { > int x; > if(22 > 5) > x = 5; > else > x = 1; > } > > Now you have dead code: "x = 1;". But nobody would ever expect to get an > "unreachable code" warning from that. It would never even be helpful. It > would always just be noise. Same goes for the OP's foreach example. > > In both this inlining example and the OP's example, what's important is > whether any of the *user's* code is unreachable, not whether any of the > compiler's internally-generated code is unreachable.
OK. You want to detect unreachable codes that *human feels* with -w. I want to detect codes that is *computed* as unreachable. I think that the -w option's Raison d'etre is to detect all of the *potentially* unreachable codes. For the purpose, -w should detect many codes as far as possible. There is no reason to reduce information by merging unrolled loops. > The fact that the compiler unrolls it behind-the-scenes is irrelevent to the user No, foreach with tuple always unrolled. It is basically truth in strict-typed language. Because each elements can have different types. And with an unrolled loop, its body code does *small generative programming*, and the generated codes may have unreachable statements. Current -w is useful tool to terminate them. Finally from compiler developer sight: Current dmd uses same statically analyzer against unrolled and normal loops. It has been the compiler implementation simple. Kenji Hara
