[PATCH] D11958: Add a -gmodules option to the clang driver.

[Adrian Prantl via cfe-commits]

> On Aug 19, 2015, at 2:15 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> rsmith added a subscriber: rsmith.
> 
> ================
> Comment at: include/clang/Frontend/CodeGenOptions.def:164-165
> @@ -163,1 +163,4 @@
> 
> +CODEGENOPT(DebugTypeExtRefs, 1, 0) ///< Whether or not debug info should contain
> +                                   ///< external references to a PCH or module.
> +
> ----------------
> Does this flag end up in the module hash? It presumably should do so.
> 
> ================
> Comment at: lib/Driver/Tools.cpp:3708
> @@ +3707,3 @@
> +    CmdArgs.push_back("-dwarf-ext-refs");
> +    CmdArgs.push_back("-fmodule-format=obj");
> +  }
> ----------------
> What happens if we get a module cache hash collision between module files with different formats? This didn't really matter when the choice was essentially made per-platform, but if it's affected by a user-facing -g flag, we should make sure this works reliably. (You can probably test this by using `-disable-module-hash` and then using the same module with two different module formats specified.)

Maybe this is missing the point, but a hash collision between module files with different formats should be highly unlikely because we add the module format into the hash.

    llvm::hash_code Hash =
      llvm::hash_combine(DirName.lower(), FileName.lower(),
                         HSOpts->ModuleFormat);

Or do you mean a collision in spite of this?

-- adrian

> 
> 
> Repository:
>  rL LLVM
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D11958&d=BQIFaQ&c=eEvniauFctOgLOKGJOplqw&r=cTx6f1tAfqPeajYunFWp7_8ot79RnHyNteqzig4fXmA&m=Hif7tUdT99UHfmvRzCmBZwy6dNprsPRxUGBxEk-_7N8&s=49H83hq9XpGzkDxo54JS1C3LveyHd66KK0SoZFrFhHU&e= 
> 
> 
>